Categories
程式開發

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


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

本文最初发布于Christian Posta的个人博客,经原作者授权由InfoQ中文站翻译并分享。

在过去五年,我投入大量精力来帮助企业踏上云原生之旅。很大程度上,对团队(最终是组织)基于软件的技术交付速度进行现代化提升受到人员、过程和最终技术决策的影响。当应用程序的架构(由于各种人员/流程/技术因素)成为修改和“加快速度”的瓶颈时,微服务方法可能会合适,但也不是唯一的方法

我曾在以前的文章中提到,许多团队都无法完美地实现它让微服务运行需要克服一些“困难”。同时,我还提到一些长远来看可能对你工作有益的技术。我甚至还写了一本关于这个主题的

开始的时候,最好是远离微服务,不过现在,许多组织已经远远过了这个阶段。

你已经走上了微服务之路

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

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

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

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

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

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

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

Istio以微服务的方式实现

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

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

过去,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为例 3

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

  • 只有一个服务需要部署,安装/升级变得简单了
  • 配置复杂性降低了,因为不再需要通过配置编排服务
  • 问题调式更容易了(只需要在一个地方查找问题,而不是多个地方)
  • 提高了效率,降低了数据传输开销、共享缓存,等等

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

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

小结

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

英文原文:

Istio as an Example of When Not to Do Microservices