产品版本控制微服务答案

【问题标题】：Product Versioning Microservices产品版本控制微服务
【发布时间】：2016-01-17 01:41:18
【问题描述】：

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

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

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

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

【问题讨论】：

upgrading the product whenever he wants to 是什么意思？您指的是桌面应用程序或移动应用程序之类的东西，您不需要它们进行更新，从而导致在添加附加功能或发展 API 消息模式方面出现问题？
是的，我说的是桌面应用程序，它有upgrade system module。它确实允许管理员（客户）一键升级他的系统。应用程序停机一段时间，后台任务完成它的工作，以满足请求。

标签： architecture docker domain-driven-design soa microservices

【解决方案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。提供一种机制来保留满足依赖要求的已安装服务可能是一个好主意，这样用户就不会被更新机制所困扰。

【讨论】：

我认为 OP 的问题中遗漏了一点。他在问“如果我有 3 个微服务，每个都有自己的版本，例如 v1.0.0 v1.2.1 v1.3.0 当我从 v1.0.0->v1.1.0 开始时如何描述产品版本？是否应该有一个独立的具有这 3 个微服务的整体产品的版本？是否也应该使用 SemVer？"

【解决方案2】：

文学为此使用了 5 维模型：

版本（想要更改）
状态（生命周期：创建、测试、部署、停用）
查看（源代码、部署、文档）
层次结构（产品、微服务）
变体（大体相似，描述差异，产品系列）

大多数系统只处理其中的几个维度。要处理所有这五个问题，您必须描述（修复）您的开发过程。

当仅查看版本和层次结构时，就像您在此处分别对产品和微服务版本所做的那样：产品版本应在产品用户注意到不同之处时立即更改。您可能希望通过使用主要-次要编号从微服务版本控制中发出信号：次要不应该影响产品版本，主要应该。或者您可以使用版本范围/语义版本控制。

参考资料：

管理设计数据：CAD 框架、配置管理和产品数据管理五个维度。 van den Hamer, P. Lepoeter, K. 飞利浦水库，埃因霍温；

本文发表于：IEEE 会议记录出版日期：1996 年 1 月卷数：84，期数：1 在页面上：42-56 ISSN: 0018-9219 引用的参考文献：26 代号：IEEPAD INSPEC 登录号：5175049 数字对象标识符：10.1109/5.476025 当前版本发布时间：2002-08-06

【讨论】：