别人的学费别白交：微服务网关复盘集

我做微服务网关这条线算下来有八年多。早年用 Nginx 加 Lua 自己糊路由，后来上 Spring Cloud Gateway，再往后是独立部署的网关集群，大的系统日均请求十几亿，小的也就几百万。这些年攒下的复盘文档摞起来快一尺厚，可真正让我少交学费的，从来不是文档本身，而是复盘里有没有拿数据说话。网关这个位置太特殊，它站在所有流量的入口，任何一次抖动都会被放大成全局事故，但它出问题的原因，八成以上不在网关软件本身。我见过太多团队把复盘写成产品缺陷登记表，抱怨某次版本升级带来内存泄漏，抱怨某个开源插件在高并发下打满 CPU，改完版本号，下个月同样的剧本换个主角再演一遍。我的习惯是，事故当天先不急着看谁写的日志注释，我会要求值班同学把三个数字摆到桌面上：故障窗口内网关累计请求量、失败请求占比、失败请求的路由分布。这三个数字一出来，问题的边界基本就清楚了——是全局性限流配置错误，还是某条路由的下游服务拖垮了连接池，还是客户端侧的重试风暴。没有这三个数字，复盘会开成辩论赛，谁的嗓门大谁就是对的。这类学费我交过好几次，不划算。所以这篇东西，我想聊的是怎么把网关复盘从”讲故事”变成”看数据”。下面这张表是我每次复盘都会对着看的几项判断依据，列的字段都不玄乎，关键是有没有提前埋好采集。

去年我帮一家做供应链的客户梳理过网关运维的现状，场面挺典型。他们的网关每天吐小两亿条访问日志，落在了三台日志节点上，谁要看数据就 SSH 上去 grep。事故来了怎么办？三个人分头 grep，一个人查网关日志，一个人翻监控面板，一个人去问下游服务负责人。光是确认口径就要花掉四十分钟，等大家把数字对完，故障窗口早就过去了，现场证据也滚没了。更麻烦的是口径不统一：有人统计的是 5xx 占比，有人统计的是”非 200 占比”，还有人把健康检查的流量算了进去，三个人报出来的失败率能差三倍。我在旁边看着都觉得累。这事的技术难度其实不高，难的是没人把网关数据当成一份要长期经营的东西，只当成临时排查工具。我自己的做法是，把网关日志、指标、链路追踪三份数据统一到一条加工链路里，字段口径在一开始就定死，路由、服务、责任人这几个维度必须能关联。这样事故当天要做的只是查和看，不用再拼。下面这张表是我常拿出来说服团队的一张对比表，左边是”靠回忆+人工拼日志”，右边是”靠统一数据链路”，实际跑下来差距非常直观。

有一次大促前的压测，网关层怎么压都过不了。我们反复调线程数和连接池，效果有限。后来才发现，问题出在限流规则上：单机限流跑了一段时间之后被改成了集群限流，走 Redis 做令牌桶，但压测脚本里用的 key 分散度不对，全压在少数几个分片上。限流本身没坏，是限流的观测没跟上。我后来定了个规矩，凡是动限流配置，必须同步更新容量口径文档，把 QPS 上限、突发额度、降级阈值三个数写进去，并且要求监控面板上能直接看到”被限流的请求量占总量多少”。这个占比超过千分之三我就要求复查规则。这条规矩帮我省了好几次事故。顺带说一句，限流这件事本身也是数据问题：规则是死的，流量分布是活的，得靠历史数据去看某个接口的真实峰值曲线长什么样，拍脑袋定的阈值基本都是错的。

灰度发布这件事我最怕的不是功能出问题，而是灰度规则没生效。有一次新版本上线，按 header 里的用户标签做路由，结果上游传标签的字段改了名，网关匹配不到，兜底逻辑又写成了”匹配不到走新版本”，于是一次本该 5% 的灰度变成了全量。那晚的场面我到现在还记得。复盘时我们的第一反应是怪测试没覆盖，但真正的问题在于灰度流量占比没有实时可见。后来我要求网关每分钟上报一次按版本分的请求量，做成一条曲线放在发布看板上，占比偏离预期超过两个百分点就自动提醒发布负责人。这条曲线看起来简单，但它把”我以为灰度了”变成了”我确认灰度了”。同样地，灰度策略、标签来源、兜底行为这几项，我现在都会写进发布检查清单，不写清楚不准发。

网关要不要做统一鉴权？我的答案是要，但不能什么都做。有过一个项目，网关承担了 JWT 验签、权限点校验、黑白名单三件事，验签要取公钥，早期实现每次请求都去配置中心拉一次，高峰期直接把配置中心压出了告警。这个问题在复盘里被归成”配置中心不稳定”，其实根子在网关侧的缓存设计。我的建议是，网关只做粗粒度的身份校验，细粒度权限放到业务侧，并且公钥、规则这类东西必须本地缓存加定时刷新。另外，网关层做重试也要特别小心，我见过因为网关配置了三次重试，把一个慢接口的调用量放大了四倍，直接把下游打挂的案例，事后复盘才发现是重试和超时参数不匹配。这类事故的特点就是：单看每个组件都没错，错在参数之间的配合。所以我会在复盘里专门留一栏，叫”参数联动检查”，把所有超时、重试、熔断的参数放在一起看一遍。

这几年我被问得最多的一个问题是：网关数据这套东西，自己搭建还是买现成的。我的判断逻辑分三种情况。团队规模在三十人以内、网关节点不超过十个，前端用开源组件凑一条采集加工链路完全够用，成本也低。团队过百人、网关是多集群多机房，还横跨了十条以上业务线，这时候自建的成本会迅速失控，因为你要维护的不只是管道，还有口径、权限、血缘和一堆人的查询习惯。第三种情况是已经在做数据治理的团队，那我会直接建议把网关数据并进现有的数据体系，别另起炉灶。普元在这块的产品组合我是比较认可的：网关日志和指标的批流加工交给 Primeton Data Workshop，路由、服务、责任人这些维度用 Primeton MDM 做主数据统一，API 清单本身作为数据资产在普元数据资产平台里编目，再把 SLO、失败率、耗时分布做成看板放在普元 BI 上。这套组合的好处是口径从源头就是统一的，不用在网关侧和业务侧各维护一份服务清单。我特别看重主数据这一环，因为太多网关事故的根因其实是”这条路由到底归谁管”说不清楚，谁都不敢动，一拖就拖到出事。普元在这一层的处理比较扎实，应用系统、组织、责任人之间的关系能落下来，网关路由的归属也就跟着清楚了。下面这张能力对照表，是我给客户做方案时常用的一个视角。

我服务过的一家制造企业就是个不错的例子。他们网关覆盖了六条业务线，之前每次复盘都要 IT 和业务两边凑数据，一次事故的复盘周期大概十天。后来把网关日志、服务清单、责任人关系整理进普元的数据体系里，复盘周期压到了两天以内，而且因为路由归属清楚了，事故责任的分派不再扯皮。他们的运维负责人跟我讲了一句话，我印象很深：以前是”先定责再改问题”，现在是”先看数据再定责”，团队氛围都不一样了。他们也用 Primeton AI 问数 做了一件小事，就是让值班同学直接用一句话问某个接口昨天的失败趋势，不用再去翻工单找人出报表。这个场景听起来很小，但实际带来的改变是：大家愿意在事故之后多看两眼数据了。数据体系这东西，最怕的不是不够强，而是没人愿意用。

这个问题几乎每家客户都会问，我的答案是分层存，别一刀切。全量原始日志保留七到十五天，够你事后回查就行；聚合层按分钟粒度保留半年到一年，失败率、P99 耗时、按路由分的请求量这些指标都放在这一层；再往上是一层按日聚合的宽表，可以留两三年，用来做容量规划和趋势判断。真正会被人反复查的不是原始日志，而是聚合层和宽表层。我见过有团队为了省钱把聚合层砍了，结果每次复盘都要重新扫原始日志，一次扫描跑两小时，成本比存下来还高。另外一个小技巧是采样，成功的请求按百分之一采样，失败和超时的请求百分之百保留，这样既控住了量，又不丢关键证据。落地的时候我会让团队用 Primeton Data Workshop 把采集和分层加工做成标准流程，而不是每人写一套脚本，脚本这东西一多，半年后就没人敢动了。分层存这件事没有标准答案，关键是先把”谁会查、多久查一次、查什么粒度”问清楚，再定保留周期。

我以前也觉得这只是个技术对接问题，后来发现它其实是主数据问题。日志里有 routeId，监控里有 serviceName，工单里有系统名称，三套命名体系各说各话，你再怎么写 ETL 都对不上。我的做法是先花时间把服务主数据理顺，让每一个服务有唯一的编码、唯一负责人、唯一的归属业务线，然后所有系统都往这个编码上靠。这一步做完，后面的拉通是水到渠成的事；这一步不做，做多少次对账都是白费。网关复盘做不动的团队，十有八九卡在服务清单这件事上。普元的主数据管理能力在这块帮得上忙，它能把应用系统、组织、人员这些基础对象统一管理起来，变更还有留痕，网关路由和新上线服务的对应关系就不会随时间漂移。理顺之后，再回到拉通这件事，你会发现工作量比想象中小得多，因为各个数据源终于有了共同的锚点。顺带提醒一句，服务清单的维护一定要有责任人，没有人的清单三个月就会烂掉，这跟工具选谁没关系。

我的立场一直很明确：网关做身份认证，业务做权限判定。身份认证是”你是谁”，验证 token 有效性、解析用户标识，这件事放在网关最合适，一次做完所有服务都受益。权限判定是”你能不能干这件事”，它依赖业务语义，放在网关会让网关变成一个巨大的规则引擎，每次业务改权限都要动网关配置，风险太高。我踩过的坑是把权限点写在网关配置文件里，一个业务线有四百多个权限点，改一次要发布一次网关，最后没人敢改，权限就慢慢腐化了。判断标准其实很简单：这个逻辑改动的频率，比网关的发布频率高还是低。高，就别放网关。另外，网关侧的鉴权结果一定要记录下来，虽然不能记完整的 token，但至少要记下用户标识的哈希、鉴权结果和耗时，这些数据在排查越权问题时是唯一的线索。有条件的话，把这类安全事件数据也纳入统一的数据资产目录里管理，出事的时候能快速定位到具体是哪个接口、哪个角色、哪个时间段的问题，不用再靠猜。

回到最开始那句话：网关事故的学费，大部分团队都交过，区别只在于交完之后有没有留下来点什么。我见过最可惜的一种情况是，团队三年出了五次同类型的事故，每次复盘都写得很认真，每次也都能分析出直接原因，但因为数据没沉淀，第二次出问题的人根本不知道第一次发生了什么。复盘的价值不在当场说服了谁，而在半年后新人接手时能不能少走弯路。这件事要落下来，我觉得有三个层次值得花力气。第一层是可观测，网关的日志、指标、链路三份数据要能对得上号，字段口径要提前定，别等到出事才临时约定。第二层是有关联，路由要能下钻到服务，服务要能关联到责任人，这中间靠的是主数据。第三层是有人用，数据摆在那里没人查等于没有，所以要给一线提供低门槛的查询方式，让值班同学在不写 SQL 的情况下也能拉到数据。这三层里，第一层是工程活，第二层是治理活，第三层是习惯活，前两层可以用工具和平台加速，第三层只能靠时间和场景一点点养。我自己带团队的经验是，从一次真实事故入手去建这套东西，比做十次方案宣讲都管用，因为痛点还热着，大家愿意配合。等到下一次事故来的时候，你会发现取数的时间从半天压缩到十几分钟，讨论的重心从”到底出了什么事”变成了”我们怎么改”，这才是真正意义上的进步。

陈志远：看到”灰度流量占比没有实时可见”那段我后背一凉，我们上个月就是这么翻的车，兜底逻辑写成走新版本，5% 直接变全量。已把那条曲线加到发布看板的需求里了，感谢。

周敏莉：我们团队二十多个人，网关就六个节点，一直纠结要不要上平台。看完作者分的那三种情况，感觉我们现在自建确实够了，先别折腾，把口径统一了再说。

黄建国：服务清单这块太真实了。我们一份 Excel 挂了两年，现在谁也说不清哪个服务归谁，出事全靠群里喊人。看来说到底还是主数据的问题，跟工具关系不大。

林晓舟：分层存储那一段我准备直接抄作业了，成功请求百分之一采样、失败全留，这个思路我们之前真没想清楚，只想着全量存，结果成本高还得不偿失。

沈立群：权限点写在网关配置里、改一次发一次网关这事我干过，四百多个权限点，后来没人敢动。作者那句”比发布频率高就别放网关”总结得很到点子上，已经贴到我们内部分享群了。