产品版本化微服务

Question

产品版本化微服务

architecturedockerdomain-driven-designsoamicroservices

28

我正在使用基于Docker的微服务架构，我有3个微服务，它们共同创建了一个产品，例如“CRM系统”。

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

那么有没有模式或想法来处理这种情况呢？

我脑海中唯一想到的是拥有另一个存储库，每当一个微服务生成生产就绪的软件包时，该存储库将被版本化。然而，现在我有一个版本，我的任何产品负责人（PO）都不会知道。

- Dariss

“随时升级产品”是什么意思？您是指桌面应用程序或移动应用程序之类的东西，其中您不需要更新，这会导致添加其他功能或演变API消息模式方面出现问题吗？ - Will C

1

是的，我在谈论桌面应用程序，它具有“升级系统模块”。它允许管理员（客户端）通过单击一个按钮来升级他的系统。应用程序会暂时关闭，后台任务会执行其工作，以满足请求。 - Dariss

2个回答

6

文献使用了一个五维模型来描述：

版本（想要改变的）
状态（生命周期：创建、测试、部署、退役）
视图（源代码、部署、文档）
层次结构（产品、微服务）
变体（大致相似，描述差异，产品族）

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

当只考虑版本和层次结构时，就像您在此处单独对产品和微服务进行版本控制一样：产品版本应该在产品用户可以注意到有所不同的时候立即更改。您可能希望通过使用主要-次要编号从微服务版本控制中发出信号来表示这一点：次要版本不应影响产品版本，而主要版本应该。或者您可以使用版本范围/语义化版本控制。

参考文献：

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

本文发表于：IEEE会议论文集出版日期：1996年1月卷：84，期：1 页码：42-56 ISSN：0018-9219 引用参考文献：26 CODEN：IEEPAD INSPEC访问号：5175049 数字对象标识符：10.1109/5.476025 当前版本发布日期：2002年8月6日

- Stephan Eggermont

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- theDmi · Accepted Answer

微服务版本控制

首先要确保严格遵循语义化版本控制（SemVer）。不这样做最终会导致不兼容的问题。

只在该版本中捕获 API 更改，不要将其与微服务内部版本控制混合（例如，对于具有 DB 的服务的 DB 模式版本控制）。

产品版本控制

像您已经建议的那样，为产品引入版本控制。在这里遵循 SemVer 同样是有意义的，但可能需要放松以满足营销需求（例如，即使 SemVer 只需要一个次要版本增量，也允许进行主要版本增量）。在极端情况下，使用专门的“技术版本”和“营销版本”。然而，这也会让客户更复杂。

还要注意，您需要定义 SemVer 版本在应用程序方面的含义，因为整个应用程序没有“API”。

依赖管理

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

通过这种方式，例如，您可以指定您的产品在版本4.8.12中需要服务 A 版本1.12.0和服务 B 版本3.0.4。

更新机制应该遵循SemVer标准。这意味着安装特定的产品版本会自动安装带有相同主要版本号的最新服务。在上面的示例中，可能安装服务A的1.12.2和服务B的3.3.0。提供一种机制来保留已安装的满足依赖要求的服务可能是个好主意，这样用户就不会被更新机制所困扰。