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

如果你实现了微服务的好处，那么这可能是一个必要的代价。如果没有，你最好评估一下你的假设，并改变路线。这就是 Istio 现在的情况。
改变路线首先，要了解的是谁在开发和运营你的服务架构。在 Istio 社区，项目中不同的组件由不同的社区工作组负责。另一方面，下载和操作 Istio 的人并不是这样划分的。事实上，根据到目前为止的观察，Istio 控制平面是由同一组人（甚至是一个人）操作的。在某种程度上，如果 Istio 控制平面的一组微服务作为一个较大的 SaaS 运行，那么它会工作得很好，但在目前的使用中，情况似乎并非如此。
其次，要了解的是发布是如何完成的？服务可以独立发布吗？Istio 的答案是“理论上是”，但实际上似乎不是这样。Istio 的新版本发布时，需要升级 / 部署所有控制面组件。
最后，在 Istio 的情况下，你可能会问，“对于各种不同的组件，难道没有不同的伸缩变量和安全考虑吗？”老实说，并没有。下面这段话节选自 Istio istiod的设计文档：

然而，对于现在的大多数 Istio 组件来说，情况并非如此——控制平面的成本主要由一个特性（服务于 XDS）决定。相比之下，其他控制平面特性都有边际成本，因此，分离的价值不大。

出于安全考虑，控制平面的所有服务都有相同的权限等级：

现状并非如此，Mutating Webhook、Envoy Bootstrap 和 Pilot 的权限在许多方面与 Citadel 相似，因此，对它们进行攻击造成的伤害几乎相同。

正如 Istiod 设计文档的所言：“复杂性是万恶之源，否则：我怎么能学会不再忧虑并爱上单体” 。
istiod是一个单体，它支持以前版本的所有功能，并且显著降低了复杂性。请注意，以前组成控制平面的服务在项目中仍然是作为子模块实现（包括边界和契约等），但操作体验得到改善。操作人员现在只需要考虑运行和升级单个二进制文件，而不再是一批二进制文件。

文章插图

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

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

想了解更多信息，请参阅 Istiod 的设计文档。
另外，你可以观看我做的istiod方法演示，它应该会出现在 Istio 1.5 中。请注意，该演示使用了 Istio 的 super alpha 版本，所以还不是很完美。
小结我很高兴看到 Istio 社区继续改进 Istio 的可用性和可操作性。Istio 控制平面的单体部署对这个项目很有意义。这对你的项目有意义吗？如果是这样，你会考虑吗？你是否也会像这样计算自己的微服务架构（和相关基础设施）的价值与复杂性比，从而确定变换方法的时间呢？