前言
本文内容整理自5月25日在 Kubernetes & Cloud Native Meetup 上海站发表的主题演讲,主要介绍了 ServiceMesh 最新的产品动态,分析其发展趋势和未来走向;结合蚂蚁金服的上云实践,阐述在云原生背景下 Service Mesh 的核心价值,以及对云原生落地的关键作用。
内容主要有三个部分:
- Service Mesh 产品动态:介绍最近半年 Service Mesh 的产品动态,包括开源项目和云厂商推出的云上服务
- Service Mesh 发展趋势:根据最近的产品动态,总结 Service Mesh 的发展趋势,推断未来的走向
- 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。这