产品版本控制微服务 [英] Product Versioning Microservices

问题描述

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

I go into microservices architecture based on docker and I have 3 microservices, which together create one product for example "CRM system".

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

Now I want my client to be able to upgrade his product, whenever he wants to. I have 3 different versions of my microservices, which one should client see? I guess product version should be independent of microservices, because copying one of the microservices version would make me go into more trouble than having no version at all.

那么有没有处理这种情况的模式、想法?

So is there any pattern, idea to handle such situation?

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

The only thing that comes to my mind is to have another repository which will be versioned whenever one of the microservices will produce production ready package. However, I now have a version, which none of my Product Owners (PO) would ever know about.

推荐答案

微服务版本控制

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

Micro Service Versioning

First of all ensure Semantic Versioning (SemVer) is strictly followed by the micro services. Not doing this will sooner or later lead to incompatibility problems.

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

Capture only API changes in that version, don't mix it up with micro service internal versioning (e.g. DB schema versioning for a service that has a DB).

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

Introduce a version for the product as you already suggested. Following SemVer makes sense here, too, but may need to be loosened to meet marketing needs (e.g. allow to make a major version increment even though SemVer would require only a minor version increment). In extreme cases, use dedicated "technical versions" and "marketing versions". This is however more complicated for the customers, too.

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

Also note that you will need to define what the SemVer version means in terms of your application, since the application as a whole has no "API".

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

Now a specific product version is a list of micro services of specific versions. Note that this is essentially dependency management in the same sense as apt, npm, bower, etc implement. How sophisticated your solution needs to be is difficult to say, but I recommend to at least support the notion of "minimum required versions". If docker has a built-in mechanism, try to use that one (I don't know docker very well, so I can't tell).

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

With this, you are e.g. able to specify that your product at version 4.8.12 requires service A at version 1.12.0 and service B at 3.0.4.

然后更新机制应遵循符合 SemVer 的策略.这意味着安装特定产品版本会自动安装具有相同主要版本的最新服务.在上面的例子中，这可以例如安装服务 A 的 1.12.2 和服务 B 的 3.3.0.用户不会因为更新机制而烦恼.

The update mechanism should then follow a strategy that adheres to SemVer. This means that installing a specific product version automatically installs the newest services with the same major version. In the example above, this could e.g. install 1.12.2 of service A and 3.3.0 of service B. Providing a mechanism to keep already installed services that meet the dependency requirement may be a good idea, so that users don't get annoyed by the update mechanism.

这篇关于产品版本控制微服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！