Get best of the week

微服务-版本的组合爆炸

哈Ha！我向您介绍了微服务-版本组合爆炸文章的作者翻译。
图片

在IT世界逐渐转向Kubernetes等微服务和工具的时代，只有一个问题变得越来越明显。这个问题是微服务版本的组合爆炸。但是，IT界认为，当前的情况要比上一代技术的“依赖关系”好得多。但是，微服务的版本控制是一个非常复杂的问题。可以在“将我的巨石归还给我”之类的文章中找到这种证明之一。

如果您正在阅读本文，但仍然不明白问题所在，请让我解释一下。假设您的产品包含10个微服务。现在，假设为这些微服务中的每一个发布了一个新版本。仅版本1-我希望我们都同意这是一个非常琐碎且无关紧要的事实。现在，请再次查看我们的产品。现在，每个组件只有一个新版本，因此我们可以对产品的组成进行2 ^ 10-或1024个排列。

如果仍有误解，让我扩展一下数学。因此，我们有10个微服务，每个微服务都会收到一个更新。也就是说，我们为每个微服务（旧的或新的）都有2个可能的版本。现在，对于每个产品组件，我们可以使用这两个版本中的任何一个。从数学上讲，这与二进制数为10个字符的情况相同。例如，假设1是新版本，0是旧版本-那么可以将一个可能的排列指定为1001000000-其中第1个和第4个组件被更新，而其余所有组件都没有更新。从数学上，我们知道10个字符的二进制数可以具有2 ^ 10或1024个值。也就是说，我们已经确认了它所处理的数量规模。

我们将继续进行讨论-如果我们有100个微服务，每个微服务都有10个可能的版本，会发生什么？整个情况变得非常不愉快-现在我们有10 ^ 100个排列-这是一个巨大的数字。尽管如此，我还是喜欢这样描述这种情况，因为现在我们并没有躲在诸如“ kubernetes”之类的词后面，而是我们正面临着这个问题。

为什么这个问题令我着迷？部分是因为在NLP和AI领域工作较早，我们讨论了大约5至6年前的许多组合爆炸问题。我们没有版本，而只有单独的单词，没有产品，而只有句子和段落。尽管NLP和AI的问题仍未解决，但我们必须承认，过去几年已经取得了重大进展。（在我看来，进步可以用于以 lshim如果业内人士有点不太注意支付给机器学习等技术，多一点-不过这是题外话）。

我将回到DevOps和微服务的世界。我们面临着一个巨大的问题，在Kunstkamera中伪装成一头大象-因为我经常听到的是“只要拿起Kubernetes和头盔，一切都会好起来的！”但是不，如果一切都按原样进行，那一切都不会好。而且，鉴于复杂性，对该问题的分析解决方案似乎不可接受。像在NLP中一样，我们应该首先通过缩小搜索范围来解决此问题-在这种情况下，通过消除过时的排列。

可以帮忙的一件事-我去年写过关于需要在为客户设计的版本之间保持最小差异的需求。还需要注意的是，完善的CI / CD流程在减少偏差方面非常有帮助。但是，如果没有其他用于记录和跟踪组件的工具，CI / CD的当前状态不足以解决排列问题。

我们需要的是在集成阶段的实验系统，在该系统中，我们可以确定每个组件的风险因素，并且还具有一个自动化的过程，可以在无需操作员干预的情况下更新各种组件和进行测试-看看什么有效，什么无效。

这样的实验系统可能如下所示：

  1. ( — — ).
  2. () CI — , CI
  3. « » CI - , . , . , — .
  4. CD , « » . .

总结起来，对我来说，现在最大的问题之一是缺少这样一个“智能集成系统”，该系统会将各个组件链接到产品中，从而使您能够跟踪产品的整体组成。我会对社区对此的想法感兴趣（破坏者-我目前正在从事Reliza项目，该项目可能会成为这样的智能集成系统）。

我要提到的最后一件事是，对于任何中等规模的项目，单块都是不可接受的。对我来说，对于通过返回整体来加快实现时间和提高开发质量的做法，我持极大的怀疑态度。首先，整体式组件具有类似的组件管理问题-在其组成的各个库中，但是所有这些并不是那么引人注目，并且主要在开发人员花费的时间中体现出来。整体问题的后果是无法更改代码，并且开发速度非常慢。

微服务改善了这种情况，但随后微服务体系结构在集成阶段面临组合爆炸的问题。是的，总的来说，我们已经解决了相同的问题-从开发阶段到集成阶段。但是，在我看来，微服务方法仍然可以带来更好的结果，并且团队可以更快地获得结果（可能主要是由于开发单元的大小-或批处理大小的减少）。但是，从整体式服务向微服务的过渡尚未提供足够的流程改进-微服务版本的组合爆炸是一个巨大的问题，并且在解决该问题的过程中，我们具有很大的改进潜力。

More articles:


All Articles