有一次凌晨处理线上问题十几个还在用老版本客户端的用户突然集体报错后端三个服务同时冒出大量异常日志值班的同学一边回滚一边在群里问“到底是谁把字段改了”。折腾到天亮才发现问题根本不在业务代码而在于我们让每个服务各自去处理版本兼容、签名校验、限流和跨域十几套逻辑各写各的改一处漏三处。那次之后我们才认真把Gateway 网关这件事捡起来做把那些散落在各个服务里的公共逻辑统一收到入口层。这篇就聊聊网关这个东西到底是什么、它在链路里站在哪、核心能力怎么拼起来以及从零跑通一个最小网关要踩哪些坑。适合刚开始接触微服务拆分、或者正在犹豫要不要引入网关的同学我会尽量把“为什么这么设计”讲透而不是只丢一堆配置。1. 网关补的到底是架构里的哪个洞1.1 从三个服务到二十个服务重复代码是怎么滚起来的单体应用时代没人会想念网关。一个 war 包丢进容器前端所有请求打到同一个地址鉴权在拦截器里做一次日志在过滤器里打一遍跨域在配置文件里写死完事。问题是在服务拆分之后这套东西会以几乎复制粘贴的方式蔓延到每一个新服务里。我们当时的拆分路径很典型先是用户、订单、商品三个服务每个服务里都有一份 Token 解析工具类后来加了支付、库存、消息工具类变成了六份再后来每份都被人改过一点点签名算法出现了两个版本共存的情况。真正让人难受的不是重复本身而是重复带来的不一致。某次安全整改要求所有接口加上请求时间戳校验防止重放。八个服务四个团队改了两周才全部上线中间有一周时间是半改状态新旧逻辑混跑。还有跨域配置有的服务写了Access-Control-Allow-Origin: *有的写死了具体域名前端联调时经常出现“这个接口能通那个接口 403”的诡异现象排查半天发现是配置差异。这类逻辑在架构术语里叫横切关注点——它们不属于任何一个业务领域但每个对外暴露的接口都需要。身份认证、权限校验、限流熔断、请求日志、链路追踪、协议转换、灰度分流、响应脱敏全都属于这一类。把它们分散在 N 个服务里成本不是线性增长而是指数增长因为组合爆炸N 个服务 × M 个横切逻辑 N×M 份代码每份都要独立测试、独立发布、独立排障。1.2 把公共逻辑上提到入口层收益和代价都要算清楚网关的本质就一句话在客户端和后端服务之间插入一个统一的入口层把横切关注点集中处理。生活里的类比很好理解——一个小区有二十栋楼你可以选择每栋楼门口都雇一个保安查证件也可以在大门口设一个岗亭所有人进出先过岗亭。前者人力成本是后者的二十倍而且二十个保安的判断标准很难完全一致后者只需要一套标准、一套流程、一套监控。收益是显而易见的业务服务回归纯粹只关心“这个请求要查什么数据、返回什么结果”公共逻辑改一次全量生效安全策略有了统一的执行点出了事只需要盯一个地方流量治理能力限流、熔断、灰度有了统一的抓手不用每个服务自己实现一遍。我们改完之后一个鉴权规则的调整从“两周 八个团队”变成了“改配置 灰度十分钟”。但代价必须说清楚否则很容易在引入网关之后踩更大的坑。第一是多了一跳网络开销请求路径从“客户端 → 服务”变成“客户端 → 网关 → 服务”多了一次完整的 TCP 往返和序列化反序列化正常情况下增加 1~3 毫秒配置不当或者网关本身有性能问题时可能增加到几十毫秒。第二是单点风险网关挂了所有流量都进不来所以它必须做高可用部署至少两个实例跨可用区而且要能快速扩容。第三是运维复杂度上升多了一个必须重点保障的组件配置管理、版本升级、容量规划都得跟上。提示如果你的系统只有三五个服务、团队不到十个人、也没有对外暴露大量接口引入完整网关的收益可能覆盖不了运维成本用 Nginx 做一层简单转发加基础鉴权往往更划算。别为了架构图好看而上网关。1.3 一个容易被忽略的判断标准谁在消费你的接口决定要不要上网关有个很实用的判断角度看接口的消费方有多少种。如果只有自家前端一个消费方接口协议稳定、版本迭代同步发布那横切逻辑放在服务里也不会有大问题。但如果消费方包括自有 App且历史版本长期存在、小程序、第三方合作方、内部其他团队的系统那接口的兼容压力会急剧上升这时候网关的价值就体现出来了——它可以在入口层做版本路由、字段兼容、协议适配而不用污染业务代码。我们当时就是被老版本客户端逼着做这件事的。App 的版本更新率永远到不了 100%两年后还有 8% 的设备停留在很老的版本上。这些请求打到新服务上字段缺失、枚举值不认、分页格式不对每种情况都要在业务代码里写兼容分支。后来把这些兼容逻辑收到网关用请求头里的版本号做路由老版本走老版本的服务实例新版本走新的业务代码立刻清爽了。2. 请求从浏览器到后端网关站在第几跳2.1 一次请求的完整链路拆解很多人对网关的位置是模糊的觉得“反正就是在中间”。实际排障时这个模糊会要命——请求超时了到底是 DNS 慢、CDN 没命中、四层负载均衡的问题、七层转发层的问题、网关的问题还是后端服务慢只有把链路拆清楚才能快速定位。下面这张表是我们内部排障时常用的一张对照表把一次 HTTPS 请求从发起到落库的每一跳职责和典型故障表现列了出来。跳次组件类型主要职责典型故障表现1DNS 解析域名到 IP 的映射首包特别慢后续请求正常2CDN / 静态资源层缓存静态文件、边缘就近响应静态资源 404 或缓存脏数据3四层负载均衡TCP 连接分发、健康检查连接被重置、部分实例不接流量4七层入口TLS 卸载证书管理、HTTP 解析、粗粒度路由证书过期、协议版本不匹配5网关鉴权、限流、路由、灰度、日志401/429 集中出现、路由 4046业务服务业务逻辑与数据访问特定接口耗时升高、报错堆栈7服务间调用内部 RPC / HTTP 调用下游超时引发上游雪崩这张表的价值在于帮你建立排除法思维。比如用户反馈“页面打不开”你先看是全部请求慢还是特定接口慢——全部慢往 1~4 跳查特定接口慢往 5~6 跳查。看到大量 429 基本可以直接锁定网关的限流策略看到 401 就在网关的鉴权过滤器里找原因看到 502 一般是网关到后端这一段连接不上。2.2 网关和七层入口、服务网格的边界在哪这三个东西经常被混为一谈实际职责差别很大。七层入口常见的是 Nginx 这一类软件主要负责 TLS 证书卸载、HTTP 协议解析、静态资源服务、基于域名和路径的粗粒度转发它的强项是高并发连接处理和稳定性配置以声明式为主。网关关注的是应用层语义——谁在调用、有没有权限、这个用户该走哪个版本、这个接口一分钟能调几次、响应要不要脱敏。服务网格处理的是服务与服务之间的通信重点是东西向流量的可观测性、mTLS、细粒度流量拆分和故障注入。把它们放在一起看就很清楚了七层入口管“北向流量的接入和卸载”网关管“北向流量的治理”服务网格管“东西向流量的治理”。三层各司其职不要指望一个组件全包。我们见过一些团队把 TLS 卸载、静态资源、鉴权、限流、灰度全塞进网关结果网关配置膨胀到几千行每次发布都提心吊胆性能也扛不住——这就是职责越界。2.3 集中式部署和每服务一个网关怎么选网关的部署形态主要有两种。集中式是所有服务共用一套网关集群通过路由规则把请求分发到不同后端优点是统一管理、统一监控、资源利用率高缺点是配置集中在一处变更影响面大出问题影响所有服务。每服务一个或者按业务域划分是每个服务或每个域有自己的网关实例优点是故障隔离、配置自治、团队自主缺点是资源浪费、标准难统一、监控分散。我的经验是按业务域划分的中间态最实用核心交易域一套、内容域一套、开放平台一套每套独立部署、独立扩容但共用同一套网关框架和配置规范。这样既保证了故障隔离内容域的网关挂了不影响交易又不会退化成每个服务一套的碎片化状态。规模再小一点的团队直接用集中式加严格的灰度发布流程就够了。3. 路由、断言、过滤器三块积木拼出一个网关3.1 一条路由的四个组成部分不管用哪个网关框架核心模型大同小异都是由**路由Route**这个基本单位构成的。一条路由通常包含四部分唯一标识 ID、目标地址请求最终转发到哪里、断言集合满足什么条件才匹配这条路由、过滤器链匹配之后对这个请求做什么处理。这个模型的好处是极其直观——你可以把它理解成一份份“如果……那么……”的规则清单。以 Spring Cloud Gateway 的 YAML 配置为例一条典型路由长这样spring: cloud: gateway: routes: - id: order-service-route uri: lb://order-service predicates: - Path/api/order/** - MethodGET,POST - HeaderX-Client-Version, ^2\..*$ filters: - StripPrefix2 - name: RequestRateLimiter args: redis-rate-limiter.replenishRate: 800 redis-rate-limiter.burstCapacity: 1200逐行拆一下。id是这条路由的名字日志和监控里全靠它区分命名一定要有意义别用route1、route2出问题时你根本不知道是哪条。uri里的lb://前缀表示走服务发现做负载均衡如果写成http://10.0.0.1:8080就是直连固定地址——生产环境不建议直连实例一变就得改配置。predicates是断言数组多个断言之间是与的关系全部满足才匹配。filters是过滤器数组按声明顺序执行。StripPrefix2表示去掉路径的前两段/api/order/list转发到后端时变成/list这个配置项是新手最容易漏的漏了就会出现后端 404。3.2 断言决定“这个请求归谁管”顺序很关键断言是网关的路由判定逻辑常见的有基于路径、方法、请求头、查询参数、Cookie、时间窗口、客户端 IP 等。看起来简单实际有两个坑。第一个坑是断言的顺序和优先级。当多条路由都能匹配同一个请求时大多数框架按路由声明的顺序取第一个匹配的也有的框架支持权重排序。我们踩过一次先配了一条Path/api/**的兜底路由后配了一条Path/api/order/**的精确路由结果所有订单请求都被兜底路由截走了查了半天才发现是顺序问题。正确做法是精确路由在前、宽泛路由在后或者给兜底路由加一个明显更低的优先级。第二个坑是路径匹配的通配符语义。/api/**和/api/*的区别很多人搞不清单星号匹配一层路径双星号匹配任意多层。/api/*能匹配/api/order但匹配不了/api/order/list。另外要注意路径末尾斜杠的处理/api/order和/api/order/在某些框架里会被判定为不同路径前端多传一个斜杠就可能 404。还有一类容易被忽略的断言是基于请求头的版本路由。前面提到老版本客户端兼容就是靠HeaderX-Client-Version, ^1\..*$这样的断言把老版本请求导到专门做兼容的实例组上。这个做法的前提是客户端会传版本头所以接口设计阶段就要把这个头约定好事后补救很麻烦。3.3 过滤器链的执行顺序像洋葱一样从外往里剥过滤器是网关真正干活的地方也是价值密度最高的部分。理解过滤器的关键是想清楚它的执行模型——请求阶段按声明顺序从前往后执行响应阶段按相反顺序从后往前执行就像洋葱一层层剥开再一层层合上。这种模型保证了“谁先开的资源谁后关”比如你在第一个过滤器里记了开始时间它一定在最后一个过滤器里才能算出总耗时。执行阶段过滤器顺序典型动作请求进入1最外层生成 traceId、记录入口日志请求进入2鉴权校验、解析用户身份请求进入3限流判断、拒绝超额请求请求进入4最内层路径重写、添加转发头响应返回4最内层修改响应状态码响应返回3记录后端耗时响应返回2响应脱敏、字段裁剪响应返回1最外层记录总耗时、上报指标这个顺序设计不是随便定的背后有明确的理由。鉴权必须在限流之前否则恶意请求会先消耗限流配额把正常用户的额度挤掉。traceId 生成必须在最外层因为后面所有日志都要带上它晚一步就丢了。耗时统计必须包含最内层因为它要覆盖后端服务的处理时间。这些顺序看起来是常识但在实际配置里经常被写反尤其是多个团队各自加过滤器的时候。3.4 写一个自己的全局过滤器框架自带的过滤器能覆盖大部分场景但总有一些业务定制需求比如给每个响应统一加上链路 ID、把内部错误码转换成对外协议、对特定字段做脱敏。这时候就需要写自定义的全局过滤器。下面是一个生成并透传 traceId 的最小示例用的是 Spring Cloud Gateway 的 GlobalFilter 接口Component public class TraceIdFilter implements GlobalFilter, Ordered { private static final String TRACE_HEADER X-Trace-Id; private static final Logger log LoggerFactory.getLogger(TraceIdFilter.class); Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { String traceId exchange.getRequest().getHeaders().getFirst(TRACE_HEADER); if (traceId null || traceId.isEmpty()) { traceId UUID.randomUUID().toString().replace(-, ).substring(0, 16); } final String finalTraceId traceId; long start System.currentTimeMillis(); ServerHttpRequest mutated exchange.getRequest().mutate() .header(TRACE_HEADER, finalTraceId) .build(); return chain.filter(exchange.mutate().request(mutated).build()) .doFinally(signal - { long cost System.currentTimeMillis() - start; log.info(traceId{} path{} status{} cost{}ms, finalTraceId, exchange.getRequest().getURI().getPath(), exchange.getResponse().getStatusCode(), cost); }); } Override public int getOrder() { return Ordered.HIGHEST_PRECEDENCE; } }几个细节值得说一下。getOrder()返回HIGHEST_PRECEDENCE是为了让它排在最外层这样 traceId 能覆盖后续所有过滤器。exchange.getRequest().mutate().header(...)是必须的直接改原请求对象不行因为它是不可变的这是响应式编程里的常见坑。doFinally保证无论成功失败都会执行日志记录比then或doOnSuccess更稳妥。提示doFinally里拿到的exchange.getResponse().getStatusCode()在异常情况下可能是 null直接拼接会打出一堆 statusnull 的日志建议加判空。另外 traceId 的长度不要随意截断有的团队用 16 位、有的用 32 位跨团队对接时要提前约定好否则日志系统里拼不上。4. 各类网关的适用边界别拿锤子找钉子4.1 四类常见方案的能力对照选型这件事最容易犯的错是“看到别人用啥我就用啥”。实际情况是每类网关都有自己的强项和舒适区用错了不是不能跑而是会在某个阶段突然变得很难受。下面这张表是我们内部做技术选型时的对比口径列的是能力侧重点而不是绝对性能排名。方案类型代表实现强项相对短板适合场景配置型七层软件Nginx 及其脚本扩展方案极高并发、稳定、资源占用低业务逻辑扩展门槛高动态配置需额外方案接入层、静态资源、简单转发应用框架型Spring Cloud Gateway与 Java 生态无缝集成写过滤器就是写业务代码单机吞吐弱于 C 系实现内存占用较高Java 技术栈、需要大量业务定制插件生态型Kong 一类插件丰富配置动态生效多语言支持深度定制需要学 Lua链路上多一层依赖开放平台、多团队共用、需要快速接入云原生数据面Envoy 一类性能好、可观测性强、与服务网格天然配合学习曲线陡配置模型较复杂大规模集群、已引入服务网格4.2 选型时先问自己三个问题第一问技术栈是什么。如果整个后端是 Java 生态团队里没人写 Lua、也没人熟悉 Envoy 的配置模型那选 Spring Cloud Gateway 就是最省心的因为写过滤器就是写熟悉的 Java 代码调试、单元测试、CI 流程全部复用现有体系。反过来如果是多语言混合栈Java 框架就没什么优势了插件生态型方案更合适。第二问配置变更的频率有多高。如果路由和限流规则基本不动用配置文件 重启发布完全够用。如果运营侧经常要改限流阈值、加白名单、调整灰度比例那就必须选支持动态配置的方案否则每次改个数字都要走一遍发布流程运营同学会疯掉。我们当时的做法是接配置中心网关监听配置变更事件热更新路由改限流阈值从“发版 20 分钟”变成“改配置 10 秒生效”。第三问性能要求是什么量级。这里要特别提醒别照抄别人公布的 QPS 数字。测试口径差异极大有没有开 TLS、请求体多大、响应是否压缩、连接是否复用、断言规则有几条、过滤器里做了多少事每一个变量都能让数字差出好几倍。我见过同一个框架在两份不同报告里数字相差六倍的案例一份测的是空转返回固定字符串另一份测的是带鉴权、限流、日志的完整链路。要评估性能唯一的办法是用自己的真实配置和真实报文压一遍。4.3 一个反直觉的结论网关的性能瓶颈往往不在网关本身我们做过一轮压测单实例网关在完整链路鉴权 限流 日志 转发下跑到某个量级就开始出现延迟毛刺。一开始以为是框架性能问题折腾了半天参数调优最后定位到根因是日志同步刷盘和限流依赖的远程调用——每次请求都要同步写一条日志到磁盘还要访问一次远程缓存判断配额这两个动作加起来占了单请求耗时的六成以上。改成异步日志加本地令牌桶预取之后同样的硬件吞吐直接翻倍。这件事给我的教训是评估网关性能时先把所有同步的外部依赖列出来能异步的异步、能本地缓存的本地缓存、能批量合并的批量合并做完这一步再谈框架选型。很多人一上来就纠结框架谁快谁慢但真实场景里那些毫秒级的框架差异往往被一次同步远程调用就吃掉了。5. 从零跑通一个最小网关的完整过程5.1 版本对齐是第一步也是最容易翻车的一步Java 生态的版本兼容问题在网关这里体现得特别明显因为网关依赖 Spring Cloud 的一整套组件版本对不上直接启动失败或者运行时报各种找不到类。我整理了一份常用的对应关系选版本的时候对着看能省掉大量时间。组件版本约束要点说明JDK17 及以上新版本框架已不推荐低版本 JDKSpring Boot3.x决定了基础依赖的版本区间Spring Cloud与 Boot 版本严格对应官方有明确的兼容矩阵务必查表注册中心客户端与 Cloud 版本同代跨代会出现在注册但拉不到实例配置中心客户端与 Cloud 版本同代同上注意不要凭记忆写版本号。Spring Cloud 和 Spring Boot 的版本兼容是强约束差一个小版本都可能出问题。遇到“启动时报 NoSuchMethodError”或者“配置项不生效”先查版本矩阵八成的概率是版本没对齐。5.2 配置文件逐行拆开看跑通最小可用网关配置文件其实不长但每一行都有讲究。下面这份是能直接用的骨架server: port: 9000 spring: application: name: gateway cloud: gateway: discovery: locator: enabled: false httpclient: connect-timeout: 1000 response-timeout: 3000 routes: - id: user-service uri: lb://user-service predicates: - Path/api/user/** filters: - StripPrefix2 - id: fallback-route uri: lb://default-service predicates: - Path/api/** filters: - StripPrefix1几个关键点。discovery.locator.enabled建议设为false。这个开关打开后框架会自动为注册中心里的每个服务生成一条路由路径规则是服务名小写看起来很省事实际很危险——意味着任何注册上来的服务都自动对外暴露了测试环境的服务可能被误访问安全边界完全失控。路由必须显式声明这是我一直坚持的原则。httpclient的超时配置一定要显式设置。默认值在生产环境往往不合适连接超时太长会导致网关线程被慢连接占住响应超时太长会让用户等太久。这里的数值需要根据下游服务的实际耗时分布来定后面第 6 章会讲怎么算。StripPrefix的数值要跟路径前缀的段数严格对应。/api/user/**去掉两段就是/user之后的全部内容比如/api/user/profile转发后是/profile。这个数字写错的典型症状是后端返回 404而且日志里看不出异常因为网关自己认为转发成功了。5.3 启动失败的高频原因排查刚上手的时候启动不起来是常态。按下面这个顺序排查基本能覆盖九成情况端口被占用。报错信息里会明确写Port 9000 was already in use换个端口或者杀掉占用进程即可。开发机上经常是上次没关干净。依赖冲突导致类加载失败。症状是NoSuchMethodError、ClassNotFoundException、NoClassDefFoundError。用依赖树命令把冲突的包找出来通常是注册中心客户端或配置中心客户端被不同来源引入了多个版本。注册中心连不上。症状是启动卡住几十秒然后超时退出。检查注册中心地址配置、网络连通性、以及本地时间是否准确时间偏差过大会导致心跳被拒。路由配置格式错误。YAML 缩进错一个空格就会解析失败症状是启动时报绑定异常错误信息里会指出具体字段。建议配置写完先过一遍 YAML 校验。断言或过滤器类找不到。用了自定义过滤器但没被扫描到检查包路径是否在启动类扫描范围内或者有没有加组件注解。5.4 用五条命令验证网关是否真的工作启动成功不等于工作正常必须实际验证。下面这组命令覆盖了最常见的五个验证点建议每次改完配置都跑一遍# 1. 基础路由是否通 curl -i http://localhost:9000/api/user/profile # 2. 路径重写是否正确看后端日志里的实际路径 curl -i http://localhost:9000/api/user/profile?debug1 # 3. 请求头是否被正确透传 curl -i -H X-Trace-Id: test-trace-001 http://localhost:9000/api/user/profile # 4. 限流是否生效连续快速请求观察是否出现 429 for i in $(seq 1 50); do curl -s -o /dev/null -w %{http_code}\n http://localhost:9000/api/user/profile; done # 5. 后端服务不可用时的表现先停掉后端服务再请求 curl -i http://localhost:9000/api/user/profile第 5 条特别重要。很多人只验证“通”的情况不验证“不通”的情况。后端挂了的时候网关返回什么是 500、502 还是 503有没有返回一堆内部堆栈信息响应时间是多少这些在没有故障的时候看不出来真出事时才发现网关把后端异常的堆栈原样透给了前端既泄露信息又影响体验。6. 上线之前必须算清楚的几个数6.1 超时配置的三层关系配错了会雪崩超时是最容易配错、配错了后果最严重的一项。链路上有三个层次的超时必须协调网关到后端的读超时、服务内部的调用超时、服务自身的处理耗时。原则是外层超时必须大于内层所有可能耗时的总和否则会出现“内层还在正常处理外层已经放弃并重试”的情况一次用户请求在后台被放大成好几次直接把下游打垮。举个具体例子算一遍。假设服务 A 处理一个请求需要调用服务 B超时 800 毫秒最多重试 1 次和服务 C超时 500 毫秒不重试A 自己的计算和数据库访问大概 200 毫秒。那么 A 的最坏耗时是800×2 500 200 2300 毫秒。网关到 A 的读超时如果配成 2000 毫秒就会出现网关已经超时返回、A 还在慢慢跑的情况。合理配置是 2300 毫秒再加一点余量比如 2500 到 3000 毫秒。层级建议值计算依据单次下游调用依据下游 P99 耗时 × 1.5覆盖绝大多数正常请求重试次数只对幂等接口开启最多 1 次避免请求放大服务整体耗时所有下游最坏耗时之和 自身耗时串行调用需累加并行取最大值网关读超时服务整体最坏耗时 × 1.1~1.3留出网络抖动和调度延迟的余量提示重试只对幂等接口开启。GET、PUT、DELETE 一般可以重试POST 要极其谨慎尤其是下单、支付这类接口重试可能造成重复扣款。如果确实需要重试 POST必须配合幂等键做去重这是另一个话题了。6.2 限流参数不是拍脑袋定的算给你看限流参数最容易被“凭感觉填”填大了没效果填小了误伤正常用户。令牌桶模型有两个核心参数令牌生成速率和桶容量。速率的含义是稳态下允许通过的请求速率容量的含义是允许的瞬时突发量。假设某个接口的线上峰值 QPS 是 800允许短时突发到 1200那么速率配 800、容量配 1200 是合理的起点。但容量不能随便调大原因在于下游的承载能力有硬上限。如果下游服务的连接池是 50 个连接、单请求平均耗时 50 毫秒那么单实例的理论吞吐上限是 50 ÷ 0.05 1000 QPS。这时候把桶容量设成 3000 毫无意义多出来的 2000 个请求只会在连接池队列里排队排队时间越长用户感受到的延迟越高最后触发超时重试反而加剧拥堵。所以限流的容量参数应该这样定先算出下游的实际吞吐上限再把桶容量控制在这个上限的 1.2 倍以内。速率则参考历史峰值流量取最近 30 天 P99 的 QPS 再留 20% 余量。另外一定要区分接口维度和用户维度两种限流接口维度防的是整体流量洪峰用户维度防的是单个调用方刷接口。两者要叠加使用只做其中一种都会留缺口。6.3 日志和指标里必须有哪几个字段网关是所有流量的必经之路它的日志价值极高但日志字段设计不好会变成噪音。我要求日志里必须包含这几个字段traceId串联全链路、路由 ID知道是哪条规则匹配的、请求路径原始路径不含查询参数以免泄露敏感信息、响应状态码、总耗时、后端实例地址定位是哪个实例慢、客户端标识区分调用方。指标方面至少要有四类请求量按路由、状态码分组、延迟分布P50/P95/P99不能只看平均值平均值会掩盖长尾、限流命中数判断阈值是否合理、后端不可用次数健康检查失败计数。这四类指标配好告警阈值基本能覆盖绝大多数线上异常的早期发现。有个细节值得单独说延迟指标一定要按路由分开看。全局平均延迟 20 毫秒看起来很好但某个路由可能已经 2000 毫秒了被其他快速路由平均掉了。我们有过一次教训全局指标一切正常但用户投诉某个功能特别慢一查发现那条路由的 P99 已经飙到 5 秒只是因为它的请求量占比小没在全局平均值上体现出来。6.4 灰度分流用请求头做切分的最小实现网关做灰度有一个天然优势——它能拿到请求的全部信息可以按用户 ID、设备 ID、请求头、地理位置、随机比例做分流。最小实现是基于请求头的权重路由给一部分请求打上标记头网关根据这个头把流量导到新版本实例组。具体做法是在路由配置里准备两套目标一套指向稳定版实例组一套指向灰度版实例组然后用过滤器或者自定义断言读取灰度标记决定走哪套。比例控制可以用两种方式一是按用户 ID 哈希取模保证同一个用户始终落在同一侧体验一致二是纯随机比例实现简单但同一用户可能新旧版本来回跳。我更推荐按用户 ID 哈希。原因是很多功能涉及状态比如用户在新版本里点了某个按钮产生了数据切回老版本看到不一致的界面会困惑甚至报错。哈希取模能保证用户粘性代价是需要先确定一个稳定的用户标识而且比例调整时会有部分用户迁移需要接受这个抖动。灰度期间还要重点盯两套实例的错误率和延迟对比如果灰度侧错误率明显更高要能在一分钟内把流量切回去——所以灰度开关必须做成动态配置不能靠改配置文件重启。有一点容易被忽略灰度不只是转发响应格式也要兼容。新旧版本返回的字段可能不同如果前端是同一份代码就得在网关做响应适配把新字段裁掉或者给老字段补默认值。这类适配逻辑最好集中在网关的一个过滤器里别散落在各处否则灰度结束后清理起来很痛苦。这套东西跑通之后我们那个凌晨被电话叫醒的场景基本不会再出现了——版本兼容在网关层解决业务服务不用再写一堆判断分支限流和鉴权有了统一的执行点出问题看一份日志就能定位到具体哪一跳。后面还有不少细节值得展开比如网关的高可用部署方式、动态路由的热更新机制、以及和认证体系的对接细节这些留到下一篇再说。
