diff --git a/ServiceMesh/control-plane.md b/ServiceMesh/control-plane.md index 0e68caac..93150022 100644 --- a/ServiceMesh/control-plane.md +++ b/ServiceMesh/control-plane.md @@ -2,7 +2,9 @@ 本节，笔者继续以 Istio 的架构为例，探讨控制平面的设计。 -Istio 自发布首个版本以来，有着一套“堪称优雅”的架构设计，它的架构由数据面和控制面两部分组成，前者通过代理组件 Envoy 负责流量处理；后者根据功能职责不同，由多个微服务（如 Pilot、Galley、Citadel、Mixer）组成。 Istio 控制面组件的拆分设计看似充分体现了微服务架构的优点，如职责分离、独立部署和伸缩能力，但在实际场景中，并未实现预期的效果。 +Istio 自发布首个版本以来，有着一套“堪称优雅”的架构设计，它的架构由数据面和控制面两部分组成，前者通过代理组件 Envoy 负责流量处理；后者根据功能职责不同，由多个微服务（如 Pilot、Galley、Citadel、Mixer）组成。 + +Istio 控制面组件的拆分设计看似充分体现了微服务架构的优点，如职责分离、独立部署和伸缩能力，但在实际场景中，并未实现预期的效果。 :::tip Isito 控制平面的问题 当业务调用出现异常时，由于接入了服务网格，工程师首先需要排查控制面内各个组件的健康状态：首先检查 Pilot 是否正常工作，配置是否正确下发至 Sidecar；然后检查 Galley 是否正常同步服务实例信息；同时，还需要确认 Sidecar 是否成功注入。 @@ -10,7 +12,7 @@ Istio 自发布首个版本以来，有着一套“堪称优雅”的架构设 一方面，控制面组件的数量越多，排查问题时需要检查的故障点也就越多。另一方面，过多的组件设计也会增加部署、维护的复杂性。 ::: -服务网格被誉为下一代微服务架构，用来解决微服务间的运维管理问题。但在服务网格的设计过程中，又引入了一套新的微服务架构。这岂不是“**用一种微服务架构设计的系统来解决另一种微服务架构的治理问题**”？那么，谁来解决 Istio 系统本身的微服务架构问题呢？ +服务网格被誉为下一代微服务架构，用来解决微服务间的运维管理问题。但在服务网格的设计过程中，又引入了一套新的微服务架构，这岂不是**用一种微服务架构设计的系统来解决另一种微服务架构的治理问题**。那么，谁来解决 Istio 系统本身的微服务架构问题呢？ 在 Istio 推出三年后，即 Istio 1.5 版本，开发团队对控制面架构进行了重大调整，摒弃了之前的设计，转而采用了“复古”的单体架构。组件 istiod 整合了 Pilot、Citadel 和 Galley 的功能，以单个二进制文件的形式部署，承担起之前组件的所有职责： diff --git a/ServiceMesh/data-plane.md b/ServiceMesh/data-plane.md index 9cd5b99a..38b66425 100644 --- a/ServiceMesh/data-plane.md +++ b/ServiceMesh/data-plane.md @@ -116,9 +116,9 @@ Chain ISTIO_REDIRECT (2 references) 通过 iptables 劫持流量，转发至边车代理后，边车代理根据配置接管应用程序之间的通信。 -传统的代理（如 HAProxy 或 Nginx）依赖静态配置文件来定义资源和数据转发规则，而 Envoy 则几乎所有配置都可以动态获取。Envoy 将代理转发行为的配置抽象为三类资源：Listener、Cluster 和 Router，并基于这些资源定义了一系列标准数据面 API，用于发现和操作这些资源。这套标准数据面 API 被称为 xDS。 +传统的代理（如 HAProxy 或 Nginx）依赖静态配置文件来定义资源和数据转发规则，而 Envoy 则几乎所有配置都可以动态获取。Envoy 将代理转发行为的配置抽象为三类资源：Listener、Cluster 和 Router，并基于这些资源定义了一系列标准数据面 API，用于发现和操作这些资源，这套标准数据面 API 被称为 xDS。 -xDS 的全称是“x Discovery Service”，这里的 “x” 指的是表 8-1 中的协议族。 +xDS 的全称是“x Discovery Service”，“x” 指的是表 8-1 中的协议族。 :::center 表 8-1 xDS v3.0 协议族