微服务版本控制

Question

在基于微服务的体系结构中适应版本控制的最佳实践是什么？在运行时支持同一服务的多个版本部署以及消费者如何使用不同版本？ 1）如果我们使用基于路由版本的方法之一提到here 话，我想我们将有以下缺点

1. 内部服务不得不通过反向代理消费。
2. 消费者总是必须知道所需的版本。

向客户公开版本信息是否是最佳做法？

在任何情况下，因为我觉得，以下始终适用：

1. 重大版本变化，消费者必须改变。
2. 对于MINOR版本更改（向后兼容），只有需要添加功能的使用者需要更改。
3. 对于PATCH版本更改，它是可选的，可能无缝供任何消费者使用。

什么样的微服务版本策略可以帮助我们实现上述目标？

注 - 请随时让我知道这是否需要分成多个问题。

Answer 1

没有最佳实践。这将取决于如何在特定情况下使用版本控制。

Shawn Wildermuth在pluralsight video中讨论了有关api版本控制的内容。不确定你的微服务实现细节，但如果你使用rest api，你可以尝试实际有效负载的版本号

你也可以用Accept头来做到这一点。接受允许您通过 注释接受标头的版本类型与您想要查看的API相对应。你也可以用内容类型来做到这一点。 供应商的应用程序/ vnd指定返回的 数据的版本，以便当应用程序发送它时，它知道它是什么样的有效载荷版本。这是 版本控制中的一项重要技术，因为您必须对API，实际URI调用以及返回数据的形状进行版本管理。

如果您发现一种适用于您的环境以及您的客户和用户的良好机制，请继续使用。

Answer 2

什么是对版本的微服务基础的架构

一个startegy，我在我的微服务项目中使用是版本通过路由适应的最佳实践。

我们使用JSON RPC 2。0，所以它与REST有点不同，但它可以应用。

我们只使用主要的版本控制，并尝试同时使用旧版和新版，以便让消费者更新时间。

事情要具有生产服务的超过两个的版本

• 避免护理（真的很难管理，如果你有一些模型更新）。

• 找到告诉消费者使用的版本已过时的方法。

我知道有些微服务架构生活没有版本控制，但它意味着你有消费者和生产者之间的强耦合，所以我可以不推荐这种方法。

要回答第二个问题

消费者如何能够使用不同的版本？

这听起来不可能，因为消费者一次只能使用一个版本。

如果您想知道该版本可以在运行时使用它，您可以通过功能翻转以及服务发现进行浏览。

如果路由x存在，您的消费者会定期询问服务发现。如果为true，则使用该功能，否则继续使用当前版本。它可以工作，但管理起来有点棘手。

Answer 3

你可以混合不同stretagies

进行大的变动，你可以使用基于路由版本

对于其他可以使用适配器基于版本

的比赛