From 8c9eec4d7fd78120db42c2a9853fbd6c5a04f131 Mon Sep 17 00:00:00 2001 From: isno Date: Sat, 28 Dec 2024 17:41:14 +0800 Subject: [PATCH] fix typo --- Observability/signals.md | 6 ++---- ServiceMesh/control-plane.md | 31 ++++++++++++++----------------- ServiceMesh/overview.md | 12 +++++++----- http/Edge-Acceleration.md | 14 ++++++++------ 4 files changed, 31 insertions(+), 32 deletions(-) diff --git a/Observability/signals.md b/Observability/signals.md index 13f87626..16aa6eac 100644 --- a/Observability/signals.md +++ b/Observability/signals.md @@ -1,4 +1,4 @@ -# 9.3 可观测数据的分类及处理 +# 9.3 遥测数据的分类与处理 业界将系统输出的数据总结为三种独立的类型：指标（metrics）、日志（logs）和链路追踪（traces），它们被称为可观测性的“三大支柱”。 @@ -28,8 +28,6 @@ Trace ID: 12345 ::: -现在，CNCF 发布的可观测性白皮书中[^1]，将系统输出的各类观测数据统一称为信号（Signals）。主要的信号除了 指标、日志、链路追踪之外又增加了性能剖析（Profiling）和核心转储（Core dump）。 - -接下来，笔者将详细介绍可观测系统中各类信号的采集、存储和分析处理设计，以及面对海量数据规模时遇到的技术挑战。 +2021 年，CNCF 发布了可观测性白皮书[^1]，又新增了性能剖析（Profiling）和核心转储（Core dump）2 种数据类型。接下来，笔者将详细介绍这 5 类遥测数据的采集、存储和分析处理，以及应对海量数据规模的技术挑战。 [^1]: 参见 https://github.com/cncf/tag-observability/blob/main/whitepaper.md \ No newline at end of file diff --git a/ServiceMesh/control-plane.md b/ServiceMesh/control-plane.md index 011e8e9a..981ded7e 100644 --- a/ServiceMesh/control-plane.md +++ b/ServiceMesh/control-plane.md @@ -1,38 +1,35 @@ # 8.4 控制平面技术：从微服务架构到单体架构 -本节，笔者继续以 Istio 的架构设计为例，讨论服务网格的控制平面设计。 +本节，笔者继续以 Istio 的架构为例，讨论控制平面的设计。 -Istio 之所以脱颖而出，最大创新在于它为微服务系统带来了前所未有的控制力： -- 以 Linkerd 代表的第一代服务网格通过 Sidercar 模式控制微服务间所有的流量； -- 以 Istio 为代表的第二代服务网格新增控制平面，控制所有的 Sidecar。于是，Istio 间接掌控了系统中的所有请求和流量。 - -自发布第一个版本以来，Istio 有着一个堪称优雅的架构设计。Istio 的整个系统分为数据面和控制面：前者通过代理组件 Envoy 负责流量处理；后者根据功能职责不同，由多个微服务（如 Pilot、Galley、Citadel、Mixer）组成。Istio 控制面组件的拆分设计，看似拥有微服务架构所有的优点：职责分离、独立部署、独立的伸缩能力。但实际场景中却没有达到理想中的设计效果，我们思考如下问题： +Istio 自发布首个版本以来，有着一套“堪称优雅”的架构设计，它的架构由数据面和控制面两部分组成，前者通过代理组件 Envoy 负责流量处理；后者根据功能职责不同，由多个微服务（如 Pilot、Galley、Citadel、Mixer）组成。 Istio 控制面组件的拆分设计看似充分体现了微服务架构的优点，如职责分离、独立部署和伸缩能力，但在实际场景中，并未实现预期的效果。 :::tip 服务网格控制面的问题 -如果业务调用异常，由于接入了服务网格。工程师首先需要排查控制面内各个组件是否正常：首先检查 pilot 是否正常工作，配置是否正常下发至 Sidecar，然后检查 Galley 组件是否正常同步服务实例信息，还需要检查 Sidecar 是否正常注入... +当业务调用出现异常时，由于接入了服务网格，工程师首先需要排查控制面内各个组件的健康状态：首先检查 Pilot 是否正常工作，配置是否正确下发至 Sidecar；然后检查 Galley 是否正常同步服务实例信息；同时，还需要确认 Sidecar 是否成功注入。 -一方面控制面的组件越多，排查问题时需要检查的故障点越多。另一方面，过多的组件设计导致部署的难度也会增加。 +一方面，控制面组件的数量越多，排查问题时需要检查的故障点也就越多。另一方面，过多的组件设计也会增加部署、维护的复杂性。 ::: -服务网格号称下一代微服务架构，用于解决微服务之间运维管理问题，但在服务网格的设计过程中，又引入了一套新的微服务架构，这岂不是“用一套微服务架构设计的系统解决另一套微服务系统的服务治理问题？”，那谁来解决 istio 系统本身的微服务架构问题呢？ +服务网格被誉为下一代微服务架构，用来解决微服务间的运维管理问题。但在服务网格的设计过程中，又引入了一套新的微服务架构。这岂不是“用一种微服务架构设计的系统来解决另一种微服务架构的治理问题”？那么，谁来解决 Istio 系统本身的微服务架构问题呢？ -在 Istio 推出三年之后，也就是 Istio 的 1.5 版本，开发团队推翻了之前控制面的设计，启用了“复古”的单体架构，引入了的统一组件 istiod，它整合了 Pilot、Citadel 和 Galley 的功能，并以单个二进制文件的形式部署。Istio 1.5 版本的架构调整，其实只是将原有的多进程设计模式转换为单进程的形式，因此，istiod 就需要承担之前组件的所有职责： +在 Istio 推出三年后，即 Istio 1.5 版本，开发团队对控制面架构进行了重大调整，摒弃了之前的设计，转而采用了“复古”的单体架构。新的统一组件 istiod 整合了 Pilot、Citadel 和 Galley 的功能，并以单个二进制文件的形式进行部署。Istio 1.5 版本的架构变化，实际上是将原有的多进程设计转换为单进程模式，因此，istiod 需要承担之前各个组件的所有职责： -- 服务发现与配置分发：从 Kubernetes 等平台获取服务信息，将路由规则和策略转换为 xDS 协议下发至 Envoy 代理。 -- 流量管理：管理流量路由规则，包括负载均衡、分流、镜像、熔断、超时与重试等功能。 -- 安全管理：生成、分发和轮换服务间的身份认证证书，确保双向 TLS 加密通信；基于角色的访问控制（RBAC）和细粒度的授权策略，限制服务间的访问权限。 -- 可观测性支持：协助 Envoy 采集运行时指标（如延迟、错误率、请求流量等），并将数据发送到外部监控系统（如 Prometheus）；支持分布式追踪系统（如 Jaeger、Zipkin 和 OpenTelemetry），帮助分析跨服务调用链路；提供访问日志和事件日志的采集功能。 -- 配置验证与管理：验证用户提交的网格配置，并将其分发到数据平面，确保一致性和正确性。 +- **服务发现与配置分发**：从 Kubernetes 等平台获取服务信息，将路由规则和策略转换为 xDS 协议下发至 Envoy 代理。 +- **流量管理**：管理流量路由规则，包括负载均衡、分流、镜像、熔断、超时与重试等功能。 +- **安全管理**：生成、分发和轮换服务间的身份认证证书，确保双向 TLS 加密通信；基于角色的访问控制（RBAC）和细粒度的授权策略，限制服务间的访问权限。 +- **可观测性支持**：协助 Envoy 采集运行时指标（如延迟、错误率、请求流量等），并将数据发送到外部监控系统（如 Prometheus）；支持分布式追踪系统（如 Jaeger、Zipkin 和 OpenTelemetry），帮助分析跨服务调用链路；提供访问日志和事件日志的采集功能。 +- **配置验证与管理**：验证用户提交的网格配置，并将其分发到数据平面，确保一致性和正确性。 :::center ![](../assets/service-mesh-arc.svg)
图 8-12 Istio 架构及各个组件 ::: -通过多进程到单进程的架构调整，Istio 的开发团队以最小的成本实现了整体运维的巨大收益： +通过将架构从多进程转为单进程，Istio 的开发团队以最小的成本显著提高了运维收益。 + - 运维配置变得更加简单，用户只需要部署或升级一个单独的服务组件； - 更加容易排查错误，因为不需要再横跨多个组件去排查各种错误； - 更加利于做灰度发布，因为是单一组件，可以非常灵活切换至不同的控制面； - 避免了组件间的网络开销，因为组件内部可直接共享缓存、配置等，也会降低资源开销； -通过上面的分析，你是否对 Istio 控制平面的拆分架构有了新的看法。看似优雅的架构设计，往往在用户落地过程中，对运维/开发人员带来了意料之外的困难。还真是顺应了一句老话：“没有完美的架构，只有最合适的架构”。 \ No newline at end of file +通过以上分析，你是否对 Istio 控制平面的拆分架构有了新的理解？看似优雅的架构设计，往往在实际落地过程中给运维和开发人员带来意料之外的困难。正如一句老话，没有完美的架构，只有最合适的架构！ \ No newline at end of file diff --git a/ServiceMesh/overview.md b/ServiceMesh/overview.md index 0ac1410c..58299b4f 100644 --- a/ServiceMesh/overview.md +++ b/ServiceMesh/overview.md @@ -1,14 +1,16 @@ # 8.5 服务网格的产品与生态 -Buoyant 公司在 2016 年发布了第一代服务网格 Linkerd，同一时期，离开 Twitter 的工程师 Matt Klein 加入了 Lyft，并开启了 Envoy 项目。第一代服务网格稳步推进的过程中，世界的另一角落，Google 和 IBM 两个巨头开始握手合作，它们联合 Lyft 启动了 Istio 项目。 +2016 年，Buoyant 公司发布了第一代服务网格 Linkerd。同一时期，离开 Twitter 的工程师 Matt Klein 加入了 Lyft，启动了 Envoy 项目。第一代服务网格稳步发展时，世界的另一角落，Google 和 IBM 两个巨头开始联手，与 Lyft 一起启动了 Istio 项目。 -2017 年 5 月，Google、IBM 和 Lyft 开源新一代的服务网格 Istio，有巨头背书以及**新增控制平面的设计理念**让 Istio 得到极大关注和发展，并迅速成为第二代服务网格的代表项目。 +Istio 的最大创新在于为微服务系统带来了前所未有的控制力： +- 以 Linkerd 为代表的第一代服务网格，通过 Sidecar 模式控制微服务间的流量； +- 以 Istio 为代表的第二代服务网格，引入了控制平面，进一步管理所有 Sidecar。于是，间接掌控了系统中的所有流量。 -## 8.5.1 Linkerd2 出击 +巨头背书、新增控制平面的设计理念让 Istio 得到极大关注和发展，并迅速成为业界实施服务网格的主流选择。 -Istio 被争相追捧的同时，作为服务网格概念的创造者 William Morgan 自然不甘心出局。 +## 8.5.1 Linkerd2 出击 -公司生死存亡之际，William Morgan 瞄准 Istio 的缺陷（过于复杂）并借鉴 Istio 的设计理念（新增控制平面），开始重新设计它们的服务网格产品。 +在 Istio 受到广泛追捧的同时，服务网格概念的创造者 William Morgan 自然不甘心出局。公司生死存亡之际，William Morgan 瞄准 Istio 的缺陷（过于复杂）并借鉴 Istio 的设计理念（新增控制平面），开始重新设计它们的服务网格产品。 Buoyant 公司的第二代服务网格使用 Rust 构建数据平面 linkerd2-proxy ，使用 Go 开发了控制平面 Conduit，主打轻量化，目标是世界上最轻、最简单、最安全的 Kubernetes 专用服务网格。该产品最初以 Conduit 命名，Conduit 加入 CNCF 后不久，宣布与原有的 Linkerd 项目合并，被重新命名为 Linkerd 2[^1]， diff --git a/http/Edge-Acceleration.md b/http/Edge-Acceleration.md index 35b89d54..9db87e63 100644 --- a/http/Edge-Acceleration.md +++ b/http/Edge-Acceleration.md @@ -2,11 +2,13 @@ CDN 技术依赖“边缘节点”缓存静态文件实现就近访问，“动态加速”技术则是通过“边缘节点”，优化 IP 路由和传输层，对动态请求进行加速。 -目前，主流的技术服务商，如 Akamai、Fastly、Amazon CloudFront 和 Microsoft Azure 等在全球多个地区部署了数量庞大的边缘服务器，构建了一个庞大的全球性加速网络。使用上述服务商提供的“动态加速”操作简单，将域名的解析记录 CNAME 到服务商提供的域名后，整个加速过程就能自动实现。操作流程大致如下： +目前，主流的技术服务商，如 Akamai、Fastly、Amazon CloudFront 和 Microsoft Azure 等在全球多个地区部署了数量庞大的边缘服务器，构建了一个庞大的全球性加速网络。使用上述服务商提供的“动态加速”操作简单，将域名的解析记录 CNAME 到服务商提供的域名后，整个加速过程就能自动实现。 + +操作流程大致如下： 1. 源站（Origin）将域名 CNAME 到 CDN 服务商提供的域名。例如，将 www.thebyte.com.cn CNAME 到 thebyte.akamai.com。 2. 源站提供一个 20KB 左右的用于探测网络质量的文件资源。 -3. 服务商在源站周边选择一批候选的转发节点（Relay Node）。 +3. 服务商在源站周边候选一批转发节点（Relay Node）。 4. 转发节点对测试资源进行下载测试，多个转发节点多路探索后，根据丢包率、RTT、路由的 hops 数等，选择出一条客户端（End Users）到源站之间的最佳路径。 :::center @@ -14,13 +16,12 @@ CDN 技术依赖“边缘节点”缓存静态文件实现就近访问，“动 图 2-24 DSA 服务网络加速原理 [图片来源](https://www.cdnetworks.com/cn/web-performance/dynamic-web-acceleration/) ::: - -根据笔者的线上数据看，使用 Akamai 加速服务后，HTTPS 请求延迟降低了 30% 右，如表 2-4 所示。 +笔者之前负责的业务曾使用过 Aakamai 加速，根据表 2-4 所示的实践结果，HTTPS 请求延迟降低了 30% 左右。 :::center 表 2-4 网络直连与使用动态加速的效果对比 ::: -客户端| 服务器| 客户端直接访问服务端延迟| 客户端使用 Akamai 加速后延迟| 效果提升 +客户端| 源站| 客户端直接访问源站的延迟| 客户端使用 Akamai 加速后延迟| 效果提升 :---|:--:|:--:|:--:|:-- 泰国,曼谷|香港|0.58s|0.44s|31% 印尼,雅加达|香港|0.57s|0.44s|31% @@ -34,7 +35,8 @@ CDN 技术依赖“边缘节点”缓存静态文件实现就近访问，“动 菲律宾,马尼拉|香港|0.46s|0.34s|36% -利用边缘服务器对请求加速，属于典型的“网络边缘代理”技术。本书第四章详细介绍了各类代理技术的原理及应用，感兴趣的读者可参阅该章了解更多技术细节。 + +通过边缘节点对请求进行动态加速，属于典型的“网络边缘代理”技术。有关各类代理技术的原理和应用，本书第 6 章进行了详细介绍，感兴趣的读者可以进一步阅读了解。 [^1]: AS（Autonomous System，自治系统）具有统一路由策略的巨型网络或网络群组，每个自治系统被分配一个唯一的 AS 号，各个 AS 之间使用 BGP 协议进行识别和通告路由，全世界最大规模的 AS 网络就是互联网。 [^2]: 笔者曾在上海使用 mtr 工具测试一个新加坡节点路由状态，数据包先到香港 AS，香港转到美国 AS，再从美国转到新加坡 AS。