架构师的登山之路｜第十站：API 网关和中间件——微服务世界里的基建

当你开始上微服务这座山时，很多人第一反应是：服务怎么拆、代码怎么写、框架怎么选。
但真正决定系统“跑不跑得起来、稳不稳得住、好不好扩展”的，往往是那些在背后默默工作的基础设施：API 网关 和各类 中间件。

如果把微服务看成一座城市里分散的店铺，那么：

• API 网关 就是城市的「高速路收费站 + 总入口」；
• 中间件 则是水电煤、路网和管道等基础设施。

这一站，我们就从架构师视角，系统地梳理：

• 为什么微服务一定绕不开网关和中间件；
• API 网关到底在架构里扮演什么角色；
• 中间件有哪些类型、分别解决什么问题；
• 常见落地方案和选型思路；
• 架构师在这一层需要做哪些决策与约束。

---

一、为什么微服务绕不开 API 网关和中间件？

很多团队从单体系统往微服务演进时，会经历类似的阶段：

1. 先把一个大应用拆成多个服务（user-service、order-service、product-service…）；
2. 每个服务单独部署，前端或 App 直接调用这些服务的 HTTP 接口；
3. 服务数量越来越多后，会遇到一堆痛点：

• 前端 / 客户端要维护 很多服务地址，环境一多就更乱；
• 每个服务都得单独做认证、鉴权、限流、日志，重复造轮子；
• 想做灰度发布、接口版本管理、AB 实验，不知道在哪里“落刀”；
• 内部服务之间的通信越来越复杂，耦合度飙升，很难统一治理。

这时你就会发现：
没有一个统一的“入口”和“粘合层”，微服务只是“很多小服务的堆砌”，而不是一个有机的系统。

• 统一入口 —— 由 API 网关 来扛；
• 统一粘合与基础能力 —— 由各种 中间件 来支撑。

---

二、什么是 API 网关？——所有流量的总入口

2.1 API 网关的角色

API 网关（API Gateway） 是所有客户端请求进入后端系统的统一入口，它处在：

客户端（浏览器 / App / 小程序 / 第三方）
→ API 网关
→ 内部微服务集群

这一跳上。

你可以把它理解成 “流量控制中心 + 安全检查站 + 接口聚合层”。

2.2 API 网关的核心职责

常见的核心能力包括：

1. 统一路由与服务发现

• 根据 URL、Header、Host 等规则，把请求转发到正确的微服务；
• 支持按版本、按租户、按地域做路由分发；
• 和服务注册中心联动，实现动态发现与负载均衡。

2. 统一认证与鉴权

• 登录态校验（如 JWT、Session、OAuth2）；
• 权限控制（角色、资源、租户、白名单等）；
• 防重放、防篡改（签名校验、时间戳、Nonce 等）。

3. 限流、熔断与降级

• 为不同的 API / 客户端 / 调用方设置 QPS 限制；
• 在后端服务异常时进行熔断与快速失败；
• 在高压场景下对部分低优先级接口做降级。

4. 协议与数据转换

• HTTP ↔ gRPC、WebSocket、内部自定义协议；
• Header / Body 的添加、修改、脱敏；
• 统一响应格式封装，前端开发体验更好。

5. 接口聚合与编排

• 一个前端请求需要多个服务数据时，在网关层进行聚合；
• 减少前端多次调用，降低网络开销。

6. 安全与防护

• 防止恶意扫描、暴力请求、简单 DDOS；
• 黑白名单、IP 访问控制、CORS 控制等。

7. 日志与观测

• 统一记录访问日志、慢接口、错误码分布；
• 为链路追踪打好入口埋点。

2.3 常见 API 网关选型

常见的技术选项包括：

• 基于 Nginx 的网关方案：OpenResty、Lua 脚本等；
• 专用网关产品：Kong、APISIX、Tyk 等；
• 基于 Java 生态的：Spring Cloud Gateway、Zuul（老）、Gateway + Nacos；
• 云厂商托管：各家云 API 网关服务等。

架构师在选型时，通常关注几个维度：

• 性能与可扩展性；
• 插件生态与可定制性；
• 和现有技术栈的契合度（K8s / Service Mesh / Spring Cloud 等）；
• 运维复杂度与可观测性。

---

三、什么是中间件？——串联微服务的“基础设施”

如果说网关是 对“入口流量”负责，那中间件则是：

让服务和服务之间 能沟通、能协作、能观测、能治理 的那一层。

3.1 中间件可以怎么分类？

从能力维度看，中间件大致可以分为：

1. 消息队列中间件（异步解耦）

常见如：Kafka、RabbitMQ、RocketMQ、Pulsar 等。

主要解决：

• 服务之间的异步通信（订单创建 → 发送“订单创建事件” → 其他服务订阅）；
• 削峰填谷，保护下游不被瞬时流量打垮；
• 支持可靠投递、顺序消息、事务消息等复杂场景。

2. 缓存中间件（读写加速）

常见如：Redis、Memcached。

主要用途：

• 缓解数据库压力，提供毫秒级读取能力；
• 承载热点数据（商品详情、配置、排行榜等）；
• 实现分布式锁、幂等控制、会话存储等。

3. 配置中心与注册中心（服务治理）

如：Nacos、Consul、Eureka、Zookeeper 等。

• 注册中心：
  • 服务启动时自动注册自身地址；
  • 其他服务通过注册中心发现并调用它；
  • 支持健康检查、自动摘除异常实例。
• 配置中心：
  • 配置信息集中管理（数据库连接、开关、阈值等）；
  • 支持动态刷新，无需重启服务。

4. 日志、指标与链路追踪中间件（可观测性）

如：ELK/EFK、Prometheus、Grafana、SkyWalking、Jaeger 等。

• 日志采集与检索；
• 指标监控（QPS、RT、错误率等）；
• 分布式链路追踪，定位“到底哪一跳慢了 / 挂了”。

5. 任务调度与批处理中间件

如：XXL-JOB、Quartz、自研调度平台等。

• 定时任务管理、分布式调度；
• 重试策略、失败告警等。

可以这样理解：
中间件负责“横向打通”和“非功能性需求”，让微服务在可靠、高效、有治理能力的基础上运行。

---

四、API 网关 vs 服务网格：谁负责什么？

在今天的云原生环境里，很多人会问另一个问题：

有了 Service Mesh（服务网格），还需要 API 网关吗？

简单区分一下两个角色：

• API 网关：偏「南北向流量」（外部 → 内部）。

  • 面向客户端；
  • 负责认证鉴权、协议转换、限流、接口聚合等。

• 服务网格（如 Istio、Linkerd）：偏「东西向流量」（服务 ↔ 服务）。

  • 通过 Sidecar 代理，接管服务间通信；
  • 负责熔断、重试、流量镜像、细粒度路由等。

常见实践是：

• 入口流量 → 先经 API 网关，再由服务网格进行服务间治理；
• 网关与服务网格配合使用，而不是互相取代。

对于很多中小团队，暂时不引入 Service Mesh 也是常态，此时：

• 网关 + 注册中心 + 客户端负载均衡
  仍然是一个性价比很高的组合。

---

五、典型实践：一个电商系统里网关和中间件怎么配合？

以一个简化的电商场景为例：

5.1 请求链路示例

1. 用户在 App 里点击「提交订单」；
2. 请求到达 API 网关：
   • 校验身份与权限；
   • 做限流与风控基本策略；
   • 把请求转发到 order-service；
3. order-service：
   • 通过 Redis 读库存缓存；
   • 通过数据库写入订单数据；
   • 通过 消息队列（Kafka/RocketMQ） 发送“订单创建事件”；
4. 订阅“订单创建事件”的服务：
   • inventory-service 扣减库存；
   • coupon-service 冻结优惠券；
   • notify-service 发送短信 / 站内信；
5. 整个调用链路：
   • 被接入 链路追踪系统（如 SkyWalking） 记录；
   • 日志统一进入 日志平台（ELK / Loki）；
   • 指标统一上报到 监控系统（Prometheus/Grafana）。

5.2 架构师需要关注什么？

• 哪些调用必须同步，哪些可以转成异步事件；
• 哪些读路径必须走缓存，如何防止缓存击穿、雪崩；
• 网关限流策略如何设计：按 IP / 用户 / 客户端 / 接口维度；
• 出现异常时，哪里可以快速熔断，哪里需要降级兜底；
• 日志与链路信息是否足够支撑排障。

---

六、架构师在网关和中间件上的决策清单

6.1 API 网关层面

1. 选型与定位

• 你们是偏云原生（K8s + Ingress）还是偏传统 VM / Spring Cloud？
• 网关需要支持哪些协议（HTTP/gRPC/WebSocket）？
• 是否需要插件扩展能力（Lua、Filter、自定义插件）？

2. 路由与版本管理

• 如何划分「外部 API」与「内部管理接口」；
• 接口版本（v1/v2）的路由策略；
• 多环境（dev/test/stage/prod）如何隔离与切换。

3. 安全与风控策略

• 登录方式（JWT / Session / OAuth2）；
• 接口是否需要签名验证、防重放；
• 对外开放的第三方接口如何做限流和配额控制。

4. 高可用与扩展性

• 网关本身如何做到多实例部署、负载均衡；
• 日志与监控是否覆盖网关这一层；
• 出现网关故障时，有没有旁路机制。

6.2 中间件层面

1. 消息队列

• 使用场景边界：哪些是“必须同步”的，哪些可以异步；
• 消息可靠性要求（至少一次、至多一次、幂等策略）；
• 消息堆积、消费延迟超标时的应对策略。

2. 缓存

• 缓存粒度（单字段、整行、整页面）；
• 失效策略与更新策略（主动更新 / 被动过期）；
• 针对穿透、击穿、雪崩的防护（预热、互斥锁、降级等）。

3. 配置与注册中心

• 配置变更的审批与发布流程；
• 灰度发布时配置和路由的配合；
• 健康检查与自动摘除异常实例策略。

4. 日志与观测

• 统一日志格式（traceId、spanId、userId 等）；
• 错误分类与告警阈值；
• 对关键链路的「SLA 指标」设定。

---

七、常见误区：API 网关和中间件别这么用

7.1 把网关当成「大型业务服务」来写

• 在网关里写大量业务逻辑，甚至做复杂事务；
• 导致网关变成新的“单体”，每次改动都牵扯巨大。

正确姿势：
网关尽量只做「跨服务通用能力」，业务逻辑留给各服务自己处理。

7.2 过度依赖单一中间件

• 所有异步需求都上同一个 MQ；
• 所有缓存都堆在一个 Redis 实例里，不做分拆与隔离。

后果：
某一个中间件挂了，整个系统“牵一发动全身”。

7.3 只会上线，不会上监控

• 网关部署了、MQ 用上了、Redis 接入了；
• 但没有日志检索、没有指标监控、没有可视化报警。

结果：
出了问题，只能 SSH 上去看 log，一层一层人肉排查。

---

八、小结：基建打牢，微服务才有底气

这一站，我们从「基建视角」重新看了微服务：

• API 网关：
  统一入口，负责流量调度、安全防护、限流熔断、协议转换与接口聚合；
• 中间件：
  消息、缓存、配置、注册、日志、监控、调度……
  让服务与服务之间真正“可沟通、可观测、可治理”。

对架构师来说，关键不只是会用某个产品，而是要想清楚：

• 在你的业务里，哪些问题交给网关来解决，哪些问题交给中间件来解决；
• 不同中间件之间的边界和协作方式；
• 在扩展、稳定和成本之间，怎么做出平衡。

只有当基础设施打牢了，服务拆得多一点、复杂一点，团队才有底气。

---

下一站预告：三把标尺拆微服务

基础设施铺好之后，我们就可以回到很多人最关心的问题：微服务到底要不要拆、拆到什么程度？

下一站，我们将从三个角度给出一套可落地的判断标尺：

1. 领域边界：业务领域模型如何划分服务边界；
2. 团队边界：组织结构如何影响服务拆分；
3. 演进节奏：系统成长到什么阶段，需要怎样的拆分力度。

敬请期待《架构师的登山之路｜第十一站：微服务要不要拆、怎么拆？三把标尺帮你判断》。