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

本文最初发布于 Christian Posta 的个人博客，经原作者授权由 InfoQ 中文站翻译并分享。
在过去五年，我投入大量精力来帮助企业踏上云原生之旅。很大程度上，对团队（最终是组织）基于软件的技术交付速度进行现代化提升受到人员、过程和最终技术决策的影响。当应用程序的架构（由于各种人员 / 流程 / 技术因素）成为修改和“加快速度”的瓶颈时，微服务方法可能会合适，但也不是唯一的方法。
我曾在以前的文章中提到，许多团队都无法完美地实现它，让微服务运行需要克服一些“困难” 。同时，我还提到一些长远来看可能对你工作有益的技术。我甚至还写了一本关于这个主题的书。
开始的时候，最好是远离微服务，不过现在，许多组织已经远远过了这个阶段。
你已经走上了微服务之路如果你真的走上了微服务之路，那么当其不奏效时，不管是对自己还是对公司都要实事求是。改变路线可能才是产品成功的正确步骤。
如果微服务不奏效，要勇于承认尽管出发点是好的，在你出于正当的理由开始使用微服务后，返回单体架构仍然可能是正确的选择。如果你做出决策时的假设或上下文发生了变化，那么回到单体架构也“没关系” 。
在 Istio 社区（为微服务通信构建服务网格），控制平面的实现将逐渐从微服务方法转变为更趋向于单体的方法。在2019 年KubeConNA 的Istio 大会上，谷歌API 基础架构首席工程师和架构师 Louis Ryan 发表了演讲，详细描述了这样做的动机，并在设计文档中介绍了大致的情况。从Istio 1.5 开始，我们应该就可以看到 istiod方法的效果，以前分配给各种微服务部署的功能将被合并到一个守护进程中。
Istio 用于帮助解决由微服务 / 云架构引入的应用程序网络难题，那么 Istio 本身为什么要远离微服务架构呢？最直接的答案是：

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

对于 Istio 项目来说，单体架构似乎能更好地实现这些目标。下面，我们将做进一步地分析。
Istio 以微服务的方式实现【什么时候不要用微服务？以 Istio 为例】Istio 是一个开源的服务网格，其架构与其他服务网格的实现类似，包括一个控制平面和一个数据平面。数据平面由与每个应用程序实例共存并位于请求路径中的代理组成。控制平面位于请求路径之外，用于管理和控制数据平面的行为。

文章插图

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

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

这些服务将根据一组操作人员定义的配置，共同提供和管理数据平面。
微服务的好处微服务可以减少系统更改时的分歧，提升组织速度。在微服务架构中，每个服务可能都是独立运营的（每个服务都有自己的团队），并且有独立于其他服务的发布节奏 / 生命周期。这将使开发人员和运营人员可以并行不悖，而不需要进行锁定 / 同步 / 协调（这些可能会减慢部署和特性更改的速度），提升了更改速度。
服务可能会被进一步分解的另一个原因是它的使用模式和可伸缩性。举个简单的例子，一个具有大量读写操作的服务可以从读写操作分离中受益，因为读操作可能会消耗更多的内存（可能需要比较多的缓存空间才能提供超快的读取速度），而写操作可能会消耗更多的存储或网络。你能在可以独立伸缩的机器 / 配额上优化服务的读操作部分（内存更大），然后在其他具有 SSD 或经过优化的 EBS/SAN 的机器上优化服务的写操作部分。
以下是其他可能让你将应用分解成服务的原因：