产品版本控制微服务
我进入基于Docker的微服务架构，我有3个微服务，它们共同创build一个产品，例如“CRM系统”。
现在，我希望我的客户能够随时升级他的产品。 我有3个不同版本的微服务，哪一个客户应该看到？ 我猜产品版本应该独立于微服务，因为复制一个微服务版本会让我陷入比没有任何版本更麻烦的地步。
那么是否有任何模式，想法来处理这种情况？
我唯一想到的就是有一个存储库，只要其中的一个微服务可以生产现成的包，就会有一个版本库。 不过，我现在有一个版本，我的产品所有者（PO）都不会知道这个版本。
微服务版本控制
首先要确保语义版本（SemVer）严格遵循微服务。 不这样做迟早会导致不兼容问题。
只捕获该版本中的API更改，不要将其与微服务内部版本（例如，具有DB的服务的数据库模式版本）混合使用。
产品版本控制
按照您的build议介绍产品的版本。 在这之后，SemVer也是有意义的，但是可能需要放宽以满足营销需求（例如，即使SemVer只需要较小的版本增量，也允许进行大量的版本增量）。 在极端情况下，请使用专用的“技术版本”和“营销版本”。 然而，这对客户而言也更复杂。
另外请注意，您将需要定义SemVer版本在应用程序方面的含义，因为整个应用程序没有“API”。
依赖pipe理
现在特定的产品版本是特定版本的微服务列表。 请注意，这实质上是与apt ， npm ， bower等实现相同的依赖性pipe理。 您的解决scheme需要多么复杂很难说，但我build议至less支持“最低要求版本”的概念。 如果docker有一个内置的机制，试着使用那个（我不太了解docker，所以我不知道）。
有了这个，你就可以指定4.8.12版本的产品要求服务A的版本为1.12.0 ，服务B的版本为3.0.4 。
更新机制应遵循遵循SemVer的策略。 这意味着安装特定的产品版本会自动安装具有相同主要版本的最新服务。 在上面的例子中，这可以例如安装服务A的1.12.2和服务B的3.3.0 。提供保持已经安装的满足依赖性要求的服务的机制可能是一个好主意，使得用户不会感到恼火由更新机制。
文献为此使用5维模型：
- 版本（想改变）
- 状态（生命周期：创build，testing，部署，退役）
- 视图（来源，部署，文档）
- 层次结构（产品，微服务）
- 变体（很大程度上类似，描述了产品族的差异）
大多数系统只处理这些维度中的一些。 要处理所有五个，你必须描述（修复）你的开发过程。
当只考虑版本加层次结构时，就像在这里单独进行产品和微服务版本一样：只要产品的用户可以注意到不同的东西，产品版本就会改变。 您可能想要通过使用major-minor编号从microservice版本信号中发出信号：minor应该不会影响产品版本，major应该。 或者你可以使用版本范围/语义版本。
参考资料：
pipe理devise数据：CAD框架，configurationpipe理和产品数据pipe理的五个维度。 van den Hamer，P. Lepoeter，K. Philips Res。，Eindhoven;
本文出现在：Proceedings of the IEEE Publication Date：Jan 1996卷：84，期：1页：42-56 ISSN：0018-9219参考书目：26 CODEN：IEEPAD INSPEC保藏号：5175049数字对象标识符：10.1109 / 5.476025当前版本发布：2002-08-06