政策快报平台的后端服务，从最初的一个单体应用，拆分成了现在的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 Gateway：
Kong功能全面（基于Nginx+OpenResty），性能好，适合大规模生产环境，但运维成本较高，需要单独部署和管理。Spring Cloud Gateway是Spring生态的一部分，与现有Java技术栈天然兼容，易于开发和定制，但性能略低于Kong。考虑到团队技术栈和后期的可维护性，选择了Spring Cloud Gateway，便于团队快速上手和持续迭代。
关于部署架构：网关本身是无状态的，可以水平扩展。目前生产环境部署了3个节点，日常单节点处理约2万QPS，瓶颈主要在下游服务。网关层面预留了横向扩展的能力，如果流量继续增长，可以直接增加节点数。
遇到的几个问题
问题一：网关成了单点故障
网关是唯一入口，它挂了所有服务都挂。解决方案：网关部署3个节点，前置负载均衡（SLB），单节点故障自动切换。
问题二：超时时间难配置
不同服务的响应时间不同：查询类服务要求快（秒级），导出类服务可能慢（几十秒）。网关的超时时间不能一刀切。解决方案：网关支持按路由配置超时。查询服务设3秒超时，导出服务设60秒超时。
问题三：网关成了性能瓶颈
所有请求都经过网关，网关自身的处理能力很重要。解决方案：网关层尽量轻量------不处理业务逻辑，只做路由、鉴权、限流。复杂逻辑下沉到服务层，网关只做"快递员"，不做"加工厂"。
结尾
API网关的核心价值，不是"技术多先进"，是"边界多清晰"。网关负责"怎么进、怎么出"，服务负责"做什么"。各司其职，系统才稳定。