Analysis of Tencent Cloud Mesh and Istio Service Mesh Evolution

腾讯云服务网格（TCM）作为兼容Istio的服务网格平台，已经在腾讯内外部有诸多落地案例。本文是对腾讯云高级工程师钟华、苗艳强在云+社区沙龙online的分享整理，深度解析服务网格架构演进和发展趋势，希望与大家一同交流。

一、 istio 现状和发展趋势

istio现在是目前最流行的服务网格实现，它的流行主要体现在两个方面：一是社区非常的活跃，过去一年，Istio 在 GitHub 增长最快的开源项目排行榜上名列第四；另一方面 istio 在业界有了越来越多的生产落地。在一项云原生调研报告中，已经有18% 的用户在生产环境中使用mesh 技术，而另外47% 的用户正在进行 mesh 落地评估，而在这部分评估和测试的用户中，有接近7成的用户是在评估 istio。

istio 今年的一个大事件是将商标转让给了OUC（Open Usage Commons ），官方宣称的目的是给 istio 提供更加中立和独立的监督，当然这个做法不太符合社区的主流期望，也就是大家一直在讨论 istio 什么时候加入cncf，这里我们就不展开讨论。

istio 是在 17 年 5月份发布的第一个版本，到目前为止已经演进了三年多，目前有固定的发布节奏，每个季度会发布一个子版本。

istio 是在 18年7月发布 1.0 版本，宣布 Production ready，但在这之后 istio 多次的重新定义生产落地，这从一个侧面也反映了 istio 还处在一个高速演进的过程中，大的架构变迁仍然会时有发生。

所以说如果大家尝试在生产环境中使用开源 istio，开发和运维人员需要对 istio 组件有深刻的理解，以及持续的技术投入。

二、 istio 架构演进

istio 最大的一次架构演进发生在今年三月份，将微服务控制面调整为单体式的 istiod。我们简单对比下当时的架构变化，并探讨下演进的背景和原因：

istio 在1.5 之前，整个控制面是一个复杂的微服务架构。其中：Galley 是整个 mesh 的配置管理中心，包括配置验证功能，可以对接不同的服务注册中心，服务配置在这里统一接入。他有两个主要的消费者是 pilot 和 Mixer。

Pilot 是整个控制面的核心，它负责聚合服务发现数据，抽象成 istio 的数据模型，以 xDS 的形式下发给数据面。

Mixer 包括 Telemetry 和 Policy 两个组件，Telemetry 负责遥测数据采集，并以 Adapter 方式对接各种监控后端，Policy 负责在服务相互调用过程中对请求进行策略检查。

Citadel 负责安全和证书管理。

但实际的实现还要更复杂些，Mixer 可以利用复杂的扩展模型对接第三方系统。控制面还包括 Prometheus Grafana Kiali 等遥测组件。还有独立负责数据面 Sidecar 模板注入的 sidecar-injector 组件等。

再来看单体化的 istio 控制面，控制面只有一个单体组件 istiod，原来的微服务组件全面纳入其中，同时这个架构直接把原来的性能消耗大户 Mixer 去掉了，后面引入了 Telemetry v2 作为 istio 新的扩展方式。

istio 单体化的发展，似乎和目前大热的微服务趋势背道而驰，我们可以稍微分析下背后的原因：

istio 诞生在微服务架构大热的背景下，从一开始， 控制面就规划了不同职责的组件，所以 istio 最开始就选择微服务架构是很自然的结果。

在微服务里的理论背景中，不同的组件有不同的资源和弹性需求，比如上图中，Pilot 需要处理服务发现数据，需要对接数据面 Sidecar，Mixer 的消耗和流量规模正相关，这 2 个组件会占用控制面 80% 以上的资源消耗，把它们独立出来是有意义的， 他俩可以各自进行弹性伸缩。比如 Mixer 通常需要跑多份，其他组件可能只有一份。

另外微服务的控制面还做了一些假设，设计者认为控制面不同的组件通常会由不同的团队来维护，这也是典型的微服务架构理论，比如 Citadel 由安全或运维团队来负责，Pilot 和业务开发关系更紧密等等。另外 istio 最初还非常理想化的提出控制面的各个组件都可以独立部署，按需选择安装组件，在实际应用场景里却并非如此。

微服务架构看起来非常优雅，兼顾可伸缩和可扩展性，但是呢在实际使用过程中的，用户却发现该架构极度复杂。这是单体化演进的根本原因。

istio 单体化演进的另一个原因是和 Mixer 组件演进相关，Mixer 一直饱受诟病，check report 模型精巧但性能低下，随着 Envoy 支持 wasm 作为新的扩展方式，社区决定把 Mixer 从控制面中移除。

当 Mixer 移除后我们再来看控制面：Galley 的消费者只剩下 Pilot，没有独立存在的必要，所以合并到 istiod；伸缩性方面， 2个性能消耗大户去掉了一个，只剩 Pilot 比较占用资源，分组件独立伸缩的需求也没有那么重要了。

单体 istiod 受到社区的广泛欢迎，特别是我们这种 istio 相关的研发和维护人员：首先我们使用 istio 的难度降低了，安装和排错都会更简单。另外 istio 的性能也有很大的提升，一个原因是 Mixer 的去除，另一个原因是 之前复杂的组件合并到一个进程中后，原来组件之间的 RPC 通信，变成了单体中的方法调用，原来组件之间需要传递的数据，变成了单体中的共享内存，所以说不管是响应速度，还是资源消耗，都有较大的优化。

三、原生 istio 在企业级应用中的挑战

mesh 技术在腾讯内部已经有多年的应用实践，从最早的单纯 sidecar 模式，到最近几年以 Envoy 和 istio 为主的云原生模式，都有大量的生产实践。

但不管是内部用户还是公有云用户，大家的一致反馈是，使用 istio 成本高，落地难，这里有一些共性问题：

1. 版本迭代快，维护周期短；

2. 内部组件复杂；

3. 外部依赖众多；

4. 性能瓶颈；

5. 多集群，混合云，托管诉求。

istio 对 每个子版本的官方支持时间比较短，根据 istio 的 Support Policy，istio 发布了新的 LTS 版本后，上一个版本只会在支持三个月。按照现在 istio 三个月一个 LTS 的节奏，大概就是每个版本官方只支持半年。

举个例子，备受关注的 istio 1.5 在今年 3 月 5 号发布， 而在今年 8 月 21 号 就宣布不再维护，整个周期不到半年。

另外 istio 每个版本只支持 k8s 最新的三个版本。比如最新的 istio 1.7 只支持 k8s 1.16， 1.17 和 1.18。这要求用户频繁地对基础架构进行升级。

即便现在把控制面合并为一个单体后，istiod内部实现也比较复杂，包括高度的模型抽象。

另外 istio 很多功能依赖其他系统，比如遥测，就用到了 Prometheus， Grafana， Kiali，Jaeger 等等。

所以使用者需要理解和运维的，不仅仅是istio本身，比如说 Prometheus 单点问题如何解决，比如说 Jaeger 选用什么存储，这些组件高可用怎么处理等等，这整套对团队的技术投入要求很高。

另外服务网格的性能开销也是用户比较顾虑的点，目前对于最新的 istio 1.7，单次 RPC 增加耗时开销大概是 3~5 毫秒，这对一些耗时敏感的系统是无法接受的。

支持协议方面，目前istio 支持的协议有限，应用层主要是支持 HTTP，gRPC，但现实企业中有大量的其他rpc协议治理的需求：比如dubbo、thrift以及其他私有 RPC。这也会限制很多用户直接接入。

另外 istio 对多集群和多平台的支持也还不够完善，用户有很强的托管诉求。

四、Tencent Cloud Mesh 架构演进

腾讯云服务网格 Tencent Cloud Mesh （以下简称 TCM ）的定位是云原生服务级别的网络管控基础设施。

为什么说是基础设施呢？一个原因是我们对 mesh 的理解，我们希望接入的业务团队不需要过多地关心 mesh 的底层实现，只需要专注将业务本身。

另一方面，我们认为 mesh 提供的能力，不仅仅局限在常规的服务治理领域，其他需要用到流控能力的场景，比如发布系统，比如 serverless，都可以使用 TCM 暴露的能力，下文也会介绍一些 TCM 的典型落地案例。

如下图所示，是 TCM 的一个能力概览：