100+微服务的统一出入口：政策快报平台的API网关设计

政策快报平台的后端服务从最初的一个单体应用拆分成了现在的100多个微服务。服务多了问题也多了每个服务都要做鉴权代码重复每个服务都要限流各自为政出了问题不知道是哪个服务挂了前端要调用几十个不同的接口地址管理混乱2024年我们做了一件事把所有服务的出入口统一收归到一个API网关。网关作为唯一入口统一处理鉴权、限流、路由、监控后端服务只负责业务逻辑。做这件事之前我们花了两周时间调研方案、梳理已有的服务清单、评估改造范围。网关本身不复杂但改动的边界需要想清楚——哪些功能应该由网关统一处理哪些应该下放到业务服务自己控制。想清楚之后才开始动手。4个核心功能功能一统一鉴权网关之前每个服务都要自己验证Token、解析用户信息。重复代码多还容易出漏洞。网关之后Token验证统一在网关层完成。验证通过后网关把用户信息user_id、权限等注入到请求头里下游服务直接使用。下游服务不再需要关心Token怎么解析、怎么验证——只管业务逻辑拿到user_id就用。功能二统一限流和熔断网关之前每个服务独立限流。一个服务被冲垮不会影响其他服务。但问题是如果某个服务的流量突然暴增网关会先感知到。网关之后在网关层统一配置限流规则。某个接口超过阈值网关直接返回“繁忙”请求根本不会打到下游服务。同时网关会对异常情况响应超时、错误率超限自动触发熔断快速失败而非长时间阻塞。功能三统一路由网关之前前端要记住几十个不同的服务地址policy-api、user-api、search-api、recommend-api……每个服务一个域名或路径前端配置混乱联调效率低。网关之后前端只需要记住一个域名。所有请求都发到网关网关根据路径如/api/policy/xxx自动路由到对应服务。前后端对接成本大幅降低。功能四统一监控网关是请求进出的必经之路所以它也是采集流量数据的最佳位置。网关记录每个请求的路径、响应时间、状态码、用户ID——这些数据成为全链路监控和告警的数据基础。网关的技术选型在技术选型上对比了Kong和Spring Cloud GatewayKong功能全面基于NginxOpenResty性能好适合大规模生产环境但运维成本较高需要单独部署和管理。Spring Cloud Gateway是Spring生态的一部分与现有Java技术栈天然兼容易于开发和定制但性能略低于Kong。考虑到团队技术栈和后期的可维护性选择了Spring Cloud Gateway便于团队快速上手和持续迭代。关于部署架构网关本身是无状态的可以水平扩展。目前生产环境部署了3个节点日常单节点处理约2万QPS瓶颈主要在下游服务。网关层面预留了横向扩展的能力如果流量继续增长可以直接增加节点数。遇到的几个问题问题一网关成了单点故障网关是唯一入口它挂了所有服务都挂。解决方案网关部署3个节点前置负载均衡SLB单节点故障自动切换。问题二超时时间难配置不同服务的响应时间不同查询类服务要求快秒级导出类服务可能慢几十秒。网关的超时时间不能一刀切。解决方案网关支持按路由配置超时。查询服务设3秒超时导出服务设60秒超时。问题三网关成了性能瓶颈所有请求都经过网关网关自身的处理能力很重要。解决方案网关层尽量轻量——不处理业务逻辑只做路由、鉴权、限流。复杂逻辑下沉到服务层网关只做“快递员”不做“加工厂”。结尾API网关的核心价值不是“技术多先进”是“边界多清晰”。网关负责“怎么进、怎么出”服务负责“做什么”。各司其职系统才稳定。