微服务版本控制

Question

在支持基于微服务的体系结构中进行版本控制的最佳实践是什么,在运行时支持同一服务的多个版本化部署以及消费者如何能够使用不同的版本？1)如果我们使用基于路由的版本控制作为这里提到的方法之一, 那么我想我们会有以下缺点

1. 内部服务必须通过反向代理才能使用.
2. 消费者必须始终了解所需的版本.

向消费者公开版本信息是最佳做法吗？

无论如何,我认为,以下内容始终适用:

1. 对于MAJOR版本更改,必须更改消费者.
2. 对于MINOR版本更改(向后兼容),只需要更改需要添加功能的消费者.
3. 对于PATCH版本更改,它是可选的,并且可能是任何消费者无缝使用它.

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

注意 - 如果需要分成多个问题,请随时告诉我.

Answer 1

我认为可以肯定地说，到目前为止，这还没有解决。在微服务架构中，每个服务应松散耦合。如果在更换生产者时也必须寻找消费者以对其进行更改，则表明您存在设计缺陷。链接中显示的基于路由的版本控制似乎不仅仅具有“一些缺点”。

您应该对整个服务还是仅对API进行版本控制？

如果您对整个服务进行版本控制，您将始终打开相当数量的蠕虫。假设您实现了服务A的第一个版本（v1）。现在想象一下，一段时间后，由于业务原因，必须实施一个新版本（v2）。如果在此服务的v2上发现错误，该怎么办？团队应检查v1上是否也没有相同的错误。如果是这样，则也应更正并重新部署v1。即使只是复制和粘贴，也需要重新测试和重新部署两个版本。如果版本之间的重构与修复v1的方式与修复v​​2的方式不同，该怎么办？如果不是5个或10个版本，而不是2个版本，该怎么办？比我更有趣的人应该为此设置一个“迅速缩放”的模因。

仅仅通过摸清该选项可能带来的头痛程度，我们基本上就可以通过仅对API进行版本化来决定。但基本上，如果您在代码级别上对服务进行版本控制：

1. 团队只需要支持该服务的一个版本（错误只需更正一次）
2. 由于不必了解大量不同且可能非常不同的服务版本，因此减少了团队的认知消耗
3. 减少资源消耗
4. 保证版本之间的所有内容都是一致的（如果不是保证，则至少更有可能）

客户端如何交流他们将使用的api版本？

对于此答案，我将仅提及REST api，因为我所知道的足够多。基本上有4种API版本（我可以想到）：

1. 对URI进行版本控制：“ http：// host / serviceA / v3 / whatever “
2. 接受标题中的版本
3. 自定义标题中的版本
4. 版本作为参数

本教程将比我更好地解释其中的每个缺点，但是基本上任何一个都应该做得很好=）

我该如何在同一个代码中维护众多的服务版本？（你疯了吗？？？）

您的服务本身仅仅是其中之一。您应该做的是应用适配器设计模式，以便存在与服务的业务层进行交互的前后版本。这样，您就可以拥有某些对象的某些版本，并且对服务的核心是透明的。这与问题中提到的文章的结论相同，甚至有一个很好的例子来展示它。

Answer 2

没有最佳实践。这将取决于版本控制在您的具体情况下应如何工作。

Shawn Wildermuth 在一个pluralsight 视频中讨论了api 版本控制。不确定你的微服务实现细节，但如果你使用rest api，你可以尝试对实际负载进行版本控制

您也可以使用 Accept 标头来执行此操作。Accept 允许您使用您想要查看的 API 的版本类型来注释 Accept 标头。您也可以使用内容类型来执行此操作。供应商的 application/vnd 指定返回数据的版本，以便应用程序发送它时，它知道它是什么版本的有效负载。这是版本控制中的一项重要技术，因为您必须对 API、实际 URI 调用以及返回的数据的形状进行版本控制。

如果您找到一种适合您的环境以及客户和用户的机制，请继续使用它。