我进入了基于docker的微服务架构，我有3个微服务，它们共同创建了一个产品，例如“ CRM系统”。
现在，我希望我的客户能够随时升级他的产品。我的微服务有3个不同版本，客户应该看哪个？我猜产品版本应该独立于微服务，因为复制一个微服务版本会使我陷入麻烦，而不是根本没有版本。
那么，有什么模式，想法可以应对这种情况吗？
我唯一想到的就是拥有另一个存储库，只要其中一个微服务产生生产就绪的软件包，该存储库就会被版本化。但是，我现在有一个版本，我的产品所有者（PO）都不知道。
首先，确保微服务严格遵循语义版本控制（SemVer）。不这样做会迟早导致不兼容问题。
仅捕获该版本中的API更改，请勿将其与微服务内部版本控制（例如，具有数据库的服务的数据库架构版本控制）混合使用。
按照您的建议介绍该产品的版本。遵循SemVer在这里也很有意义，但是可能需要放宽以满足市场需求（例如，即使SemVer仅需要较小的版本增量，也可以进行主要版本的增量）。在极端情况下，请使用专用的“技术版本”和“营销版本”。然而，这对于客户来说也更加复杂。
还要注意，由于整个应用程序没有“ API”，因此您需要定义SemVer版本对您的应用程序的含义。
现在，特定的产品版本是特定版本的微服务的列表。请注意，这基本上是在同一意义上依赖管理apt，npm，bower，等实现。您的解决方案需要多么复杂很难说，但是我建议至少支持“最低要求版本”的概念。如果docker具有内置机制，请尝试使用该机制（我不太了解docker，所以我无法告诉）。
apt
npm
bower
有了这个，你是例如可以指定你的产品的版本为4.8.12需要服务A版本1.12.0和B业务的3.0.4。
4.8.12
1.12.0
3.0.4
然后，更新机制应遵循符合SemVer的策略。这意味着安装特定产品版本会自动安装 具有相同主要版本 的最新服务。在上面的示例中，这可以例如1.12.2是服务A和3.3.0服务B的安装。提供一种机制来保持满足依赖要求的已安装服务可能是一个好主意，以使用户不会因更新机制而烦恼。
1.12.2
3.3.0
