From 9d611197af01c893d261cb796386991f9598aa86 Mon Sep 17 00:00:00 2001 From: isno Date: Wed, 14 Feb 2024 10:49:36 +0800 Subject: [PATCH] =?UTF-8?q?=E6=9B=B4=E6=96=B0=E5=8F=AF=E8=A7=82=E6=B5=8B?= =?UTF-8?q?=E6=80=A7?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Observability/tracing.md | 22 +++++++++++++--------- ServiceMesh/overview.md | 13 ++++++++++--- architecture/summary.md | 4 +++- container/Container-Orchestration-Wars.md | 9 +++++---- 4 files changed, 31 insertions(+), 17 deletions(-) diff --git a/Observability/tracing.md b/Observability/tracing.md index 6ed470b0..e74ad4ee 100644 --- a/Observability/tracing.md +++ b/Observability/tracing.md @@ -9,6 +9,8 @@ 分布式链路追踪诞生的标志性事件就是 Google Dapper 论文的发表。2010年4月，Benjamin H. Sigelman 等人在 Google Technical Report 上发表了《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》[^2]论文，文中详细阐述了 Google 内部分布式链路追踪系统 Dapper 的设计理念，还提出了成为后续链路追踪系统设计共识的两个基础术语 Trace（追踪）和 Span（跨度）。 +受 Dapper 思想和协议的影响，市场上开始出现大量的链路追踪项目。 + ## Trace 和 Span 一条 Trace 代表一次入口请求在 IT 系统内的完整调用轨迹及其关联数据集合。其中，全局唯一的链路标识 TraceId 是代表性的一个属性，通过 TraceId 我们才能将同一个请求分散在不同节点的链路数据准确的关联起来，实现请求粒度的“确定性关联”。 @@ -28,7 +30,7 @@ Span 代表系统中一个逻辑运行单元，Span 之间通过嵌套或者顺

Trace 和 Spans

-总结分布式链路追踪的原理就是在分布式应用的接口方法中设置一些观察点，在入口节点给每个请求分配一个全局唯一的标识 TraceId，当请求流经这些观察点时就会记录一条对应的链路日志（Span）。最后通过 TraceId 将一次请求的所有链路日志进行组装，就能还原出该次请求的链路轨迹。 +总结分布式链路追踪的原理就是在分布式应用的接口方法中设置一些观察点，在入口节点给每个请求分配一个全局唯一的标识 TraceId，当请求流经这些观察点时就会记录一条对应的链路日志（Span），最后通过 TraceId 将一次请求的所有链路日志进行组装，就能还原出该次请求的链路轨迹。 如图所示，根据拓扑图中 Span 记录的时间信息和响应结果，我们就可以定位到出错或者缓慢的服务。 @@ -39,32 +41,34 @@ Span 代表系统中一个逻辑运行单元，Span 之间通过嵌套或者顺 ## 追踪技术的核心 -实现追踪的核心技术是方法增强（通常也称为埋点，指的是在代码中插入额外的逻辑来捕获和记录执行信息）。Dapper 的论文中提出的设计原则要求方法增强必须满足应用级透明性和低开销着两个关键条件。 +与日志不同，日志的采集和业务完全隔离。链路追踪需要获取更内部的信息，链路追踪的代码就要与业务代码耦合在一起。微服务的架构已经糅杂了一堆治理 SDK，再加上链路追踪逻辑，技术复杂度对开发人员的影响可想而知。 + +链路追踪技术使用方法增强（通常也称为埋点）解决业务隔离的问题。指的是在代码中插入额外的逻辑来捕获和记录执行信息，这是实现追踪的核心技术。Dapper 的论文中提出的设计原则要求方法增强必须满足应用级透明性和低开销着两个关键条件。 - 应用级透明：开发者不需要修改业务代码或者仅需要极少的修改即可实现埋点，这意味着追踪逻辑对应用层不可见或者几乎不可见。 -- 低开销： +- 低开销：埋点操作对系统的性能影响应当尽可能小，以避免追踪逻辑本身成为系统性能的瓶颈。 +保证应用级透明有两种方式，基于服务的追踪是目前最为常见的追踪实现方式，被 Zipkin、SkyWalking、Pinpoint 等主流追踪系统广泛采用。基于服务追踪的实现思路是通过某些手段给目标应用注入追踪探针（Probe），譬如针对 Java 应用，一般就通过 Java Agent 注入。 -**2.基于服务的追踪**，基于服务的追踪是目前最为常见的追踪实现方式，被 Zipkin、SkyWalking、Pinpoint 等主流追踪系统广泛采用。基于服务追踪的实现思路是通过某些手段给目标应用注入追踪探针（Probe），譬如针对 Java 应用，一般就通过 Java Agent 注入。 +:::tip 探针 探针可以看做是一个寄生在目标服务身上的一个小型微服务系统，它一般会有自己的专用服务注册、心跳检测等功能，有专门的数据收集协议，可以把从目标系统监控得到的服务调用信息，通过另一次独立的 HTTP 或者 RPC 请求发送给追踪系统。 +::: 因此，基于服务方式的追踪系统会比基于日志的追踪消耗更多的资源，也具有更强的侵入性，而换来的收益就是追踪的精确性和稳定性都有保证，不必再依靠日志归集来传输跟踪数据。 - -**3.基于边车代理的追踪**，服务网格的专属方案，也是最理想的分布式追踪模型，边车代理对应用完全透明，有自己独立数据通道，追踪数据通过控制平面上报，无论对日志服务本身还是，都不会有依赖和干扰；它与程序语言无法，无论应用采用什么编程语言，只要它通过网络（HTTP或 gRPC）访问服务，就可以被追踪到。如果非要总结种方式的实现有什么缺点，就是边车代理本身对应用透明的原理，决定了它只能实现服务调用层面的追踪。 +**基于边车代理的追踪**，服务网格的专属方案，也是最理想的分布式追踪模型，边车代理对应用完全透明，有自己独立数据通道，追踪数据通过控制平面上报，无论对日志服务本身还是，都不会有依赖和干扰；它与程序语言无法，无论应用采用什么编程语言，只要它通过网络（HTTP或 gRPC）访问服务，就可以被追踪到。如果非要总结种方式的实现有什么缺点，就是边车代理本身对应用透明的原理，决定了它只能实现服务调用层面的追踪。 现在，市场占有率最高的 Envoy 就提供了完善的追踪功能，但没有提供自己的界面端和存储端，需要配合专门的 UI 与存储系统来使用，不过 SkyWalking、Zipkin、Jaeger 等系统都可以接受来自 Envoy 的追踪数据。 - - ## 代表性项目 在没有形成大一统标准的早期，Dapper 的思想和协议影响了大量的开源项目。受到 Dapper 的启发，Twitter 开发了自己的分布式追踪系统 Zipkin，Zipkin 是第一个被广泛采用的开源的分布式链路追踪系统，提供了数据收集、存储和查询的功能以及友好的 UI 界面来展示追踪信息。 2017年 Uber 在基于 Zipkin 思想和经验的基础上开源了 Jaeger，增加了自适应采样、提供了更加强大和灵活的查询能力等，后来 Jaeger 成为 CNCF 的托管项目，并在 2019年 成为 graduated 级别。即使在今天，Zipkin 和 Jaeger 仍然是最流行的分布式追踪工具之一。 -Zipkin 和 Jaeger 或多或少都对业务代码有侵入性，国内的工程师应该熟悉一款基于字节码注入具有无侵入性特点的 Skywalking ，这是一款本土开源的的调用链分析以及应用监控分析工具，特点是支持多种插件，UI 功能较强，接入端无代码侵入（Java Agent 技术）。 +国内的工程师应该非常熟悉 Skywalking，这是一款本土开源的的调用链分析以及应用监控分析工具，特点是支持多种插件，UI 功能较强，接入端无代码侵入（Java Agent 技术）。Skywalking 提供了自动插桩的能力，通过 Java Agent 技术在运行时不侵入地修改字节码，插入追踪代码。这种方式对业务代码完全透明，开发者无需修改任何业务逻辑即可实现埋点。 + ## Opentracing diff --git a/ServiceMesh/overview.md b/ServiceMesh/overview.md index cfb9bb7c..088843e6 100644 --- a/ServiceMesh/overview.md +++ b/ServiceMesh/overview.md @@ -1,15 +1,22 @@ # 8.2 服务网格的产品与生态 -2016年1月，Buoyant 公司发布了第一代 ServiceMesh 产品 Linkerd。初次发布的 Linkerd 以 Scala 编写，绝大部分关注点都是如何做好 proxy（代理） 并完成一些通用控制面的功能。同期专注于 proxy 领域的还有一个重量级选手 Envoy，Envoy 是 CNCF 内继 Kubernetes、Prometheus 第三个孵化成熟的项目，由 Lyft 公司基于 C++ 开发，特点为性能出色、功能丰富、生态成熟。初代的 ServiceMesh 虽然理念美好，但以 sidecar 为核心存在不少缺陷：特别是 Linkerd，其明显的资源消耗、性能影响广受诟病；其二仅限于数据层面的代理功能时，当大量部署 sidecar 以后，并没有充分考虑如何管理和控制这些 sidecar。 +2016年1月，Buoyant 公司发布了第一代 ServiceMesh 产品 Linkerd。初次发布的 Linkerd 以 Scala 编写，绝大部分关注点都是如何做好 proxy（代理） 并完成一些通用控制面的功能。同期专注于 proxy 领域的还有一个重量级选手 Envoy，Envoy 由 Lyft 公司基于 C++ 开发，特点为性能出色、功能丰富、生态成熟，是 CNCF 内继 Kubernetes、Prometheus 第三个孵化成熟的项目。初代的 ServiceMesh 虽然理念美好，但以 Sidecar 为核心存在不少缺陷，特别是 Linkerd，其明显的资源消耗、性能影响广受诟病，其二仅限于数据层面的代理功能时，当大量部署 Sidecar 以后，并没有充分考虑如何管理和控制这些 Sidecar。 于是，第二代 Service Mesh 应运而生。2017年5月，Google、IBM、Lyft 宣布新一代的服务网格 Istio 开源，有巨头背书以及**新增控制平面的设计理念**让 Istio 得到极大关注和发展，并迅速成为 ServiceMesh 的代表产品。 +Istio 最大的创新在于它为 ServiceMesh 带来前所未有的控制力：以Sidercar 方式部署的 ServiceMesh 控制服务间所有的流量，Istio 增加控制面板来控制系统中所有的 Sidecar。以此，Istio 便控制系统中所有请求的发送，也即控制了所有的流量。 +
- +

Linkerd 架构

+
+ +

Linkerd 架构

+
+ ## xDS 暂且不论 istio 和 linkerd 到底是谁 ServiceMesh 的赢家。 @@ -32,7 +39,7 @@ Envoy 倒成了偷偷领先的玩家，成为了云原生时代数据平面的 主打世界上最轻、最简单、最安全的Kubernetes服务网格 -Istio 被争相追捧的同时，作为 service mesh 概念的缔造者 Buoyant 公司自然不甘心出局，使用Rust构建数据平面 linkerd2-proxy ，使用Go构建控制平面 痛定思痛 使用 Rust 开发了数据面产品（） ，使用 Go 开发了 控制平面 Conduit，主打轻量化，Buoyant 的第二代ServiceMesh 产品最初是以 Conduit 命名，在 Conduit 加入 CNCF 后不久，宣布与原有的 Linkerd 项目合并，被重新命名为Linkerd 2[^1]。 +Istio 被争相追捧的同时，作为 Service Mesh 概念的缔造者 Buoyant 公司自然不甘心出局，公司生死存亡之际，痛定思痛之后使用 Rust 构建数据平面 linkerd2-proxy ，使用 Go 开发了控制平面 Conduit，主打轻量化，Buoyant 的第二代ServiceMesh 产品最初是以 Conduit 命名，在 Conduit 加入 CNCF 后不久，宣布与原有的 Linkerd 项目合并，被重新命名为Linkerd 2[^1]。
diff --git a/architecture/summary.md b/architecture/summary.md index aeb926e1..de493c98 100644 --- a/architecture/summary.md +++ b/architecture/summary.md @@ -1,6 +1,8 @@ # 第一章：云原生技术概论 -云原生是一个很抽象的概念，解读云原生往往用抽象的解释解释抽象。话有些绕，但我想你能理解它的意思：用“不可变基础设施”、“声明式API”、“容器”这样的描述会让云原生的概念更加难以理解。这一章，容我换一种方式解读：用朴素的话从需求的背景、发展的历史，讨论这期间诞生的各类技术以及它们试图解决的问题的方式去解读。思想先行，技术随后，让我们一起洗洗脑子**从解决问题的角度出发真正理解云原生技术的变革**。 +云原生是一个很抽象的概念，解读云原生往往用抽象的解释解释抽象。话有些绕，但我想你能理解它的意思：用“不可变基础设施”、“声明式API”、“容器”这样的描述会让云原生的概念更加难以理解。 + +这一章，容我换一种方式解读：用朴素的话从需求的背景、发展的历史，讨论这期间诞生的各类技术以及它们试图解决的问题的方式去解读。思想先行，技术随后，让我们一起洗洗脑子**从解决问题的角度出发，真正理解云原生技术的变革**。
diff --git a/container/Container-Orchestration-Wars.md b/container/Container-Orchestration-Wars.md index 40800cf5..5b5656e3 100644 --- a/container/Container-Orchestration-Wars.md +++ b/container/Container-Orchestration-Wars.md @@ -1,7 +1,8 @@ # 7.1 容器编排之争 +**容器技术的兴起源于 PaaS 技术的普及**。 -**容器技术的兴起源于 PaaS 技术的普及**，在云计算早期的 IaaS 阶段虚拟机还是太过于笨重，每一台虚拟机都需要消耗CPU、内存等计算资源才能支撑应用的运行，即便应用再小，系统的开销都是固定的成本。在 IaaS 时代，云计算厂商一直思考的一个问题是如何充分利用资源，这个问题在云计算进入 PaaS 时代找到了答案。 +在云计算早期的 IaaS 阶段，虚拟机还是太过于笨重，每一台虚拟机都需要消耗CPU、内存等计算资源才能支撑应用的运行，即便应用再小，系统的开销都是固定的成本。在 IaaS 时代，云计算厂商一直思考的一个问题是如何充分利用资源（赚更多的钱），这个问题直到云计算进入 PaaS 时代找到了答案。 2013 年开始，云计算正式进入了 PaaS 时代，**在 PaaS 时代，云计算所销售的单元从虚拟机变成了应用运行平台，云厂商提供的服务更多，资源利用率自然也更高**。 @@ -29,11 +30,11 @@ Cloud Foundry 为每一种主流的语言都定义了一套打包的方式，开 ## 3. Kubernetes 入场 -每一波技术浪潮都会带来新的机会，科技的进步与商机是一对相辅相成的孪生兄弟。Docker 项目利用自己创新的 Docker Image 瞬间爆红，众多厂商也从中发现商机，开始围绕容器编排做一些思考和布局，这其中就包括云计算概念的最早提出者 Google 公司。 +每一波技术浪潮都会带来新的机会，科技的进步与商机是一对相辅相成的孪生兄弟。 -虽然 Google 公司名声显赫，有强大的技术实力和资金实力，但在当时提到云计算，人们首先想到的却是 AWS，Google 也一直想法设法扭转局面，随着 Docker 的成功，他们从大火的容器市场看到了新的机会。 +Docker 项目利用自己创新的 Docker Image 瞬间爆红，众多厂商也从中发现商机，开始围绕容器编排做一些思考和布局，这其中就包括云计算概念的最早提出者 Google 公司。虽然 Google 公司名声显赫，有强大的技术实力和资金实力，但在当时提到云计算，人们首先想到的却是 AWS，Google 也一直想法设法扭转局面，随着 Docker 的成功，他们从大火的容器市场看到了新的机会。 -Google 对容器也算知根知底，2007 年提交了 cgroup 到 Linux 内核，如今已经演变成容器运行时的基础。**2008 年 PaaS 平台 GAE 就已经采用了 LXC，并且开发了一套进行容器编排和调度的内部工具，也就是 Kubernetes 的前身 -- Borg**。凭借多年运行 GCP（Google Cloud Platform，Google云端平台）和 Borg 的经验，使得 Google 非常认可容器技术，也深知目前 Docker 在规模化使用场景下的不足。如果 Google 率先做好这件事不仅能让自己在云计算市场扳回一局，而且也能抓住一些新的商业机会。比如，在 AWS 上运行的应用有可能自由地移植到 GCP 上运行，这对于 Google 的云计算业务无疑极其有利。 +Google 对容器知根知底，2007 年提交了 cgroup 到 Linux 内核，如今已经演变成容器运行时的基础。**2008 年 PaaS 平台 GAE 就已经采用了 LXC，并且开发了一套进行容器编排和调度的内部工具，也就是 Kubernetes 的前身 -- Borg**。凭借多年运行 GCP（Google Cloud Platform，Google云端平台）和 Borg 的经验，使得 Google 非常认可容器技术，也深知目前 Docker 在规模化使用场景下的不足。如果 Google 率先做好这件事不仅能让自己在云计算市场扳回一局，而且也能抓住一些新的商业机会。比如，在 AWS 上运行的应用有可能自由地移植到 GCP 上运行，这对于 Google 的云计算业务无疑极其有利。 为了使 Google 能够抓住这次机会，2013 年夏天，Kubernetes 联合创始人 Craig McLuckie、Joe Beda 和 Brendan Burns 开始讨论借鉴 Borg 的经验进行容器编排系统的开发。Kubernetes 项目获批后，Google 在 2014 年 6 月的 DockerCon 大会上正式宣布将其开源，在云计算失去先机的 IT 界的领导者和创新者再次王者归来，容器编排的竞赛正式拉开帷幕。