Istiod——回到单体的理由

原文：Istio as an Example of When Not to Do Microservices

作者：Christian Posta

近五年来，我尽心尽力帮助各种组织踏入云原生之路。要让团队变得现代化并增强基于软件的产品的交付能力，人、过程以及技术决策都很重要。当应用架构的上限已经成为应对变化和加速发展的瓶颈时，微服务方法可能是合适的，但这并不是唯一的方法。

微服务并非应用架构的乌托邦。

过去，我在这方面发表了一些看法，例如我认为很多团队无法将其落地，实现过程中的困难之处，还提出了一些长远来看会对这项工作有益处的技术。甚至还写了一本书来讲述这一主题。

尽管很多组织已经踏上微服务之旅，远离微服务一文仍然可能是个好起点。

如果你已经踏上了微服务旅程

如果发现微服务不灵，就该正视现实。拨乱反正是做出成功产品的正确举措。

尽管出发点是好的，但开始使用微服务之后，开倒车还是有可能的。如果之前的假设或周遭环境已经发生了变化，重回单体架构也是可以理解的。

为微服务通信构建服务网格的 Istio 社区，控制平面的实现将最终从微服务架构转向更为单体的方式。Google API 基础设施的首席工程师和架构师 Louis Ryan，在 2019 年 KubeConNA 上讲述了这一变化的动机，并在设计文档中进行了阐述。从 Istio 1.5 开始（可能会在 2020 年 2 月中旬），我们可能就会看到 istiod 了，这个组件把前作中多个组件集成为单一进程。

Istio 用于解决因为微服务、云原生架构引入的复杂的应用网络问题，所以为什么 Istio 自身却反其道而行之？最直接答案是：

事实证明，微服务的复杂性无法实现其预期的价值或目标。相反，它违背了这些目标。

对于 Istio 项目来说，似乎单体方式能更好的为目标服务。

微服务模式的 Istio

Istio 是一个开源的服务网格产品，其实现和其它同类产品大同小异，由控制平面和数据平面组成。数据平面由反向代理服务器组成，这些反向代理和各个应用实例伴行，并替代应用行使通信职责。控制平面在请求路径之外，用于对数据平面的行为进行管控。

Istio 的控制平面分为几个组成部分，其职责如下：

• Pilot：核心的数据平面配置（xDS）服务器。
• Galley：配置监听、验证和转发。
• Injector：负责数据平面的注册和初始化。
• Citadel：证书签发、Secret 生成、CA 集成等。
• Telemetry：Mixer 组件之一，负责聚合监控信息到多种后端。
• Policy：Mixer 组件之二，在请求路径之中负责实现策略支持。

运维人员通过一组配置指令来借由这些部件为数据平面提供服务并对其进行控制。

微服务的好处

微服务能够降低变更过程中因为耦合产生的冲突，因此能加快组织的调整速度。有了微服务架构的帮助，每个服务都能可以有自己的团队，独立进行运维，有各自的变更频率和生命周期。这使得开发和运维能够轻装上阵，不会因为变更过程中的锁定、同步、协作等问题拖慢部署和变更的进度。

拆分成微服务的另一个原因就是它的用法和扩展方式。例如一个需要大量读写的服务，能从读写分离上受益，这是因为读取过程需要更多内存（缓存），而写入需要更多的存储或者网络资源。拆分之后就可以放心的给读取服务分配大量内存，而写入服务则可以运行在 SSD 或者 EBS/SAN 等设施加持的服务器上。

拆分微服务的另外几个理由：

• 安全考虑
• 领域分隔
• 针对不同语言的优化
• 安全分级

微服务架构的复杂性是第一号问题。当单体应用拆分为一些互相通信的小玩意之后，架构的复杂性以及对应的基础设施的复杂性都显而易见地提高了。

除非已经清楚的意识到，这是为了获得更多好处，而做出的一种必要的妥协；否则就应该对假设进行评估，并及时做出反应——这就是 Istio 现在的举措。

回头草

首先要清楚，你的服务是谁开发谁运维的。在 Istio 社区，项目里不同的工作组维持着不同的组件。另一方面，下载、安装和运维 Istio 的用户就不那么清楚了。目前看来，都是由单一的工作组（甚至一个人）在操作 Istio 的控制平面。某种程度上，一组微服务构建的 Istio 控制平面更适合被当做一个更大规模的 SaaS 看待，但是目前的情况看来并非如此。

第二个需要注意的就是部署问题。这些微服务能独自部署么？Istio 的回答是：理论上可以，但实际上可能并非如此。当新版本 Istio 发布时，需要更新/部署所有控制平面的组件。

最后一个问题：”Istio 的各个组件，有各自不同的安全考量和伸缩需求吗？“，答案也并不肯定。来自 istiod 的一段陈述：

目前看来，对于多数组件来说并非如此。然而——控制平面的成本由单一的功能（xDS）决定。相对而言，其它所有组件的消耗微不足道，因此分离并无必要。

为了安全起见，所有的控制平面都处于相同的特权级别：

当前的情况下，Mutating Webhook、Envoy Bootstrap 以及 Pilot，这几个组件的特权级别和 Citadel 基本持平，对它们的滥用所引发的损失几乎相同。

Istio 设计文档中的潜台词就是——“复杂性是万恶之源，或者换个说法：停止焦虑，爱上单体”。

istiod 是一个单体应用，它用较低的复杂性提供了和之前版本一致的功能。组成旧版控制平面的服务都还以子模块的方式存在于项目之中，但提供了更好的运维体验。操作者只需关注单一二进制文件的运行和升级了。

Istio 一旦转向单体的控制平面，会大幅降低复杂性，从而：

• 只需要对一个单独的服务进行部署和升级。
• 因为无需关注编排服务自身的配置，因此配置复杂度也降低了。
• 更容易除错。
• 提高分发、共享和缓存的效率，降低开销。

另外你可以看一下 Istiod 的 Demo 视频。这个视频基于一个早期版本，因此并不完善。

结论

很高兴看到 Istio 社区在持续提高其易用性和可运维性。转向单体应用的 Istio 带来了很多好处。这个过程会对你的项目产生什么启发么？如果有的话，你会采取什么措施么？

相关链接

• Istio设计文档：https://docs.google.com/document/d/1v8BxI07u-mby5f5rCruwF7odSXgb9G8-C9W5hQtSIAg/edit#
• Istiod 的 Demo 视频：https://www.youtube.com/watch?v=QD115XiBXwY
• 远离微服务：https://blog.christianposta.com/microservices/when-not-to-do-microservices/