微服务——版本组合爆炸！

随着 IT 领域向微服务的转变，以及诸如 Kubernetes 之类工具的蓬勃发展，一个挥之不去的问题开始慢慢地全面显露出来。这就是各种微服务版本的组合爆炸（Combinatorial Explosion of versions）。社区的期望是，它至少要比以前的依赖地狱（dependency hell）好一些。但尽管如此，对基于微服务的产品进行版本控制仍然是一个相当困难的问题。为了证明这一点，像《把我的单体应用还给我》这样的文章会立刻浮现在脑海中。

组件版本的组合爆炸

让我来给你解释一下这是怎么回事吧。假设我们的产品由 10 个微服务组成。现在假设每个微服务都有一个新版本。只有一个版本（这是我们都清楚的，这听起来很微不足道）。现在回过头来看下我们的产品。每个组件只有一个新版本，那么我们现在就有 2^10 种组合，即可以对我们的产品进行 1024 种排列组合。

如果还没有完全弄清楚，让我用数学解释一下吧。我们有 10 个微服务，每个都有一个更新。因此，每个微服务都有两个可能的版本（旧版本或更新后的版本）。现在，对于每个组件，我们可以使用这两个版本中的任何一个。这相当于一个有 10 位的二进制数。例如。假设 1 代表新版本，0 代表旧版本，所以，在只更新第 1 个和第 4 个组件其他组件无更新的情况下，会得到一个排列 1001000000。利用数学，我们知道 10 位的二进制数有 2^10 或 1024 种变化。这正是我们要处理的数字。

现在，继续我们的思考。假设我们有 100 个微服务和 10 个可能的版本，又会怎样呢？整个事情会变得很糟糕。它将是 10^100 个排列组合，这是一个很大的数字。对我来说，这样很好，因为现在我们不是躲在“kubernetes”这样的字眼后面，而是要面对这个棘手的问题。

为什么我对这个问题如此着迷呢？部分原因来自 NLP/AI 领域，我们在 5-6 年前就已经在积极讨论这个领域的组合爆炸问题了。我们只是用不同的词代替了版本，用句子和段落代替了产品。现在，虽然 NLP 和 AI 的问题基本上还没有解决，但事实上，最近已经取得了实质性的进展（对我来说，如果人们对机器学习不再那么痴迷，对其他技术考虑得更多一些，进展可能会更快一些，但这是题外话）。

现在，回到容器和微服务的 DevOps 领域。我们面临着一个巨大的问题，我经常会听到：只要使用 kubernetes 和 helm，一切都会好起来的。你猜怎么着，光靠自己是不行的。更重要的是，封闭式地解决这类问题是行不通的。就像在 NLP 中一样，我们首先应该通过限制搜索空间来解决这个问题，即修剪过时的排列。

”修剪过时的排列“对此很有帮助，我去年在这篇“生产中需要维持最小版本跨度”博客中也提到过。此外，值得注意的是，良好的 CI/CD 过程对修剪变化也有很大的帮助。但是，如果没有适当的核算、跟踪和工具来处理组件的实际排列，CI/CD 的当前状态是不够的。

我们需要更大规模的集成阶段实验，在那里我们可以建立每个组件的风险因素，通过自动化的过程来升级不同的组件，并在没有人为干预的情况下进行测试，看看哪些组件是有效的，哪些是无效的。

所以这个系统应该是这样的：

1. 开发人员编写测试（这一点至关重要，否则就没有参考点了，它就像是在 ML 中标记数据一样）

2. 每个组件（项目）都有自己定义良好的 CI 管道，到目前为止，这一过程已经被很好地建立了，每个组件的 CI 问题基本上已经基本解决了

3. “智能集成引擎”位于各种 CI 管道的顶部，将组件项目组装到最终的产品中，运行测试，并在给定当前组件的情况下找出完成功能所需的最短路径，并计算风险因素。如果不能进行升级，引擎就会向开发人员发出警告，告诉他们最佳候选对象是什么以及是哪些地方导致地失败。同样，测试也是至关重要的，集成引擎会使用测试作为参考点。

4. 然后，CD 管道从智能集成引擎中提取数据并执行实际的发布。这样就完成了整个循环流程。

总之，对我来说，目前最大的困难之一是缺少一个集成引擎，该引擎可以将各种组件组合到产品中，从而可以对整个产品的实际工作方式进行适当的跟踪。如果你能提出这方面的想法建议，我会很感激的（剧透下，我目前正在Reliza上开发“智能集成引擎”。）

最后我想说的是，对我来说，“单体”（monolith）并不是任何大型项目的最终答案。因此，我非常怀疑是否真的有人试图通过回到“单体”来改善交付周期和交付质量。首先，”单体“在不同库之间存在类似的依赖管理问题，只是它在很大程度上被隐藏在开发阶段了。因此，人们无法真正地在“单体”上做出任何改变，所以整个过程都会慢如蜗牛。

微服务使事情变得更好了，只是随后它们在集成阶段遭遇了版本控制的爆炸。是的，本质上，我们是将同样的问题从开发阶段转移到了集成阶段。但是，在我看来，它仍然是变得更好的，团队使用微服务后实际上运行地更快了（可能只是因为批处理的规模更小）。尽管如此，到目前为止，我们通过将“单体”分解为“微服务”所取得的进步还远远不够，组件的版本爆炸是一个巨大的问题，我们还有很大的潜力使事情变得更好。

请链接到HN进行讨论。

原文链接：

Microservices – Combinatorial Explosion of Versions