产品版本微服务

Question

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

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

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

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

Answer 1

微服务版本控制

首先,确保微服务严格遵循语义版本控制(SemVer).不这样做迟早会导致不兼容问题.

仅捕获该版本中的API更改,不要将其与微服务内部版本控制混合(例如,对于具有DB的服务的DB模式版本控制).

产品版本控制

按照您的建议介绍该产品的版本.以下SemVer在这里也有意义,但可能需要放松以满足市场需求(例如,即使SemVer仅需要较小的版本增量,也允许进行主要版本增量).在极端情况下,使用专用的"技术版本"和"营销版本".然而,这对于客户来说也更复杂.

另请注意,您需要定义SemVer版本在应用程序方面的含义,因为整个应用程序没有"API".

依赖管理

现在,特定产品版本是特定版本的微服务列表.请注意,这本质上是相同的意义上依赖管理apt,npm,bower,等实现.您的解决方案需要多么复杂很难说,但我建议至少支持"最低要求版本"的概念.如果docker有一个内置机制,尝试使用那个(我不太熟悉docker,所以我无法分辨).

有了这个,您就可以指定您的产品版本4.8.12需要服务A版本1.12.0和服务B at 3.0.4.

然后,更新机制应遵循遵循SemVer的策略.这意味着安装特定产品版本会自动安装具有相同主要版本的最新服务.在上面的示例中,这可以例如安装1.12.2服务A和3.3.0服务B.提供保持已经安装的服务以满足依赖性要求的机制可能是个好主意,因此用户不会被更新机制烦恼.

Answer 2

文献为此使用了一个 5 维模型：

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

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

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

参考资料：

管理设计数据：CAD框架、配置管理、产品数据管理五个维度。van den Hamer、P. Lepoeter、K. Philips Res.、埃因霍温；

本文发表于：Proceedings of the IEEE Publication Date: Jan 1996 Volume: 84, Issue: 1 On page(s): 42-56 ISSN: 0018-9219 References Cited: 26 CODEN: IEEPAD INSPEC Accession Number: 5175049 Digital Object Identifier : 10.1109/5.476025 当前版本 发布时间: 2002-08-06