从lstio的角度谈微服务的一些误区

在过去的五年中，我在帮助企业使用云原生技术方面投入了相当多的时间和精力。现实中团队的团队交付速度的提升，在很大程度上受其人员、过程和最终技术决策的影响。 当应用程序体系结构成为进行修改和开发的瓶颈（由于各种人员/流程/技术因素）时，微服务可能是合适的方法， 但这不是唯一的方法 。

微服务不是“乌托邦式应用程序体系结构”（译者注：指并不适用于一切）。

我曾经写过文章，认为许多团队无法实现这一目标 ， 如何有“艰巨的部分”使其发挥作用，甚至还提出了一些可能对您的工作有益的技术。

尽管今天许多组织都已实施了微服务，但是远离微服务依然可能是很好的起点。

假如您已经走上了微服务之路

如果您确实走上了微服务之路，请在无法使用微服务时对自己和组织说实话。正确的做法可能会导致产品的成功。

对微服务什么时候合适要诚实

尽管出于好意，但是在开始阶段使用单体应用是更好的选择。如果您的假设或决策周围的环境发生了变化，那么“回到单体应用”是“可以的”。

在为微服务通信构建服务网格的Istio社区中 ，控制平面的实现将逐渐从微服务方法变为更加单体的方法 。谷歌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–“Mixer”组件，负责将遥测汇总和联合到各个后端

• Policy –负责执行策略“Mixer”组件

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

微服务的好处

微服务可以通过减少对系统改进带来的摩擦，从而使组织更快地前进。在微服务架构下，每个服务可能会独立运行（每个服务都由自己的团队），并且具有彼此独立的发布节奏/生命周期。这将使开发人员和运维人员能够加快并行跟踪的速度，而不需要锁定/同步/协调这样的可能会降低开发和部署速度的措施。

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

以下是可以将应用拆分为服务的一些其他原因：

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

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

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

纠正过程

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

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

最后，在Istio案例中，是否istio各个组件的安全级别并不相同。实际上并没有。以下来自Istio设计文档：

对于大多数组件，今天的Istio情况并非如此-控制平面的成本由单个功能（服务XDS）支配。相比较而言，所有其他控制平面特征都具有边际成本，因此分离的价值很小。

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

如今情况并非如此，因为转换Webhook，Envoy引导程序和Pilot所行使的权力在许多方面与Citadel相似，因此对它们的利用会导致同样的损害力

正如Istiod设计文档中的潜台词所言： “复杂性是万恶之源“ 。

istiod是单体应用的化身，可支持以前发行版的所有功能，并且大大降低了复杂性。请注意，组成先前控制平面的服务仍被实现为项目内的子模块（带有边界和合约等），但是运维得到了改善。运维工程师现在不需要需要担心运行和升级单个二进制文件。

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

• 仅需一项可部署服务，安装/升级变得更加容易
• 由于不再需要用于协调服务的配置，因此降低了配置复杂性
• 更容易调试问题（在一个地方排查还是所有地方都看看）
• 提高效率/减少传输，共享缓存等的开销

有关更多详细信息，请参见Istiod设计文档 。

另外请注意： 我在istio 1.5中的这个 istiod方法demo 。只需注意，它是在Istio的alpha版本上运行的，并不能在所有版本上运行。

结论

我很高兴看到Istio社区继续改善其可用性和可运维的特性。Istio控制平面支持整体部署对于该项目非常有意义。这对您的项目有意义吗？如果这样做，您会考虑吗？您是否以一种能够确定更改方法的时间的方式来衡量微服务体系结构（及相关基础架构）的价值与复杂性比率？

如果您有想法要分享，请在Twitter上与我联系@christianposta 。一个好的跟进职位可以是决策表或关键指标的内容，这些指标可以决定一旦决定走微服务之路，就应该何时改变路线。如果您想为此做出贡献，请at我。

原文地址：

https://www.solo.io/blog/istio-as-an-example-of-when-not-to-do-microservices/

参考阅读：

本文由高可用架构翻译。技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构

改变互联网的构建方式

长按二维码 关注「高可用架构」公众号