【杭研大咖说】Istio进入1.7版本，Service Mesh 落地还有什么障碍？

作者 | 冯常健

编辑 | 田晓旭

首发 | 架构头条

2017 年，Google 联合 IBM、Lyft 推出了 Istio，因为有 K8s 的成功经验在先，Istio 一出生就引人注目，其受到的关注度甚至远超最早提出服务网格概念的 Linkerd。只要有关注度，就有溢价存在，业界为 Istio 买账更像是买一种预期，认为 Istio 能像 K8s 一样，快速成为服务网格领域的事实标准。

当然，除了独特的出身优势，Istio 自身也品质过硬，有着非常漂亮的架构设计，着重解决了微服务间通信的连接、保护、观测、治理等问题。此外，Istio 将 Envoy 作为标准数据面组件，借力 Envoy 社区确定了数据面方向的竞争优势。Envoy 是基于 C++ 开发的 L4/L7 高性能代理，在功能、性能、扩展性、可观测性等方面表现出色，是云原生时代服务代理的最佳选择。Istio 和 Envoy 所代表的技术栈可以说是服务网格（Service Mesh）技术中影响力最大的，虽然持续也有一些关于 Istio 开放性的质疑，我们相信这个社区会朝着一个开放、健康的方向发展。

Istio 的架构演变

自 1.5 版本开始，Istio 的架构迭代回归务实。此后的相继推出的 1.6、1.7 版本也持续往简化、易用方向演进。

从设计之初，Istio 就遵循良好的架构设计模式，有清晰的控制面和数据面边界，其中控制面又由 Pilot、Citadel、Mixer、istio-sidecar-injector 等核心微服务组成，这些服务被设计单一职责，每个服务看似都有不可或缺的存在理由。但经过了近 3 年的社区发展和企业实践，Istio 在企业里大规模落地并不顺利，这导致其在易用性、可运维性、性能等方面受到了一些质疑，这些质疑声认为 Istio 看似漂亮的微服务化设计有过渡设计之嫌。

举几个简单的例子，比如我们网易轻舟服务网格（基于 Istio）在实际生产支撑过程中，控制面的多个服务通常会作为一个整体并由一个团队开发或运维，这会让微服务倡导的“2-pizza”规模团队独立负责单一服务失去优势，因为 Istio 控制面服务由多个团队来负责并无管理的便利；再比如控制面组件的主要资源消耗在 Pilot 的 xDS serving 上，其他组件的损耗相比 Pilot 微乎其微，这意味着控制面组件不用考虑独立的可伸缩性。

基于此，Istio 社区从 1.5 版本开始做出的最大的架构调整就是把控制面组件合并为一个 istiod 单体应用，牺牲掉 istio 控制面并不刚需的微服务特性以此换来单体应用的易用性和可运维性。这是一次非常务实的架构演进。

我们分析，驱动 Istio 进行这样架构演进的原因是面临服务网格标准化的竞争。Istio 由 Google 联合 IBM、Lyft 推出，与 K8s 可以说是同源的，有 K8s 在容器编排标准化方面取得的巨大成功经验在前，Istio 一经推出就受到了业界极大的关注，在 Istio 1.0 版本还没发布的时候就有声音认为它是服务网格的事实标准。但是开源软件的最大生命力来源是给用户带来价值，换句话说是 Istio 想要成为标准必须要有大量的生产环境实践案例来支撑。在这一点上 Istio 与 K8s 有很大不同，K8s 设计理念和架构都来自 Google 内部稳定运行了 10 多年的大规模容器集群管理系统 Borg，有 Borg 的背书，K8s 成为容器编排标准化几乎没有太大阻力。于是过去 5 年成为了 K8s 发展最快的 5 年࿰