何时不需要微服务架构,Istio1.5告诉你

过去五年中,我一直帮助企业进行云原生的实践。深刻体会到,当应用程序架构成为迭代的瓶颈时,微服务方法可能是合适的,但这不是唯一的方法

微服务不是“乌托邦式应用程序体系结构”。

关于这个主题,我也出了一本书–《Microservices for Java Developers》

尽管现在许多组织都已实现微服务架构,但远离微服务有时可能是最好的起点。

已经走上了微服务的道路

如果你已经走上了微服务之路,在无法使用微服务架构时请对自己和组织诚实,这会使你的产品更为成功。

有时还是会“回到整体”

出于各种考虑,组织使用了微服务,但有时还是会“回到整体”。

在为微服务通信构建服务网格Istio社区,控制平面的实现将逐渐从微服务方法变为更加单一的方法。谷歌API基础架构的首席工程师和架构师路易斯·瑞安Louis Ryan)在2019年KubeConNA的Istio聚会上,详细介绍了动机并在设计文档中介绍了该案例。从Istio 1.5(于2020年2月中旬)开始,我们就能看到该方法的效果,该方法将先前分配给各种微服务部署的功能合并为一个守护程序istiod

我们知道,Istio是用于帮助解决微服务/云架构所带来的挑战,那么Istio自身为何会脱离微服务架构?最直接的答案是:

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

对于Istio项目,“回到整体”可以更好地实现这些目标。

Istio:微服务架构方式(V1.5之前)

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

从Istio1.5之前版本上看,Istio的控制平面是可作为单独部署的服务,该服务执行以下操作:

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

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

微服务的好处

微服务可以通过减少对整体系统的修改,来使组织快速迭代。在微服务架构下,每个服务可能会独立运行(每个服务都有自己的团队),并且具有彼此独立的发布节奏/生命周期。这将使开发人员和运维人员可以并行,而无需锁定/同步/协调来进行更改,从而提高部署和功能更改的速度。

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

将应用拆分为微服务的其他一些原因:

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

转到微服务架构时,第一要权衡的是复杂性。当你从一个事物(整体)变为一堆小事物,微服务彼此通信时复杂性就会增加。

如果微服务架构带给你了如上的好处,你有必要权衡下。如果没有,最好重新评估并纠正。这就是Istio目前正在发生的事情。

Istio1.5:从微服务到单一

首先要了解的是谁在开发和操作你的服务体系结构。在Istio社区中,项目中有不同的组成部分,可以在不同的社区工作组中看到。如果以较大规模的SaaS运行,则Istio控制平面作为一组微服务将可以很好地工作,但是在目前,情况似乎并非如此。

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

最后,在Istio案例中,你可以问:“各个组件是否存在变量和安全问题的不同?” 实际上并没有。从Istio设计文档中可以看到:

Istio1.5之前,控制平面的成本由单个功能(服务XDS)控制。相比较而言,所有其他控制平面特征都具有边际成本,因此分离的价值很小。

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

Istio1.5之前,,通过Webhook, Envoy Bootstrap & Pilot 所行使的权力在许多方面与 Citadel 相似

正如Istiod设计文档中的潜台词所言:“复杂性是万恶之源,或:我如何学会不再担心和喜欢上整体架构”。

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

对于Istio进入单一控制平面,可以减少大量的复杂性,但是复杂性永远不会完全消失:

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

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

结论

很高兴看到Istio社区继续改善其可用性和可操作性。对Istio控制平面进行整体部署对于该项目非常有意义。这对你的项目有意义吗?如果这样做,你会考虑吗?你会在什么时候衡量微服务体系结构的价值与它带来复杂性的关系,会不会也要“回归整体”?

译文链接: https://blog.christianposta.com/microservices/istio-as-an-example-of-when-not-to-do-microservices/

K8S中文社区微信公众号

评论 2

登录后评论

立即登录  

  1. #1

    这么全面的教程,博主真厉害

    智慧小鸡5年前 (2020-04-04)