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

浅浅的花香味﹌ 2023-07-24 11:54 51阅读 0赞

**目录**

已经走上了微服务的道路

有时还是会“回到整体”

Istio：微服务架构方式（V1.5之前）

微服务的好处

Istio1.5：从微服务到单一

结论

--------------------

> **原文发表于[kubernetes中文社区][kubernetes]，为作者原创翻译 ，[原文地址][Link 1]**
> 
> **更多kubernetes文章，请多关注[kubernetes中文社区][kubernetes]**

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

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

关于这个主题，我也出了一本书--[《Microservices for Java Developers》][Microservices for Java Developers]。

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

## 已经走上了微服务的道路 ##

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

## 有时还是会“回到整体” ##

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

![20200411173811557.png][]

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

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

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

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

## Istio：微服务架构方式（V1.5之前） ##

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ_size_16_color_FFFFFF_t_70][] Istio：微服务架构方式（V1.5之前）

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

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

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

## 微服务的好处 ##

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

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

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

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

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

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

## Istio1.5：从微服务到单一 ##

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

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

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

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

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

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

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

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ_size_16_color_FFFFFF_t_70 1][] istiod

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

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

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

## 结论 ##

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

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

[kubernetes]: https://www.kubernetes.org.cn/
[Link 1]: https://www.kubernetes.org.cn/7168.html
[Link 2]: https://blog.christianposta.com/microservices/when-not-to-do-microservices/
[Microservices for Java Developers]: https://www.oreilly.com/library/view/microservices-for-java/9781492042228/
[20200411173811557.png]: /images/20230528/be9c5aff823f4d22a440a56d192e5f2b.png
[Link 3]: https://istio.io/docs/concepts/what-is-istio/#what-is-a-service-mesh
[Istio]: https://istio.io/
[Link 4]: https://docs.google.com/document/d/1v8BxI07u-mby5f5rCruwF7odSXgb9G8-C9W5hQtSIAg/edit#
[Link 5]: https://twitter.com/louiscryan?lang=en
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ_size_16_color_FFFFFF_t_70]: /images/20230528/eb22cd0101ca4b6b91d3ea6a77f13db4.png
[Link 6]: https://github.com/istio/community/blob/master/WORKING-GROUPS.md
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ_size_16_color_FFFFFF_t_70 1]: /images/20230528/ae7d76caa0fa4105b2251b42c4f959e7.png
[https_blog.christianposta.com_microservices_istio-as-an-example-of-when-not-to-do-microservices]: https://blog.christianposta.com/microservices/istio-as-an-example-of-when-not-to-do-microservices/