使用 Kubernetes 实现基础结构复原

若要实现基于基础结构的复原能力，可以使用 服务网格。 除了不更改代码的复原能力外，服务网格还提供流量管理、策略、安全性、强标识和可观测性。 你的应用程序与这些被迁移到基础设施层的操作功能实现了分离。 从体系结构上讲，服务网格由两个组件组成：控制平面和数据平面。

控制平面组件包含许多支持管理服务网格的组件。 组件清单通常包括：

• 管理接口，可以是 UI 或 API。
• 定义服务网格应如何实现特定功能的规则和策略定义。
• 对强标识和 mTLS 的证书等的安全管理。
• 用于从应用收集和聚合指标及遥测数据的指标或可观测性。

数据平面组件由代理组成，代理以透明方式注入到每个服务旁边，这称为 Sidecar 模式。 每个代理都配置为控制包含您服务的 Pod 内外的网络流量。 此配置允许将每个代理配置为：

• 通过 mTLS 保护流量。
• 动态路由流量。
• 将策略应用于流量。
• 收集指标和跟踪信息。

Kubernetes 群集的一些常用服务网格选项包括 Linkerd、Istio 和 Consul。 本模块重点介绍 Linkerd。 下图显示了数据与控制平面中的组件之间的交互：

与基于代码的方法的比较

Linkerd 的主要错误处理策略包括 重试和超时。 由于 Linkerd 具有整个群集的系统性视图，因此它可以以新的方式采用复原策略。 例如，尝试在目标服务上添加最多 20% 的额外负载。 Linkerd 的基于指标的视图允许它实时动态适应群集条件。 此方法添加另一个维度来管理群集，但不添加任何代码。

使用基于代码的方法（例如使用 Polly），可以：

• 需要猜测适合采用哪些重试和超时参数。
• 专注于特定的 HTTP 请求。

无法合理响应应用代码中的基础结构故障。 请考虑同时处理的数百个或数千个请求。 即使是指数回退（时间请求计数）的重试也可能会使服务不堪负重。

相比之下，基于基础设施的方法（如 Linkerd）无法感知应用程序的内部细节。 例如，复杂数据库事务对 Linkerd 不可见。 可以使用 Polly 防止此类事务发生故障。

在接下来的几个单元中，你将使用 Polly 和 Linkerd 为优惠券服务实现弹性。