Service Mesh 发展趋势：云原生中流砥柱

前言

本文内容整理自5月25日在 Kubernetes & Cloud Native Meetup 上海站发表的主题演讲，主要介绍了 ServiceMesh 最新的产品动态，分析其发展趋势和未来走向；结合蚂蚁金服的上云实践，阐述在云原生背景下 Service Mesh 的核心价值，以及对云原生落地的关键作用。

内容主要有三个部分：

1. Service Mesh 产品动态：介绍最近半年 Service Mesh 的产品动态，包括开源项目和云厂商推出的云上服务
2. Service Mesh 发展趋势：根据最近的产品动态，总结 Service Mesh 的发展趋势，推断未来的走向
3. Service Mesh 与云原生：结合云原生，更好的理解 Service Mesh 的价值和作用

Service Mesh 产品动态

Istio1.1 发布

Istio 是目前 Service Mesh 社区最引人注目的开源项目，在今年的3月份发布了期待已久的 Istio 1.1 版本，我们来看看 Istio 最近几个版本的发布情况：

• 2018年6月1日，Istio 发布了 0.8 版本，这是 Istio 历史上第一个 LTS 版本，也是 Istio 历史上变动最大的一个版本；
• 2018年7月31日，Istio 发布了 1.0 版本，号称 "Product Ready"；
• 然后就是漫长的等待，Istio 1.0 系列以每个月一个小版本的方式一路发布了 1.0.1 到 1.0.6，然后才开始 1.1.0 snapshot 1 到 6，再 1.1.0-rc 1 到 6，终于在 2019年3月20日 发布了 1.1 版本，号称 "Enterprise Ready"。

从 Istio 1.0 到 Istio 1.1，中间的时间跨度高达9个月！我们来看看经过这漫长的开发时间才发布的 Istio 1.1 版本带来了哪些新的东西：

图中标红的部分，涉及到 Istio 的架构调整，下面将详细介绍 Istio 1.1 版本中带来的架构变化。

Istio 1.1 架构变化

下图是 Istio 1.0 和 Istio 1.1 的架构图对比：

Istio 1.1 的第一个架构变化来自 Galley：在 Istio 1.1 的架构图中增加了 Galley 组件。但是实际上在 Istio 1.0 版本中 Gallay 组件就已经存在，只是当时 Galley 的功能非常简单，只是做配置更新之后的验证（Validation），在 Istio 1.0 的架构图中都没有出现。而在 Istio 1.1 版本之后，Galley 的定位发生了巨大的变化：Galley开始分担 Pilot/Mixer 的职责。

在 Istio 1.1 版本之前的设计中，Istio 的三大组件 Pilot/Mixer/Citadel 都需要访问 Kubernetes 的 API Server，以获取服务注册信息和配置信息，包括 Kubernetes 原生资源如 service/deployment/pod 等，还有 Istio 的自定义资源（数量多达50多个的 CRD） 。这个设计导致 Istio 的各个组件都不得不和 Kubernetes 的 API Server产生强绑定，不仅仅代码大量冗余，而且在测试中也因为需要和 Kubernetes 的 API Server 交互导致 Pilot/Mixer 模块测试困难。

为了解决这个问题，在 Istio 1.1 之后，访问 Kubernetes 的 API Server 的工作将逐渐交给 Galley 组件，而其他组件如 Pilot/Mixer 就会和 Kubernetes 解耦。

这个工作还在进行中，目前 Istio 的 CRD 已经修改为由 Galley 读取，而 K8s 的原生资源（Service / Deployment / Pod等），暂时还是由 Pilot 读取。

为了方便在各个组件中同步数据，Istio 引入了MCP（Mesh Configuration Protocol）协议。在 Istio 1.1 版本中，Pilot 通过 MCP 协议从 Galley 同步数据。MCP 是受 xDS v2 协议（准确说是 aDS）的启发而制定的新协议，用于在Istio 各模块之间同步数据。

Istio 1.1 的第二个架构变化来自于 Mixer，在 Istio 1.1 版本中，推荐使用 Out-of-Process Adapter，即进程外适配器。Istio 预计下一个版本将弃用 In-Proxy Adapter，目前所有的 Adapter 都将改为 Out-of-Process adapter。

什么是 In-Proxy Adapter？下图是 Mixer 的架构图，在 Istio 的设计中，Mixer 是一个独立进程，Proxy 通过远程调用来和 Mixer 交互。而 Mixer 的实现了 Adapter 模式，定义了 Adapter API，然后内建了数量非常多的各种Adapter。这些 Adatper 的代码存放在 Mixer 代码中，运行时也在 Mixer 的进程内，因此称为 In-Process Adapter。

In-Process Adapter 的问题在于所有的 Adapter 的实现都和 Mixer 直接绑定，包括代码和运行时。因此当 Adapter 需要更新时就需要更新整个 Mixer，任意一个 Adapter 的实现出现问题也会影响整个 Mixer，而且数量众多的 Adapter 也带来了数量众多的CRD。为此，Istio 1.1 版本中通过引入 Out-of-Process Adapter 来解决这个问题。

 

Out-of-Process Adapter 以独立进程的方式运行在 Mixer 进程之外，因此 Out-of-Process Adapter 的开发/部署和配置都可以独立于 Mixer，从而将 Mixer 从 Adaper 的实现细节中解脱出来。

但是，Out-of-Process Adapter 的引入，会导致新的性能问题：原来 Mixer 和 In-Process Adapter 之间是方法调用，现在改成 Out-of-Process Adapter 之后就变成远程调用了。而 Mixer 一直以来都是 Istio 架构设计中最大的争议，之前 Proxy 和 Mixer 之间的远程调用，已经造成非常大的性能瓶颈，而引入 Out-of-Process Adapter 之后远程调用会从一次会变成多次（每个配置生效的 Out-of-Process Adapter 就意味着一次远程调用），这会让性能雪上加霜。

总结 Out-of-Process Adapter 的引入：架构更加的优雅，性能更加的糟糕。

在 Istio 1.1 为了架构而不顾性能的同时，Istio 内部也有其他的声音传出，如正在规划中的 Mixer v2。这