CloudWeGo Study Group 是由 CloudWeGo 社区建议的学习小组，开展以 30 天为一期的源码解读和学习活动，协助新成员融入社区圈子，和社区 Committer 互动沟通，并学习上手 CloudWeGo 几大结构项目。现在 CSG 第四期—— CloudWeGo 事务实践事例解读现已正式发动！

本期活动期间将会组织 4 期直播共享，主题分别为：

• Bookinfo——根据 CloudWeGo 重写 Istio 经典 demo
• Open Payment Platform——根据 CloudWeGo 完结 API Gateway
• EasyNote——CloudWeGo 生态入门
• BookShop——从上手电商到上手CloudWeGo

本文为 CSG 第四期榜首场直播中字节跳动根底架构研制工程师胡文共享内容。

回放链接：meetings.feishu.cn/s/1ipd8ih05…

一、嘉宾介绍

本期共享的内容主要分为以下四个部分：

用 Hertz 和 Kitex 重写经典的 Bookinfo 项目，展现工程规划、技能选型，再由浅入深展现用全链路泳道来完结灰度发布等场景。

1. 工程规划介绍

2. 技能选型介绍

3. 全链路泳道介绍

4. Proxyless 与 ServiceMesh

---

咱们晚上好，十分感谢咱们能够参与我的共享。这次共享主题是 Bookinfo —— 根据 CloudWeGo 这套技能栈怎样去重写 Istio 最经典的一个 demo 应用。 整个这次共享会分为 4 个章节：

• 榜首章节会简略介绍一下这个项意图工程规划；
• 第二章节介绍咱们做这个项意图技能选型的思路；
• 第三章节是咱们这个项目最中心的要完结的才能，也是这个 demo 的中心目标：运用 CloudWeGo 这套技能栈帮咱们去演示怎样去做一个全链路的泳道；
• 第四章节会做一些技能上的延伸的评论，便是 Proxyless 与 ServiceMesh 形式的一些考虑。

二、工程规划介绍

项目介绍

首要介绍一下项目，Bookinfo 是 Istio 官方供给的经典 demo 应用，它的意图是演示 Istio 的各式各样特性。当然咱们意图其实也是相似的：咱们期望运用 CloudWeGo 技能栈来重写这个 demo，而且根据 CloudWeGo 自身供给的技能栈，跟生态怎样做结合，去演示怎样满足微服务场景上的需求。这儿也放了咱们项意图地址，咱们感兴趣能够点击看一下。

项目地址：github.com/cloudwego/b…

架构规划

全体的架构规划和 Bookinfo 保持一致，从下图自上往下看，首要上面会有一层操控面，操控面是直接复用 Istio 的操控面，便是 Istiod；从左往右，左边会有一个进口网关，右边便是咱们 Bookinfo 的主体的一个微服务的拆分。首要左边的一个服务是 Producpage，它担任接纳外部的 HP 恳求流量，然后去做相应的页面出现，以及相应接口的聚合。后面会拆分几个服务，一个是 Reviews，而 Reviews 他会去调用 Ratings 服务去获取书评的评分，然后还拆分了 Details 服务， Details 服务便是去把一个数的详情信息做一个展现。

图上咱们也依照流量的示意图画了流量是怎样是走向的，分两种情况，由于 Bookinfo 最主要是 demo 下全链路泳道，所以咱们会有两种类型的流量，一种是带染色标识的流量，咱们会走到一个像紫色的这条带了流量染色标识的。首要它经过咱们的进口网关，它会在进口网关一致做一层流量的染色。后面的一切的恳求都会带上相应的 baggage。这边 baggage 咱们现在是经过 OpenTelementry 的 changing 才能帮咱们主动去透传的。 下流的服务都会集成 Kitex 的 xDS 套这套 SDK，在 Client 做路由的时分，就会精准地把流量依照泳道的路由规矩，把流量打到详细的某个服务实例版别上。比方紫色这条，它会精准地打到 Reviews v2上，也会继续往下打到 Ratings v2。 假如它没有带染色标识，它是一个正常恳求的话，咱们的泳道规矩界说正常的它会正是会在 v1 和 v3 版别做之间做一个 Round-robin 轮询，也会去调用咱们的 Details。Ratings 这边，是让它固定去恳求 v1 版别的服务，能够看到，每个 Productpage 或 Reviews，都集成了 xDS 的库，它会跟操控面 Istiod 树立 xDS 的长链接，在 Istio 操控台上能够去装备路由服务管理的规矩，经过 xDS 通道动态地下发到服务实例上。

工程架构规划

刚刚介绍了整个工程的大约的架构规划，这个是整个工程的目录结构规划。目录结构是参考比较火的 go standard project layout 项意图推荐。

首要从上往下，会放一个 makefile， makefile 是整个工程构建的一个进口，能够了解相应的构建的指令都是一致封装，会相应的构建，都能够经过一些封装指令去做相应的履行

build 目录主要会放工程相应的镜像构建的一些装备文件，比方 Dockerfile

cmd 能够了解成是整个工程的主干进口，每个服务运用 Cobra 把它拆分红不同的 subcommand；

conf 目录便是寄存整个工程的一些装备文件

Idl 目录会寄存 Kitex 的Thrift 的界说 internal 是事务逻辑相关的封装，咱们一致它默认是不会对外供给包的露出的，所以咱们把它一致放到 internal 里边。 internal 里边也会简略做一些分层： handler 层是用一致放 Hertz 相关的一些 HB 的 handler；server便是相应的咱们 4 个服务相应的服务的一些初始化，以及它的服务发动的相关的一些逻辑service。咱们一些事务逻辑的封装都会一致放在咱们这 4 个微服务的一些相关的事务逻辑的完结，都会一致放在这边。 kitex_gen 便是根据 IDL 去主动生成的一些代码

Manifest 是工程布置相关的装备文件，正常布置比较推荐的运用 Helm Charts 来布置。这边也是有一个 Bookinfo 的 helm charts，能够直接去 helm install 去布置应用

pkg 能够了解成高度封装、外部能够高度复用的而且跟事务逻辑没有任何没有太大的耦合的一些可复用的包，咱们会一致把它放到 pkg 里边

OK，这便是 Bookinfo 大约的工程结构规划

Makefile 规范规划

讲到工程化肯定就离不开 Makefine，刚刚咱们也讲到，它是做整个项目构建的一个指令封装，其实能够了解也是咱们内部笼统出来的一套规范。咱们会要求每个项意图 Makefine 得包含一些必要的元素，比方必须得能够支撑代码的查看，也能支撑去履行一些单元测试，能支撑去做二进制的构建、跨渠道编译的二进制构建，以及咱们的容器的镜像的构建，还有构建完镜像之后，能够支撑咱们 push 到长途的镜像库房上，也允许把一些本地构建的产品能够比较方便地整理掉。

上面所说是一个“强需”，即需求包含这些。下面能够按自己的需求，看是否去增加一个端到端的的测试。

这个是 Makefine 的规范规划，也给咱们简略地共享一下。 接下来是一个 Makefine 的详细的例子。能够看到，我有一个根据 lint 做代码查看的，还有一个是单元测试的，还有个是本地化二进制产品构建的，还有便是一个容器化镜像构建的。

别的一块便是说到工程化，由于现在都是一个云原生的年代，咱们都是以容器化的方法去运转自己的应用，所以容器的 Dockerfile 编写其实也有相应的规范的要求，会要求依照不同的阶段去做对应的 Dockerfile 做个拆分。

1. 榜首，多阶段构建。首要能够看上面其实是一个编译期的阶段，编译期的阶段能够依靠 golang 的根底镜像去履行咱们刚刚 makefile 里边封装的二进制构建。它的任务其实便是把咱们的工程编译成一个可履行的二进制。

2. 第二，镜像精简原则。关于运转时的镜像，就会很轻量，它不会根据一个包含了 Golang 或许包含一些根底的较大依靠的根底镜像，它会只会期望是依靠一些轻量的、小的根底镜像，咱们会把榜首步的建产品 copy 到镜像里边去，而且把一些装备目录准备好。所以它只需求放一些可履行的二进制文件和装备目录即可。这是多阶段构建的一个规范的规划。刚有说到运转时的镜像，咱们尽量期望它在出产环境是尽量精简轻量的。所以根底镜像中放的东西尽量是越少越好。
3. 第三，镜像安全。一般事务不需求特权履行，所以咱们会要求用户运用，由此指令版切换到非 root 用户，避免在出产环境把 root 用户露出出去。

三、技能选型介绍

技能选型方面，我简略的把 Bookinfo 项意图技能栈大约列了一下。

1. 首要，Kitex 和 Hertz。技能栈从上往下是咱们服务的结构，Productpage 是对外供给 HTTP 服务的，所运用 Hertz 来写一个 server 端，而且它也集成了 kitex client 去调用相应链路下流的服务。比方他调用 Reviews，调用 Details，都会运用 kitex client 去调用其他的服务。而且这些由于都是内部的一些微服务，它不需求露出接口的外部，所以一致运用 kitex 封装成 RPC 服务。

2. 第二，Istio。刚有说到，咱们这个项目是为了去演示在服务网格下怎样运用 proxyless 去做全链路的泳道，所以咱们也会依靠 Istio 的操控面。它的责任主要是用来做服务网格操控面，跟数据面的 xDS 模块做交互，担任把一些 xDS 的装备动态下发下来。
3. 第三，Wire。咱们工程里边也依靠 Google 的 wire 去做相应的依靠注入。
4. 第四， OpenTelementry 。由于咱们要做全链路的泳道，首要 Tracing 或许会是一个强依靠要依靠 Tracing 的上下文透传才能，帮咱们去把泳道的染色标识透传下去，而且也顺带去把全链路的 tracing、metrics、logs 都集成演示了。
5. 第五，Kitex-xDS 。是工程一个比较中心的依靠，能够让 Kitex 以 Proxyless 的方法能够直接对接到无网格的系统中去。
6. 最终，便是用 react，arco-design 去写了一个简略的 UI 层。 以上是技能栈的简略介绍

结构选型 – Hertz、Kitex

结构选型刚刚有提，就不再过多赘述了。首要， Productpage 有运用的 Hertz server，其他的都是用 Kitex。

依靠注入（Google Wire）

刚刚有聊到，会依靠一个 Google 的 wire 来做依靠注入。 Google 的 wire，我信任咱们也比较了解，像在 go 的依靠注入这块，主要分两种：一种是运转时根据反射去做，还有一种是在编译期能够去根据静态的代码剖析和代码生成的机制去提前把相应的注入代码生成好。

咱们选型的是运用 Google wire，能够看到一个简略的handler。handler 有两个依靠，一个是 review 的client， detail 的 client 能够看到 handler 它其实不必关怀这两个 client 是怎样去初始化的，它只需求把这两个 client 作为它的一个依靠，声明在这边即可。

下面便是 review client 它自身的 provider，也不需求关怀谁在谁会去运用它，只需求把它自身怎样初始化，以及自身怎样对外供给服务，供给才能的封装好。能够看到二者的责任是能够别离的。

下图便是 review client 它自身的 provider 例子

这边就开端注入了，用 wire.Build 去做，会把相应的 provide 以及依靠声明都一致声明在这。

咱们履行 go generator，会帮咱们主动生成相应的依靠注入代码。能够看到，依靠注入代码会帮咱们生成，比方初始化 review client、 初始化 detail client，把这 client 作为它的参数传递进去。正常没有依靠之后，这些代码或许需求咱们反复地去手写，Bookinfo 这个项目比较小，或许还好。假如是一个比较大的工程，这些代码假如手写很简略顺序会有问题，或许是一个重复的作业，不是那么简略或许高雅。

可观测 – OpenTelemetry

别的一块便是可观测了,咱们的选型是运用 OpenTelementry 。 简略介绍一下，OpenTelementry 是一套可观测的开源规范协议，它供给了相应的 specific，以及供给了相应 API 的一致界说，包含根据它自身的 specific 和 API 界说也完结了一套 SDK，一起也包含了一套自己完结的数据收集器，比方能够帮咱们从云上或许根底设施里边去采集一些数据，这些数据主要包含Metrics、 Traces 和 Logs，这些一致地把它们收敛成自己的协议规范格式。这个是 OpenTelementry 的简略介绍。

别的一方面，便是咱们的 Kitex 和 Hertz 现已是原生集成了 OpenTelementry 。这边有两个 repo，咱们感兴趣能够点过去看一下详细的完结。有了这些库，咱们运用 Kitex 或许 Hertz 的时分，就能够比较轻松地直接在咱们事务中去集成 OpenTelementry。

• Hertz-otel：github.com/hertz-contr…
• kitex-otel：github.com/kitex-contr…

集成的代码在下边简略列了一下，其实也比较简略，一个是初始化相应的 OT 的provider，而且把相应的 tracing 的 Suite 注入到 server 端去就能够了。这样其实就会帮咱们把 Tracing、Metrics、Logs 的一些集成主动帮咱们做掉。

这个是可观测，简略演示一下集成之后的作用。

有一点能够提一下，单独讲一下 Kitex 和 Hertz ，它底层的 Tracer 的完结都比较高雅，会把一些结构内部的细节帮咱们以 stats 的方法露出出来。这样咱们上层在运用 OT 去集成的时分，就能很轻松地把这些事件作为一个 span 的 event 去协助用户把它露出出来，在 event 上做相应的出现，比方一个客户端的衔接的树立和完毕，以及他的读写事件，咱们都能够在链路盯梢里边去观察到，而且会生成一些目标的拓扑或许调用链。

服务管理 – xDS 介绍

服务管理咱们的选型思路便是根据 Istio 这套服务网格的机制来做。首要要讲服务网格，需求跟咱们介绍一下 xDS 这个概念。 xDS 简略了解便是一组发现服务的总称，所以它叫“x”。其间，比方LDS、RDS、CDS、EDS，便是各式各样的资源主动装备的服务发现，它们都能够在咱们的操控面，跟 Istio 里边能够跟咱们的数据面实时地进行装备的下发。

有了 xDS 这套机制或这套一致的笼统，工作就比较好做。 Kitex 要想去对接，就能够有一种思路：直接去跟 Istiod 交互，根据 xDS 这套通用规范的协议，去实时地去获取咱们想要的管理规矩装备。

服务管理 – Kitex xDS

Kitex 现在也现已原生地支撑了 xDS API，所以咱们能够直接在咱们的代码里边去敞开相应的 xDS 模块，而且能够让服务以 Proxyless 的形式运转，再一致被服务网格去纳管。详细内部的完结细节，有一些计划咱们感兴趣能够看一下。 运用方面，能够看到有代码片段。咱们首要要初始化咱们的 xDS Manager，担任寄存咱们相应的 xDS 的装备，实时 watch 的一些装备信息，以及它会去内置一个 xDS client ，担任跟咱们的操控面 Istiod 做实时的交互。看到咱们的 kitex client 会去集成一个 xDS 的路由模块，这个是为了咱们后面要做全链路泳道，埋下一个伏笔：咱们怎样根据 Proxyless 去完结一个流量路由。

当然，一起要把 OpenTelementry 才能给敞开。

根据 xDS，Kitex 能够一致地被服务网格纳管，一致纳管的优点就能够体现出来了：咱们能够用 Istio 原生的 API 去界说管理规矩。比方依照 Istio 常规的运用方法，会给每个实例打上一个版别标识，会界说一个 destination rule 去为咱们每个实例做一个分组。在比方 v1 版别，v1 版别的 pod 一致把它放到 v1 的池子里， v2 版别一致放到 v2 的池子里边，相应的便是 v3 也会放到别的一个池子里边，是按服务实例去做一个简略的分组。

服务管理 – 界说流量路由规矩

有了分组之后，就能够去界说分组的流量路由规矩。路由规矩是两条，榜首条便是在 header 里有相应的 Baggage，会把流量精确地打到 Ratings 第二版别的池子里边，假如没有，会默认就打到 Ratings 一切版别里边轮询。这便是能够根据 Istio 原生的 API 去界说相应的流量的路由规矩了，这是对接 xDS 的优点。

四、全链路泳道介绍

讲完了技能选型，并顺带引出了咱们今日比较重要的一个主题：全链路泳道。咱们做这个 demo 最主要的意图便是期望能够 demo 一下怎样去完结全链路泳道。

首要，泳道规划简略分了两个泳道，其实详细分多少泳道是跟泳道路由规矩来定的。咱们演示的其实是基准泳道，分支泳道。能够看到基准泳道是 product v1，它会在 v1 和 v3 之间做一个轮询，会打到 v1，假如带了相应 baggage v1 的版别的流量路由，会精确地路由到 v2 版别，而且也相应地录入到 Ratings v2 的版别。

泳道规划 – 传统流量路由方法

当咱们接到这个泳道的需求，怎样去完结也有几种思路，其间最简略想到的便是传统的思路，其实 Istio 原生就支撑依照一些 header 头去匹配，能够去界说路由规矩。

有些事务直接依照事务特点标识，即我给你一个事务特点标识，你帮我去配一条路由规矩。比方要求依照 uid=100 这条规矩，让咱们去配一条相应的路由规矩。

偶然这样一次没问题，但是假如又来下一个事务方，需求配一个 uid= 101 的，这样局限性就慢慢地显露出来了，十分不够通用。由于它是以事务详细特点的某个 key 作为流量路由的匹配规矩，而且 key 也需求在 SDK 或许事务代码里边，相应的有一些侵入性，必须得帮它去透传事务特点的 key，要在 header 头里边。比方恳求 service a 恳求 service b， header 头里边需求带上 uid=100，这样 Istio 的路由才能帮你识别到 header 去路由。 另一方面，比方事务方今日是根据 uid= 100 这条规矩，第二天又改变，这个路由规矩也就很简略频频地改变，每个服务配的 vs 或许都需求去频频地去改变。而且保护的规矩或许会跟着服务数量，成了基数爆破的局面，规矩或许会十分的臃肿。这个是以传统的 Istio 默认供给的那种方法去完结的弊端。

泳道规划 – 流量染色

这儿会考虑运用一致染色的概念，所谓的染色，比方咱们刚说的 uid=100，只需求把改变的这版收敛在进口网关。下流不必感知详细事务的 header key 是什么，只需求知道你有没有带 Baggage， 详细配哪些 Baggage也不需求在事务代码里边去显现，比方我今日传 uid ，明天传 cookie 中的某个 key。事务方不需求跟着你一起去改动它，只需求去接入 Baggage 这套SDK，能够主动地去透传 Baggage。

一切的改变的部分都收敛在运维侧，只要配染色的规矩以及路由规矩就能够了。事务代码不需求做任何的改变，染色网关层一般会分两种染色方法，一种是按条件去染染色，比方刚刚说的按 uid = 100 这种，去打一个染色的标，或许它按某些 cookie 去做匹配，也打个染色的标。还有别的一种，依照一定的份额去做按份额恳求，做一些染色的标识。比方咱们依照 10% 的流量，咱们去简略去做 10% 的流量染色。 根据这条染色标识，对比传统的方法，其实有许多优点，便是事务跟事务解耦，跟事务代码解耦开了。至于根据什么方法来完结 Baggage，以及 Baggage 自身怎样去透传，也是需求根底架构团队需求去考虑处理的问题。

泳道规划 – 染色标识全链路透传（Baggage）

咱们的选型思路便是运用全链路的机制来做 Baggage。Baggage 其实也是全链路里孵化出的概念，自身规划出来便是为了能够让整个全链路可去透传一些事务特点自界说的 KV 特点，比方咱们能够用它来传递染色标识，也能够传递一些事务的标识，比方 AcountID。所以事务方需求做的工作，只需求集成咱们的 OpenTelementry 的 tracing 即可。

泳道规划 – 泳道作用（基准泳道）

接下来是 Bookinfo 的简略展现，比方进口流量不带 uid 恳求，默认会找到基准泳道。基准泳道是两个不同的服务实例版别的完结，一是只回来新的一颗新的书评，还有一个是回来没有新的书评。别的一种，它的进口恳求现已带了对应的 uid 标识，就会被精确地路由到分支泳道上。分支泳道便是一个回来 5 的评分服务。

五、Proxyless 与 ServiceMesh

以上给咱们简略介绍一下，工程引申到了全链路的场景。能够再引申一波，考虑一下 ServiceMesh 以及 Proxyless 这两个之间是什么样的联系，以及 Kitex xDS 怎样完结了全链路流量路由才能的，也能够给拿咱们简略地去介绍一下内部的完结细节。

首要 Kitex Proxyless 的形式，能够看到全体的架构也会分操控平面以及数据面。能够看到，现已没有传统 Detail 的 envoy 或许 pilot agent、sidecar 。便是一个干净的事务 application，里边会集成 xDS 相应的模块。xDS 相应的模有一个 xDS client，做的工作便是跟 Istiod 去做通讯。 根据 ADS 协议，能够去实时地获取到管理规矩的改变，比方刚刚配的流量路由的规矩，其实归于管理规矩。未来或许还会去支撑动态的熔断、超时，这些也是能够实时感知，实时下发下来，咱们会把它 sync 到咱们 xDS resource manager 中，保护实时的管理规矩。

恳求途径上，会发一个 request 到咱们的一个 Upstream 服务上。 Upstream 服务能够给服务去做一些版别的区分，依照版别去区分红不同的实例组。能够了解成，如图示，把一个服务依照版别区分红了两个实例组。首要两个 endpoint，它归于 v1 版别，会放到 sub cluster a 里边， c 和 d 别的两个服务实例归于 v2 版别，会放到 subcluster b 里边。刚刚演示的流量泳道，实质便是去 pick subcluster 的，详细是要打到 v1 用池子里，仍是打到 v2 池子里边，做的便是这个工作。 去做这个工作的大约链路，首要咱们 Kitex client 会建议恳求，它建议恳求的时分，咱们会有相应的 Middleware，它最先会经过一个 xDS 路由的 Middleware。它要做的工作，便是根操控面装备的路由规矩，获取装备规矩就从这儿获取。咱们会实时地去 sync，获取到管理规矩之后，它知道这个恳求，需求能够路由到 subcluster a 仍是 subcluster b，其实都有相应的界说。它拿到这个信息之后，就知道了恳求是要路由到 subcluster a，再经过一系列的中间件，比方在这些中间件里边，都能够去集成 Istio，有管理的逻辑，比方熔断、超时以及动态的负载均衡。 resolve middleware 要做的工作便是：由于咱们现已选到了一个池子，池子里边有许多服务实例，详细要把流量打到哪个服务实例，其实便是 resolve 去做的，会去做一个 load balance，精准选择某个实例。经过 resolve 之后，能够拿到一个精确的 endpoint，就能够发一些恳求了。然后它的 request 就会精确地打到 endpoint a 上，这便是一个完整的流量路由根据 Proxyless 完结一个全链路泳道。给咱们简略共享了底层流量路由的完结原理。

规范 Sidecar 形式

这是 Proxyless 形式的 ServiceMesh 的形状，咱们比较熟悉的 ServiceMesh 形状其实都是这种规范的 Sidecar 。每个服务咱们都会给它注入一个 Proxy，这个 Proxy 便是根据 envoy 完结的。

它做的工作，首要容器会有一些，不管是 iptables 仍是 eBPF，会帮咱们把进去的流量能够动态地去绑架重定向到咱们 Proxy上。 Proxy 处理完之后，把恳求再重定向到事务容器上，事务容器发对外发出的 outbound 流量也会首要也会重定向到 Proxy 上。

相当于它的 inbound outbound 都会过一遍署理，相当于咱们能够在事务进程、事务逻辑上再增加一层能够可拓宽的中间件机制，咱们一切队列建的中间层逻辑，比方目标、 tracing、 管理，还有安全，都一致能够收敛到这个 Proxy 中去完结。这跟 Middleware 思想很相似的，只不过 Middleware 和事务逻辑在同一个进程里边。 操控面都是根据规范的 xDS，根据规范的 Istiod 去做操控面。这个是业界比较熟悉或许用得比较多的，规范 sidecar 形式。

eBPF 内核 Mesh 形式 （cilium）

还有第三种，或许比较新的形式，根据 eBPF 内核去完结内核 Mesh 形式。它所谓的内核 Mesh 其实便是流量首要会经过咱们。

简略介绍一下 eBPF 能完结的才能，它其实能够帮咱们直接去内核态的一些系统函数去做一些相应的插桩。能够去动态地去插入一些你想要去履行的逻辑，比方我想去履行一些L3、 L4 的流量的署理，我能够把它运用 eBPF 去完结，这样就不需求去借助 envoy 去做 L3、L4 的 load-balancing，能够直接在内核里边去做。当然，有一些内核里边无法完结的，咱们会把它 fallback 到用户态的一个 envoy 上。

图中这个是 cilium 社区现在完结的一套根据 eBPF 的内核 Mesh 形式。首要 eBPF Native 层会担任 L3、L4 的流量，或许一些 canary 或许 topology 感知路由、多集群的支撑，还有安全、可观测性的支撑。 能够看到，咱们许多才能能够下沉到内核里边去，不需求在用户态的 envoy 里边去做。当然有一些跟用户态的特点强绑定的，比方 L7 的 load-balancing，跟用户带的结构或许协议都是强感知的，它很难在内核态完结，或许说要在内核态完结的成本会比较高，所以仍是倾向于会把它 fallback 到用户态来做，包含咱们的 L7 的 Rate Limiting，还有 TLS 的终止这些才能。这是一个根据内核的 Mesh 形式。

为什么要做，主要是出于功能的考量，由于 Sidecar 形式难免会带来一些时延的增长。虽然跟着 Istio 和 envoy 自身的迭代，功能差距会越来越小。 所以问题来了，ServiceMesh 终究是什么？现在似乎有各式各样的形式，各式各样的组合方法。

这确实是一个问题，值得咱们考虑。

ServiceMesh —— 无关形式，服务间通讯根底设施规范笼统

我的个人的考虑，便是 ServiceMesh 其实不关怀详细的形式完结细节，它其实是一层通讯根底设施的笼统。你能够了解成，最早的时分，咱们的事务代码想要去完结可观测，要完结流量路由，要完结安全或完结 Resilence，它要在自己的事务代码或许在自己事务结构的 Middleware 里边去做。

其实结构帮咱们做了一层解耦，把事务不必写在事务函数里边，详细的事务逻辑里边，它笼统到结构的供给的 Middleware 里边去做。我了解它其实也是一层事务代码和根底设施的一些别离。Mesh 的中心其实便是把通用的规范根底设施才能下沉，能够下沉到咱们的 Middleware，也能够一个 Sidecar 里边去，乃至下沉到内核 Mesh。 其实它们意图或许初衷，我了解其实都是相同，只不过是技能手段，或许根据不同场景能够去抉择不同的技能选型的差异，实质或许目标都是相同的。这个是我个人对 ServiceMesh 的个人了解。

ServiceMesh —— 根据一致规范去构建服务管理渠道

根据这套了解，其实咱们就能够去做一些有意思的工作了。比方有这套一致的规范，有一个一致的笼统。其实能够把操控面或许服务管理的规矩模型一致起来，去一致各种不同的异构的结构或许异构的渠道。自己描述自身的那些服务管理规矩模型或许都不相同，能够一致起来，包含操控面也能够收敛在一起，不必不同的结构或许不同的系统、运用不同的操控面。其实上层运维人员或许用户，会有一种割裂的感觉，包含装备这些管理规矩。

怎样动态下发下去，其实社区里 xDS 也是一个比较盛行的、规范的一套通用协议。刚刚说到异构的数据面，其实会有许多种，咱们做咱们要做的工作便是去兼容它，或许让它去贴合咱们的整套系统的生态，比方规范的 Proxy 形式、Proxyless 形式，还有刚说到内核 Mesh 形式，它其都能够被一致纳管到一个一致的服务网格的系统中。以上便是我根据 ServiceMesh 的一些个人的了解。 最终便是咱们项目相关的一些链接，感兴趣的同学能够点击链接到 GitHub，去看相应的一些项目。

• bookinfo：github.com/cloudwego/b…
• Kitex：github.com/cloudwego/k…
• Hertz：github.com/cloudwego/h…
• kitex-contrib/xds：github.com/kitex-contr…
• kitex-contrib/obs-opentelemetry：github.com/kitex-contr…
• hertz-contrib/obs-opentelemetry：github.com/hertz-contr…

---

项目地址

• GitHub：github.com/cloudwego

• 官网：www.cloudwego.io

• 【CSG 第四期】转发海报 & 观看直播收好礼，CloudWeGo 事务实践事例解读开端啦

活动链接：mp.weixin.qq.com/s/NG-Wf7nzN…