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