微服务和版本控制答案

【问题标题】：Microservices & Versioning微服务和版本控制
【发布时间】：2023-03-16 14:57:01
【问题描述】：

我正在使用微服务构建一个云原生应用程序。最终，我已经到了必须为我的微服务实施正确版本控制的地步。在我看过的大多数地方，现在每个人都在谈论语义版本控制（一般来说，不仅仅是微服务）。

微服务架构的一个原则是永远不要交付破坏性变更集。另一方面，语义版本控制表示，当交付非向后兼容（读作“破坏”）变更集时，应该增加主版本号。这些如何兼容？

在我看来，语义版本控制可能对于微服务架构来说太过分了。如果所有公共 API 都进行了版本控制（例如 /api/v3/getSomething），那么我真的需要完整的语义版本控制吗？我正在考虑一个方案，我使用单个数字来标识当前可用的 API 版本（v1、v2、v3 等）以及标识生成构建的持续集成管道的构建号（或者可能是日期/时间戳） .请注意，在使用该服务的每个人都开始使用 v3 之前，v3 仍将支持 v2 API 调用，因此从某种意义上说，v3 是“目标版本”。所以我的微服务 foo 看起来像“foo-v3-20160503142209.jar”

这有什么明显的缺陷吗？在我看来，如果我强制从不交付破坏性变更集（如果它发生变化，它是一个新的 API 版本），客户端将保证 API 是兼容的。客户可以通过使用最新的内部版本号/时间戳来确定所有最新的错误修复。

【问题讨论】：

标签： cloud versioning microservices semantic-versioning continuous-delivery

【解决方案1】：

我们肯定会在我们的微服务基础架构中使用语义版本控制。我强烈推荐它。

我们必须做的一件事是将某些关键服务的使用锁定到他们使用的其他服务的版本。

我们使用StdLib，所以版本控制是比较容易的部分。我建议看看他们的资料，看看他们如何处理版本控制。

但本质上，假设我们处理图片上传的 Article 服务，我们已使用 0.0.2 的 formatImage 服务锁定。

看起来像这样：

const lib = require('lib')({
  // AWS_CREDENTIALS...
});

lib.utils.formatImage['0.0.2']({ key: 'image-key', resize: [200, 300] }, ...)

这样，我们就不必担心服务会发生变化。

虽然我确实认为如果 lib 能够从文件中读取这些依赖项或类似 package.json 在 npm 中的东西，那将是非常酷的。但是可以做梦。

【讨论】：

【解决方案2】：

还努力找出最佳的版本控制方案

需要考虑的事项：

 1. CI
 2. Git Branching model
 3. Compatibility
 4. Routing

到目前为止，我使用修改后的 SemVer X.Y.Z

Z 进行小的修复和改进

X,Y 用于标签路由

Y 表示新功能

X 如果更改破坏了服务之间的协议，则修改

发布：“2.0.x”，版本：“2.0.0”，

文件夹结构

[Service name] -> [Release] -> [Service]

【讨论】：

【解决方案3】：

在与客户的日常对话中，很难使用带有时间戳或 git commit hash 的版本。因此，您可以将语义版本（v1.2.3 中的 v1）的主要部分视为 API 版本。您可以创建二进制 foo-v1.2.3.jar，它在 foo/api/v1/ 处公开 API。要引入新版本的 API，您应该相应地更改二进制文件的版本。例如，对于 API 版本 2，您将创建名为 foo-v2.0.1.jar 的二进制文件。

【讨论】：