Question

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

微服务架构的一个原则是永远不会提供突破性的变更集。另一方面，语义版本控制表明，当传递非向后兼容（读取＆＃34;破坏＆＃34;）变更集时，应该增加主版本号。这些是如何兼容的？

在我看来，对于微服务架构来说，语义版本控制可能过度。如果所有公共API都是版本化的（例如/ api / v3 / getSomething）那么我真的需要完整的语义版本控制吗？我正在考虑一种方案，我使用一个数字来识别当前可用的API版本（v1，v2，v3等）以及用于标识生成的持续集成管道的内部版本号（或可能是日期/时间戳）构建。请注意，v3仍然支持v2 API调用，直到使用该服务的每个人都转移到使用v3，因此v3是＆＃34;目标版本＆＃34;从某种意义上说。所以我的微服务foo看起来像＆＃34; foo-v3-20160503142209.jar＆＃34;

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

Answer 1

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

Answer 2

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

需要考虑的事项：

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

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

Z 用于小修复和改进

标签路由的

X，Y

新功能

Y

如果更改破坏了服务之间的协议

，则会修改

X

发布：＆＃34; 2.0.x＆＃34;，版本：＆＃34; 2.0.0＆＃34;，

文件夹结构

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

Answer 3

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

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

我们使用StdLib，因此版本控制更容易。我建议看看他们的东西，看看他们如何处理版本控制。

但实质上，让我们说我们的文章服务处理图像上传，我们已经使用0.0.2格式的图像服务锁定。

它看起来像这样：

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

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

这样，我们就不必担心服务的变化了。

虽然我认为如果lib能够从npm中的package.json文件中读取这些依赖关系，那将会非常酷。但是人们可以做梦。

微服务＆amp;版本

3 个答案: