平台工程与API网关：重新认识这对“黄金搭档”
说实话，我入行那会儿还没有「平台工程」这个说法。那时候大家聊的是「中间件」、「服务治理」，听起来挺高大上，但实际做起来呢？每个团队自己搭网关、自己写限流、自己搞配置中心，最后搞出来的东西七零八落。直到后来我参与了一个中型企业的平台化改造项目，才真正搞明白一件事：平台工程不是换个名字，而是换一套玩法。
这一章，我们就聊聊平台工程到底想解决什么问题，API网关在这个体系里又是怎么扛大旗的。嗯，干货不少，慢慢看。
平台工程到底在做什么？
先问一个问题：为什么要有平台工程？
你想想看，一个稍微有点规模的公司，微服务几十上百个，每个服务都有自己的配置、日志、监控、限流策略。开发同学要部署一个新服务，得先申请域名、配网关、写鉴权、搞CI/CD……一套流程下来，光环境就折腾好几天。这不是在写业务代码，这是在跟基础设施较劲。
平台工程的核心目标，说白了就一句话：给开发者提供一条“铺好的路”。让开发团队可以专注写业务代码，而不是反复造轮子、填基础设施的坑。
平台工程的三个核心目标：
- 抽象基础设施复杂度：让开发者不用关心底层是K8s还是虚拟机，只管推代码就行
- 标准化交付流程：从代码提交到上线，所有环节都有清晰、自动化的路径
- 提供可复用的能力：比如统一鉴权、统一限流、统一日志，一次接入到处可用
我在项目中遇到过一种典型的反面案例：某团队自己用Spring Cloud Gateway搭了一套网关，配置全靠硬编码，每次上线都要手动改YAML。结果有一次改错了限流参数，直接把线上流量全拦了……嗯，那天的复盘会开得格外漫长。
API网关在平台里扮演什么角色？
说到API网关，很多人第一反应就是“反向代理”、“路由转发”。对，这些是基本功。但在平台工程的体系里，API网关的职责要重得多。我把它总结为“三横一纵”的职责模型。
| 职责维度 | 具体能力 | 说明 |
|---|---|---|
| 流量入口 | 路由、负载均衡、DNS解析 | 所有外部请求的第一道关卡 |
| 安全屏障 | 鉴权、认证、IP黑白名单、WAF | 拦截非法请求，保护后端服务 |
| 治理中间层 | 限流、熔断、降级、重试、超时控制 | 防止流量冲垮后端，保障稳定性 |
| 可观测性 | 日志采集、链路追踪、Metrics上报 | 让每一次调用都有迹可循 |
说白了，API网关就是平台的「总入口+总开关+总监控」。所有流量都要经过它，所有策略都可以在它这一层统一管控。
个人习惯提醒：我建议在设计平台时，不要把API网关当做单纯的网络组件，而是把它当成「平台能力的第一分发点」。所有平台级的公共能力——比如统一鉴权、统一限流、统一日志——最好都在网关层完成，而不是让每个微服务自己搞一套。
API网关与微服务治理的关系
很多人会把API网关和微服务治理混为一谈，觉得不就是那点限流熔断吗？其实差得挺远。我给你画个图就清楚了。
看清楚了吗？API网关在平台工程里，其实是连接外部流量和内部服务治理的一座桥。它对外统一收口流量，对内对接服务注册中心、配置中心、限流组件等一系列治理设施。
实践中的职责划分
那么问题来了：哪些事该网关做，哪些事该服务自己做？
我记得有个团队跑来问我，说他们的网关里绑了几十个路由规则，每个规则还带了各自的限流策略、熔断策略、重试策略，搞得网关超级臃肿。我一看就发现问题了——他们把太多业务层的治理逻辑塞进了网关。
避坑指南：我曾经吃过亏，在网关层写了大量业务相关的路由逻辑，结果每次业务调整都要改网关配置。上线时提心吊胆，生怕改坏全局流量。
正确的做法：把网关当成「通用能力层」，只负责基础设施级别的治理。业务相关的策略（比如特定接口的降级策略、某个客户端的个性化限流），应该在服务自身或BFF层实现。
怎么分？我一般用这个原则：
- 全局通用的（所有服务都要用的）→ 放网关
- 局部特定的（只有某个服务需要的）→ 放服务自身
- 跨服务协调的（比如全局限流、全局熔断）→ 放网关或独立的治理中间件
举个例子。统一鉴权，所有接口都要校验，那就放网关。但某个订单接口的特殊降级策略——比如"下单量超过1000就返回排队提示"——这种就应该放在订单服务里，而不是在网关写死。
网关与注册中心的协同
另一个容易踩坑的点是：网关怎么感知后端服务的上下线？
很多入门方案是网关里写死服务地址列表。嗯，我早期也这么干过。结果有一次扩缩容，忘记更新网关配置，流量打到了已经下线的节点上……508错误刷了一屏。
正确的做法是：网关对接服务注册中心。比如基于Nacos、Consul或K8s Service，让网关动态感知后端服务的健康状态。一个服务挂了，网关自动摘除它，不再往那里发流量。
小技巧：我在架构设计时，习惯让网关同时支持「本地缓存+注册中心推送」两种方式。注册中心推送过来的服务列表，先在网关本地缓存一份。即使注册中心短暂不可用，网关也能根据缓存继续工作。这其实就是「高可用」的常见套路。
最后总结一下。平台工程和API网关的关系，用一句话概括：没有API网关的平台是“散装”的，没有平台思维的API网关是“裸奔”的。两者结合好了，开发者爽，运维稳，业务跑得快。结合不好，那就只能等着线上出故障再复盘了。