服务拆得越多，横切关注点就越刺眼。鉴权逻辑，每个服务都要重复实现一遍 token 校验，都要去请求认证服务，都要维护一份密钥。限流配置，每个服务各自为政，全局视角缺失。日志埋点，每个服务自己搞一套格式，traceId 各定各的串不起来。这些跟业务无关但所有服务都要做的事，分散到几十个服务里就是几十倍的重复劳动，而且改一处要同步改几十处。
网关把这些横切关注点收敛到一个统一入口。所有外部请求先到网关，网关做完鉴权、限流、路由、熔断这些公共动作，再转发给后端业务服务，后端服务就只需专注业务。这是网关存在的核心理由，它消除了几十倍的重复劳动。这篇讲网关要做哪些事，以及做这些事时容易踩的坑。
图：网关收敛横切关注点，业务服务专注领域逻辑
鉴权在网关层收口
鉴权是最先该收敛到网关的。分散鉴权的问题不只是重复，还有不一致。几十个服务各自实现 token 校验，时间一长，有的更新了校验逻辑有的没更新，安全策略就开始参差不齐。
图：客户端 Token 在网关层统一校验，用户身份注入请求头转发，业务服务基于网络隔离信任网关
网关层统一鉴权后，流程变成这样。客户端请求带着 token 到网关，网关调认证服务校验 token，拿到用户身份信息，把用户 ID 注入到请求头里，比如 X-User-Id，然后转发给业务服务。业务服务直接读这个头，信任网关已经认证过了，不再自己校验。
这里有个前提必须配套，就是内网信任边界。业务服务直接信任网关注入的用户信息头，建立在一个条件上，业务服务不对外暴露，只能被网关访问，靠网络隔离保证。如果业务服务也对外暴露，攻击者就能绕过网关，自己伪造一个 X-User-Id 头直接调业务服务，鉴权形同虚设。所以网关架构必须配套网络隔离，业务服务部署在内网，只接受网关来源的请求。这个前提没做实，整套鉴权就是纸糊的。
限流的天然卡点
网关是限流的最佳位置，因为所有流量必经此处，在网关限流最有效，也最干净。
图：网关限流（粗粒度，技术维度）与业务服务限流（细粒度，业务语义）分工协作，层层过滤
网关层可以做多维度限流。全局 QPS 限流保护整个后端不被打爆。接口级限流保护特定的脆弱服务。用户级限流防止单个用户刷量。IP 级限流防爬虫和恶意流量。这几个维度可以叠加，层层过滤。
但要清楚网关限流是粗粒度的。那些依赖业务上下文的细粒度限流，比如每个商品每秒只能买一次、每个用户每天只能领一张券，这些网关做不了，因为网关不懂业务语义。这类限流必须下沉到业务服务里，用业务键做判断。网关限流和业务限流是分工关系，不是替代关系，网关挡宏观洪峰，业务挡微观异常。
动态路由支撑不停机调整
网关的路由规则必须支持动态更新。新增服务、下线服务、灰度切流，这些操作都不能重启网关，否则每次调整都是一次全站抖动。
路由规则存在配置中心，网关启动时加载，配置变更时热加载生效。一个典型配置是把 URL 前缀映射到服务，/api/order 路由到 order-service，/api/pay 路由到 pay-service。灰度发布时，网关按权重或规则分流，比如 90% 流量走 order-service v1，10% 走 v2 灰度版本，或者按请求头里带 beta=true 的标识走 v2。规则变更后网关不重启即时生效，这是动态路由的核心价值。
这套机制和配置中心深度绑定，配置中心推送变更，网关监听并重新加载路由表。没有配置中心的动态推送能力，网关的动态路由就无从谈起。
熔断降级保护后端
网关作为所有请求的中转，有义务保护后端不被雪崩拖垮。当某个后端服务响应变慢或错误率升高，网关要主动熔断这个服务，快速失败，不让请求继续堆过去。
熔断器的三态逻辑和单服务熔断一样，关闭态正常转发，打开态直接拒绝，半开态放少量试探请求。区别在于网关熔断是全局视角的，它看的是从网关到某个后端服务的整体健康度，熔断决策影响所有走这个服务的请求。熔断期间网关返回降级响应，兜底数据或友好错误，而不是把请求转发给已经濒死的服务再等它超时。
协议转换让后端用最适合的协议
网关常做协议适配，外部 HTTP 请求转内部 gRPC，内部 Thrift 转外部 JSON，WebSocket 长连接代理。这让后端服务可以用最适合自己的协议，gRPC 高效但外部客户端不一定支持，对外统一提供 HTTP 或 JSON 接口，转换在网关完成。
这层转换有性能开销，但换来的是后端协议的解耦。后端从 REST 迁到 gRPC 不影响外部客户端，外部接口契约稳定，内部实现自由演进。
网关自身是新的单点
引入网关解决了服务入口的混乱，但也创造了一个新的单点。网关一旦挂了，所有服务对外不可用。所以网关的可用性要求比任何单个后端服务都高。
图：网关作为新的单点，必须具备多副本、无状态、优雅停机、过载保护四重高可用保障
网关必须多副本部署，至少两个实例，前面挂负载均衡。必须无状态，所有状态外置，session、限流计数都放 Redis，保证任意副本都能服务任意请求。必须支持优雅停机，停机前先拒绝新请求，等存量请求处理完再退出，不能硬杀导致请求中断。网关自己也要有过载保护，防止流量打爆网关本身。这四条缺一条，网关就从解药变成了毒药。
引入网关解决了服务入口的混乱，但创造了新的单点。网关的可用性要求比任何后端服务都高，它挂了等于全站挂。多副本、无状态、优雅停机、过载保护，这四条是网关可用性的底线，缺一条都不行。
全链路观测的最佳卡点
网关是全链路可观测性的最佳观测点，因为所有请求都经过这里。统一的访问日志、指标采集、链路追踪，都在网关层做最完整。
一次请求的 traceId 在网关生成，透传到后端所有服务，后端日志带上这个 traceId。出问题时一条 trace 串起全链路，从网关到每个后端服务，每个环节的耗时和状态都看得见。这种端到端的可观测性，只有网关这个位置能做到，因为只有它既连着客户端又连着所有后端。
选型看团队技术栈
网关选型，纯 Java 技术栈选 Spring Cloud Gateway，和 Spring 全家桶集成成本最低，团队上手快。追求性能和灵活定制选 APISIX，比 Kong 更轻快，插件生态丰富。已经在做 Service Mesh 的选 Envoy，作为数据面和 Istio 配合。Nginx 加 Lua 适合那些对性能有极致要求且能接受 Lua 开发门槛的团队。
选型不要只看功能列表，更要看团队技术栈匹配度和长期维护成本。一个功能更强但团队不熟的网关，落地和维护的隐性成本远高于一个功能够用但团队上手的方案。网关是基础设施，稳定运行比功能炫酷重要。
