第 10 章：前沿服务：断路器和 API 网关

本章深入分析云原生架构中的断路器与 API 网关模式，阐释其在提升系统弹性与安全性方面的关键作用，并介绍 Sidecar 与服务网格等现代实现方式。

本章要点

本章将围绕服务端交互展开，重点介绍断路器、API 网关、Sidecar 和服务网格等模式。通过实际场景和架构图，帮助读者理解这些模式在云原生系统中的应用价值。

  • 服务端交互模式
  • 断路器
  • API 网关
  • Sidecar 与服务网格

在第 8 章开始，我们已讨论服务间的交互，聚焦动态路由和服务发现。客户端如何找到并访问依赖服务已介绍完毕，接下来将重点讲解服务端的基本设计模式。

图 10.1 就像客户端可以并且应该应用某些模式，以便在交互中充当良好的参与者一样，服务端也应当如此。这些就是本章要介绍的模式。
图 10.1 就像客户端可以并且应该应用某些模式，以便在交互中充当良好的参与者一样，服务端也应当如此。这些就是本章要介绍的模式。

作为服务开发者，你需要解决如下问题：

  • 防范重试风暴和拒绝服务攻击
  • 版本升级与流量分配
  • 授权与认证
  • 监控与日志记录

本章将重点介绍断路器和 API 网关两种模式，并在最后介绍 Sidecar 的最新实现方式。

断路器模式

断路器在软件中的作用类似于家庭电路保护，防止服务因过载而崩溃。其核心思想是：当服务故障率过高时，断路器会自动切断流量，待服务恢复后再逐步放开流量。

软件中的断路器原理

断路器有三种状态：闭合（Closed）、打开（Open）、半开（Half-Open）。状态转换由故障率和恢复情况驱动。

  • 闭合：流量正常通过
  • 打开：流量被阻断，服务自我修复
  • 半开：允许少量流量测试服务恢复情况
图 10.2 通过三个状态对断路器的操作进行建模，并定义它们之间相互转换的条件或者事件。当断路器闭合时，流量可以自由通过。当断路器断开时，请求将无法到达服务。半开状态是一种瞬时状态，表示断路器可以被重置为闭合状态。
图 10.2 通过三个状态对断路器的操作进行建模，并定义它们之间相互转换的条件或者事件。当断路器闭合时，流量可以自由通过。当断路器断开时，请求将无法到达服务。半开状态是一种瞬时状态，表示断路器可以被重置为闭合状态。

断路器的使用能显著减少客户端等待响应的时间，提升系统整体健康度。

断路器对交互的影响

下图展示了服务故障时，断路器对客户端体验的影响：

  • 无断路器：客户端长时间等待响应
  • 断路器闭合：偶尔等待，影响较小
  • 断路器打开：客户端立即收到错误响应，减少等待时间
图 10.3 当服务不可用时（由于网络中断、服务本身出现问题或者其他问题），断路器的主要优点之一是可以大大减少等待响应所浪费的时间。
图 10.3 当服务不可用时（由于网络中断、服务本身出现问题或者其他问题），断路器的主要优点之一是可以大大减少等待响应所浪费的时间。

断路器实现示例（文字描述）

以 Java Spring 框架为例，断路器通常通过注解方式实现。例如，在 PostsService 类的 getPostsByUserId 方法前添加断路器注解，Spring 会自动拦截请求并实现断路器逻辑。具体代码可参考 Hystrix 官方文档或 Spring Cloud 示例。

断路器的配置项包括故障率阈值、最小故障数量、打开状态持续时间等。实际项目中可根据业务需求灵活调整。

压力测试与效果分析

在 Kubernetes 集群中部署断路器后，通过压力测试工具（如 JMeter）模拟网络中断和恢复，观察断路器对服务恢复速度和错误率的影响。测试结果表明，断路器能有效缩短恢复时间，减少错误积压。

相关帖子服务版本帖子服务版本初次恢复时间完全恢复时间
简单重试无断路器9 分钟12-13 分钟
简单重试断路器保护1-2 分钟4-5 分钟
表 1: 断路器压力测试结果对比

断路器不仅能防止重试风暴，还能提供过载保护和故障隔离。

回退机制

断路器支持回退方法，当主方法失败时自动返回预置内容。例如，服务不可用时返回缓存数据或默认响应，提升用户体验和系统弹性。

API 网关模式

API 网关作为服务前端，统一处理身份认证、限流、加密、日志等功能，简化服务开发并提升安全性和可维护性。

API 网关的作用

  • 身份认证与授权
  • 数据加密与证书管理
  • 限流与过载保护
  • 访问日志与审计

API 网关可与外部身份管理系统（如 LDAP）集成，实现企业级统一控制。

图 10.8 API 网关位于所有服务的前面，是配置和执行策略的地方。
图 10.8 API 网关位于所有服务的前面，是配置和执行策略的地方。

云原生架构下的 API 网关

随着微服务数量激增，分布式 API 网关成为主流。每个服务实例前都可部署网关，实现分布式流量管理和策略执行。

图 10.9 你可以将网关视为一个逻辑实体，是管理所需要的。但是对于云原生架构来说，网关的实现最好是分布式的。
图 10.9 你可以将网关视为一个逻辑实体，是管理所需要的。但是对于云原生架构来说，网关的实现最好是分布式的。

以 Netflix Zuul 为例，API 网关可嵌入服务进程或以独立进程运行，支持动态路由、监控、弹性和安全等功能。

Sidecar 与服务网格

Sidecar 模式

Sidecar 是与主服务并行运行的独立进程，常见于 Kubernetes Pod 内。主服务与 Sidecar 通过本地网络通信，实现语言无关、松耦合的分布式网关功能。

图 10.10 分布式网关作为每个服务的 sidecar 运行。在 Kubernetes 中，这是通过在单个 Pod 中运行两个容器来实现的，一个是主服务，另一个是网关 sidecar。
图 10.10 分布式网关作为每个服务的 sidecar 运行。在 Kubernetes 中，这是通过在单个 Pod 中运行两个容器来实现的，一个是主服务，另一个是网关 sidecar。

Envoy 是主流的 Sidecar 实现，既可作为服务端网关，也可作为客户端代理，支持重试、断路器、限速、负载均衡等多种模式。

服务网格与控制平面

服务网格由大量 Sidecar 代理组成，并通过控制平面统一管理配置、证书和策略。Istio 是最流行的服务网格解决方案之一，支持自动注入 Sidecar、策略执行和可观察性。

图 10.13 服务网格将 sidecar 和控制平面汇集在一起进行管理。
图 10.13 服务网格将 sidecar 和控制平面汇集在一起进行管理。

总结

  • 服务端交互需采用断路器、API 网关等模式提升弹性和安全性。
  • 断路器能有效防止服务过载和重试风暴，支持回退机制提升系统可用性。
  • API 网关统一处理认证、限流、加密和日志，简化服务开发和运维。
  • Sidecar 和服务网格实现分布式网关和代理，支持自动化管理和策略执行。
  • 云原生架构下，服务网格已成为提升系统可靠性和可维护性的关键技术。

参考文献

  1. Hystrix 官方文档 - github.com
  2. Spring Cloud 官方文档 - spring.io
  3. Envoy 官方网站 - envoyproxy.io
  4. Istio 官方文档 - istio.io
  5. Zuul 官方文档 - github.com
发布于: 2025/09/26 • 最后更新: 2025/09/29 • 字数: 2031 • 阅读时间: 5 mins

文章导航

独立页面

这是书籍中的独立页面。

书籍首页

评论区