转载

为微服务构建服务网格的Istio自身却走向微服务的反面单体架构 – Christian Posta

在为微服务通信构建服务网格的Istio社区中，控制平面的实现将逐渐从微服务方法变为更加monlith的方法。也就是说。Istio自身正在变成微服务的敌人单体整体Monolith，谷歌API基础架构的首席工程师和架构师路易斯·瑞安（ Louis Ryan）在2019年KubeConNA的Istio聚会上接受采访，详细介绍了这种动机并在设计文档中概述了该案例。从Istio 1.5（预计于2020年2月中旬）开始，我们应该开始看到这种路线方法的效果，将先前分配给各种微服务部署的功能合并为一个守护程序：istiod。

Istio用于帮助解决微服务/云架构所带来的困难的应用程序网络挑战，那么Istio自身为何会脱离微服务架构？最直接的答案是：

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

对于Istio项目，似乎采用单体架构可以更好地实现这些目标。让我们仔细看看。

Istio在应用微服务中定位

Istio是一个开源服务网格，其结构类似于具有控制平面和数据平面的其他服务网格实现。数据平面由与每个应用程序实例一起存在并位于请求路径中的代理组成。控制平面位于请求路径之外，用于管理和控制数据平面的行为。

从历史上看，Istio的控制平面是作为可单独部署的服务实现的，该服务执行以下操作：

Pilot -核心数据平面配置（xDS）服务器
Galley -配置监视，验证，转发
Injector -负责自动注入数据平面并设置引导程序
Citadel -证书签名，秘密生成，与CA集成等
Telemetry -一个“混合器”组件，负责将遥测数据聚合和联合到各种后端
Policy -负责执行策略的请求路径“混合器”组件

这些服务将由一组运营商定义的配置来驱动，并进行协调以最终服务和指导数据平面

微服务的好处

微服务可以通过减少对系统进行更改的摩擦来使组织更快地前进。使用微服务架构，每个服务可能会独立运行（每个服务都由自己的团队），并且具有独立于其他人的自己的发布节奏/生命周期。这将使开发人员和操作员可以并行移动，从而更快地移动，而无需进行更改的锁定/同步/协调，这可以减慢部署和功能的更改。

可能进一步细分服务的另一个原因是其使用模式和扩展属性。举一个简单的例子，具有大量读取和写入操作的服务可能会受益于将读取与写入分开，因为读取可能会占用更多的内存（可能需要更多的缓存空间才能使读取速度更快），而写入可能会占用更多的存储空间或网络。您可以在机器/配额上优化服务的读取部分，以使其能够独立扩展（更多内存），然后在具有SSD或优化的EBS / SAN等的其他机器上使服务的写入部分。

您可能将应用拆分为服务的其他一些原因：

安全问题
域分组
不同的语言优化
服务的重要性

转到微服务架构时，第一要权衡的是复杂性。当您从一个事物（整体）变为一堆小事物（彼此进行通信（以针对特定问题进行优化））时，您会大大增加架构和运行事物所需的基础结构的复杂性。

就您意识到的好处而言，这可能是必要的权衡。如果没有，最好评估一下您的假设并纠正过程。这就是Istio目前正在发生的事情。

纠正过程

首先要了解的是谁在开发和操作您的服务体系结构。在Istio社区中，项目中有不同的组成部分，可以在不同的社区工作组中看到。另一方面，下载和操作Istio安装的角色并不那么容易构建。实际上，到目前为止，观察到的是一个小组（甚至一个人）操作Istio控制平面。在某些方面，如果将Istio控制平面作为一组微服务，则可以在较大的SaaS上运行，但效果很好，但是在当前采用的情况下似乎并非如此。

要了解的第二件事就是如何完成发布，服务可以独立发布吗？在实践中，Istio的答案在理论上是“肯定的”，事实并非如此。当发布新版本的Istio时，您需要升级/部署所有控制面板组件。

最后，在Istio案例中，您可以问“在各个组件中是否还存在其他不同的缩放变量和安全问题？”而诚实的答案将意识到实际上并没有。直接从Istio设计文档中获取istiod：

正如Istiod设计文档中的潜台词所言：“复杂性是万恶之源，或者：我如何学会不再担心和爱单体monolith”。

istiod是单体整体monlith的化身，它以更低的复杂度支持了以前发行版的所有功能。请注意，组成先前控制平面的服务仍被实现为项目内的子模块（带有边界和合同等），但是操作经验得到了改善。运维人员现在需要担心运行和升级单个二进制文件还是它们的集合。

对于Istio进入单体控制平面，可以减少大量的复杂性，而这些复杂性永远不会完全得到回报：