随着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的当前状态是不够的。
我们需要更大规模的集成阶段实验,在那里我们可以建立每个组件的风险因素,通过自动化的过程来升级不同的组件,并在没有人为干预的情况下进行测试,看看哪些组件是有效的,哪些是无效的。
所以这个系统应该是这样的:
总之,对我来说,目前最大的困难之一是缺少一个集成引擎,该引擎可以将各种组件组合到产品中,从而可以对整个产品的实际工作方式进行适当的跟踪。如果你能提出这方面的想法建议,我会很感激的(剧透下,我目前正在Reliza上开发“智能集成引擎”。)
最后我想说的是,对我来说,“单体”(monolith)并不是任何大型项目的最终答案。因此,我非常怀疑是否真的有人试图通过回到“单体”来改善交付周期和交付质量。首先,”单体“在不同库之间存在类似的依赖管理问题,只是它在很大程度上被隐藏在开发阶段了。因此,人们无法真正地在“单体”上做出任何改变,所以整个过程都会慢如蜗牛。
微服务使事情变得更好了,只是随后它们在集成阶段遭遇了版本控制的爆炸。是的,本质上,我们是将同样的问题从开发阶段转移到了集成阶段。但是,在我看来,它仍然是变得更好的,团队使用微服务后实际上运行地更快了(可能只是因为批处理的规模更小)。尽管如此,到目前为止,我们通过将“单体”分解为“微服务”所取得的进步还远远不够,组件的版本爆炸是一个巨大的问题,我们还有很大的潜力使事情变得更好。
原文链接:
领取专属 10元无门槛券
私享最新 技术干货