什么时候不要用微服务？以 Istio 为例

你已经走上了微服务之路

如果你真的走上了微服务之路，那么当其不奏效时，不管是对自己还是对公司都要实事求是。改变路线可能才是产品成功的正确步骤。



如果微服务不奏效，要勇于承认

尽管出发点是好的，在你出于正当的理由开始使用微服务后，返回单体架构仍然可能是正确的选择。如果你做出决策时的假设或上下文发生了变化，那么回到单体架构也“没关系”。



在 Istio 社区（为微服务通信构建服务网格），控制平面的实现将逐渐从微服务方法转变为更趋向于单体的方法。在2019 年KubeConNA 的Istio 大会上，谷歌API 基础架构首席工程师和架构师 Louis Ryan 发表了演讲，详细描述了这样做的动机，并在设计文档中介绍了大致的情况。从Istio 1.5 开始，我们应该就可以看到 istiod方法的效果， 以前分配给各种微服务部署的功能将被合并到一个守护进程中。



Istio 用于帮助解决由微服务 / 云架构引入的应用程序网络难题，那么 Istio 本身为什么要远离微服务架构呢？最直接的答案是：



事实证明，微服务方法非常复杂，但没有提供预期的价值或目标。相反，它违背了这些目标。



对于 Istio 项目来说，单体架构似乎能更好地实现这些目标。下面，我们将做进一步地分析。



Istio 以微服务的方式实现

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





过去，Istio 的控制平面被实现为可单独部署的服务，它们的用途如下：



Pilot —— 核心数据平面配置（xDS）服务器

Galley —— 配置监控、验证、转发

Injector —— 负责自动注入数据平面并设置引导程序

Citadel —— 证书签名、Secret 生成、CA 集成

Telemetry —— 一种“混合器”组件，负责将遥测数据聚合到各种后端

Policy —— 一个请求路径“混合器”组件，负责执行策略

这些服务将根据一组操作人员定义的配置，共同提供和管理数据平面。



微服务的好处

微服务可以减少系统更改时的分歧，提升组织速度。在微服务架构中，每个服务可能都是独立运营的（每个服务都有自己的团队），并且有独立于其他服务的发布节奏 / 生命周期。这将使开发人员和运营人员可以并行不悖，而不需要进行锁定 / 同步 / 协调（这些可能会减慢部署和特性更改的速度），提升了更改速度。



服务可能会被进一步分解的另一个原因是它的使用模式和可伸缩性。举个简单的例子，一个具有大量读写操作的服务可以从读写操作分离中受益，因为读操作可能会消耗更多的内存（可能需要比较多的缓存空间才能提供超快的读取速度），而写操作可能会消耗更多的存储或网络。你能在可以独立伸缩的机器 / 配额上优化服务的读操作部分（内存更大），然后在其他具有 SSD 或经过优化的 EBS/SAN 的机器上优化服务的写操作部分。



以下是其他可能让你将应用分解成服务的原因：



• 安全问题

• 领域划分

• 不同的语言优化

• 服务的重要性

采用微服务架构的首要代价是复杂性。当你从一个东西（单体）变成一堆相互通信的小东西（针对特定问题进行了优化）时，显著增加了架构和运行这些东西所需的基础设施的复杂性。



如果你实现了微服务的好处，那么这可能是一个必要的代价。如果没有，你最好评估一下你的假设，并改变路线。这就是 Istio 现在的情况。



改变路线

首先，要了解的是谁在开发和运营你的服务架构。在 Istio 社区，项目中不同的组件由不同的社区工作组负责。另一方面，下载和操作 Istio 的人并不是这样划分的。事实上，根据到目前为止的观察，Istio 控制平面是由同一组人（甚至是一个人）操作的。在某种程度上，如果 Istio 控制平面的一组微服务作为一个较大的 SaaS 运行，那么它会工作得很好，但在目前的使用中，情况似乎并非如此。



其次，要了解的是发布是如何完成的？服务可以独立发布吗？Istio 的答案是“理论上是”，但实际上似乎不是这样。Istio 的新版本发布时，需要升级 / 部署所有控制面组件。



最后，在 Istio 的情况下，你可能会问，“对于各种不同的组件，难道没有不同的伸缩变量和安全考虑吗？”老实说，并没有。下面这段话节选自 Istio istiod的设计文档 ：



然而，对于现在的大多数 Istio 组件来说，情况并非如此——控制平面的成本主要由一个特性（服务于 XDS）决定。相比之下，其他控制平面特性都有边际成本，因此，分离的价值不大。



出于安全考虑，控制平面的所有服务都有相同的权限等级：



现状并非如此，Mutating Webhook、Envoy Bootstrap 和 Pilot 的权限在许多方面与 Citadel 相似，因此，对它们进行攻击造成的伤害几乎相同。



正如 Istiod 设计文档的所言：“复杂性是万恶之源，否则：我怎么能学会不再忧虑并爱上单体”。



istiod是一个单体，它支持以前版本的所有功能，并且显著降低了复杂性。请注意，以前组成控制平面的服务在项目中仍然是作为子模块实现（包括边界和契约等），但操作体验得到改善。操作人员现在只需要考虑运行和升级单个二进制文件，而不再是一批二进制文件。





对于 Istio 来说，采用单体控制平面，可以大大降低复杂性，而这种复杂性之前并没有为我们带来足够的回报：



• 只有一个服务需要部署，安装 / 升级变得简单了

• 配置复杂性降低了，因为不再需要通过配置编排服务

• 问题调式更容易了（只需要在一个地方查找问题，而不是多个地方）

• 提高了效率，降低了数据传输开销、共享缓存，等等

• 想了解更多信息，请参阅 Istiod 的设计文档。



另外，你可以观看我做的istiod方法演示，它应该会出现在 Istio 1.5 中。请注意，该演示使用了 Istio 的 super alpha 版本，所以还不是很完美。



小结

我很高兴看到 Istio 社区继续改进 Istio 的可用性和可操作性。Istio 控制平面的单体部署对这个项目很有意义。这对你的项目有意义吗？如果是这样，你会考虑吗？你是否也会像这样计算自己的微服务架构（和相关基础设施）的价值与复杂性比，从而确定变换方法的时间呢？



最近整理了java架构文档和学习笔记文件以及架构视频资料和高清架构进阶学习导图免费分享给大家（包括Dubbo、Redis、Netty、zookeeper、Spring cloud、分布式、高并发等架构技术资料），希望能帮助到您面试前的复习且找到一个好的工作，也节省大家在网上搜索资料的时间来学习，也可以关注我一下以后会有更多干货分享。



【微服务课】基于支付系统场景的微服务架构的分布式事务解决方案视频课程

需要的可以关注 转发+转发+转发 私信回复关键词 【学习】即可获取免费分享给大家