architecture - 微服务版本控制

Question

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


内部服务必须通过反向代理进行消费。
消费者始终必须了解所需的版本控制。


向用户公开版本信息是最佳实践吗？

在我看来，无论如何，以下条件始终适用：


对于主要版本更改，必须更改使用者。
对于MINOR版本更改（向后兼容），仅需要更改添加功能的使用者。
对于PATCH版本更改，它是可选的，任何消费者都可以无缝使用它。


哪种微服务版本控制策略可以帮助我们实现上述目标？

注意-如果需要将其分为多个问题，请随时告诉我。

Answer 1

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

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

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

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


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


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

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


URI的版本控制：“ http://host/serviceA/v3/whatever”
接受标题中的版本
自定义标题中的版本
版本作为参数


这个tutorial将比我更好地解释其中的每个缺点，但是基本上每个这些都应该做得很好=）

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

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