architecture - 产品版本控制微服务

Question

我进入基于 docker 的微服务架构，我有 3 个微服务，它们共同创建了一个产品，例如“CRM 系统”。

现在我希望我的客户能够随时升级他的产品。我有 3 个不同版本的微服务，客户应该看到哪一个？我想产品版本应该独立于微服务，因为复制其中一个微服务版本会让我陷入比没有版本更多的麻烦。

那么有什么模式，想法来处理这种情况吗？

我想到的唯一一件事是拥有另一个存储库，只要其中一个微服务生成生产就绪包，就会对其进行版本控制。但是，我现在有一个版本，我的产品负责人 (PO) 都不知道。

Answer 1

微服务版本控制

首先确保Semantic Versioning (SemVer)微服务严格遵循。不这样做迟早会导致不兼容问题。

仅捕获该版本中的 API 更改，不要将其与微服务内部版本控制混为一谈(例如，具有数据库的服务的数据库架构版本控制)。

产品版本控制

按照您的建议介绍产品的版本。遵循 SemVer 在这里也很有意义，但可能需要放松以满足营销需求(例如，允许进行主要版本增量，即使 SemVer 只需要次要版本增量)。在极端情况下，使用专用的“技术版本”和“营销版本”。然而，这对客户来说也更加复杂。

另请注意，您需要根据应用程序定义 SemVer 版本的含义，因为整个应用程序没有“API”。

依赖管理

现在特定的产品版本是特定版本的微服务列表。请注意，这本质上是与 apt、npm、bower 等实现相同的依赖管理。很难说您的解决方案需要多么复杂，但我建议至少支持“最低要求版本”的概念。如果 docker 有内置机制，尝试使用那个(我对 docker 不是很了解，所以说不出来)。

有了这个，你就是例如能够指定版本 4.8.12 的产品需要版本 1.12.0 的服务 A 和 3.0.4 的服务 B。

更新机制应该遵循遵循 SemVer 的策略。这意味着安装特定产品版本会自动安装具有相同主要版本的最新服务。在上面的示例中，这可以例如安装服务 A 的 1.12.2 和服务 B 的 3.3.0。提供一种机制来保持满足依赖要求的已安装服务可能是一个好主意，这样用户不会对更新机制感到恼火。