就在运行时支持同一服务的多个版本化部署以及消费者如何使用不同版本而言，适应基于微服务的架构中的版本控制的最佳实践是什么？
1）如果我们使用基于路由的版本控制作为提到的方法之一here http://niels.nu/blog/2016/microservice-versioning.html那么我想我们会有以下缺点
- 内部服务必须通过反向代理进行消费。
- 消费者始终必须了解所需的版本控制。
将版本信息公开给消费者是最佳实践吗？
无论如何，我认为以下几点始终适用：
- 对于主要版本更改，必须更改消费者。
- 对于次要版本更改（向后兼容），只有需要添加功能的消费者才需要更改。
- 对于补丁版本更改，它是可选的，并且任何消费者都可以无缝地使用它。
什么样的微服务版本控制策略可以帮助我们实现上述目标？
注意 - 如果需要将其拆分为多个问题，请随时告诉我。
我认为可以肯定地说，到目前为止这还不是一个已解决的问题。在微服务架构中，每个服务应该是松散耦合的。如果当你更换生产者时，你必须寻找消费者来改变他们，那么这表明你有设计缺陷。
链接中提供的基于路由的版本控制似乎不仅仅有“一些缺点”。
您应该对整个服务进行版本控制还是仅对 API 进行版本控制？
如果你对整个服务进行版本控制，你总是会遇到很多蠕虫。想象一下，您实现了服务 A 的第一个版本（v1）。现在想象一下，一段时间后，由于业务原因，必须实现新版本（v2）。如果在该服务的 v2 上发现错误会怎样？团队应该检查 v1 上是否也存在相同的错误。如果是这样，v1 也应该被更正并重新部署。即使只是复制粘贴，两个版本都需要重新测试和重新部署。如果版本之间存在重构并且修复 v1 的方式与修复 v2 的方式不同怎么办？如果不是 2 个版本，而是 5 个或 10 个版本怎么办？比我更有趣的人应该为此制作一个“迅速升级”的模因。
只需简单了解一下这个选项可能会带来多少麻烦，我们基本上就可以通过仅对 api 进行版本控制来做出决定。但基本上，如果您在代码级别对服务进行版本控制：
- 团队只需支持一个版本的服务（错误只需纠正一次）
- 团队无需理解大量不同且可能截然不同的服务版本，从而减少认知消耗
- 资源消耗少
- 保证版本之间的一切都是一致的（如果不能保证，至少更有可能）
客户端如何传达他们将使用哪个版本的 api？
对于这个答案，我将仅参考 REST api，因为这是我所知道的足够多的内容。基本上有 4 种对 api 进行版本控制的方法（我能想到的）：
- 对 URI 进行版本控制：“http://主机/serviceA/v3/随便 http://host/serviceA/v3/whatever"
- Accept 标头中的版本
- 自定义标头中的版本
- 版本作为参数
This tutorial http://www.springboottutorial.com/spring-boot-versioning-for-rest-services会比我更好地解释其中每一个及其缺点，但基本上任何一个都应该做得很好 =)
我如何（该死）在相同的代码中维持无数的服务版本？ （你疯了？？？）
您的服务本身只是其中之一。您应该做的是应用适配器设计模式，以便存在与服务的业务层交互的不同版本的细节。这样，您就只拥有某些对象的某些版本，并且它对服务核心是透明的。这也是同样的结论article http://niels.nu/blog/2016/microservice-versioning.html问题中提到，它甚至有一个很好的例子来展示它。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
