就在运行时支持同一服务的多个版本化部署以及消费者如何使用不同版本而言，在基于微服务的架构中适应版本控制的最佳实践是什么？ 1）如果我们使用基于路由的版本控制作为提到的方法之一here 那么我想我们会有以下缺点
向消费者公开版本信息是最佳做法吗？
在任何情况下，我认为以下始终适用：
什么样的微服务版本控制策略可以帮助我们实现上述目标？
注意 - 如果这需要分成多个问题，请随时告诉我。
【问题讨论】：
标签： architecture versioning soa microservices
我认为可以肯定地说，到目前为止，这还不是一个已解决的问题。在微服务架构中，每个服务都应该是松耦合的。如果你换了一个生产者，还得找消费者换，那说明你有设计缺陷。 链接中显示的基于路由的版本控制似乎不仅仅是“一些缺点”。
您应该对整个服务进行版本控制还是只对 api 进行版本控制？
如果您对整个服务进行版本控制，您总是会打开一大堆蠕虫。想象一下，您实现了服务 A 的第一个版本（v1）。现在想象一下，一段时间后，由于业务原因，必须实现一个新版本（v2）。如果在此服务的 v2 上发现错误会怎样？团队应该检查 v1 上是否也存在相同的错误。如果是这样，也应该更正并重新部署 v1。即使只是复制和粘贴，两个版本都需要重新测试和重新部署。如果版本之间存在重构并且修复 v1 的方式与修复 v2 的方式不同怎么办？如果不是 2 个版本，而是 5 个或 10 个版本怎么办？比我更有趣的人应该为此制作一个“迅速升级”的表情包。
仅仅了解这个选项可能会带来多少麻烦，我们基本上已经可以通过仅对 api 进行版本控制来决定。但基本上，如果您在代码级别对服务进行版本控制：
客户端如何传达他们将使用哪个版本的 api？
对于这个答案，我将仅参考 REST api，因为我知道足以谈论它。基本上有 4 种方式来对 api 进行版本控制（我能想到的）：
tutorial 将比我更好地解释其中的每一个及其缺点，但基本上这些中的任何一个都应该做得很好 =)
我如何（f*****g 地狱）在同一个代码中维持众多服务版本？ （你疯了吗？？？）
您的服务本身只是其中一项。您应该做的是应用适配器设计模式，以便存在与服务的业务层交互的不同版本的输入输出。这样你就只有一些对象的一些版本，它对服务的核心是透明的。与问题中提到的article 的结论相同，甚至还有一个简洁的例子来展示它。
【讨论】：
你可以混合搭配不同的策略
对于重大更改，您可以使用基于路由的版本控制
对于其他您可以使用基于适配器的版本控制
【讨论】：
在基于微服务的架构中适应版本控制的最佳实践是什么
我在微服务项目中使用的一种策略是通过路由进行版本控制。
我们使用 JSON RPC 2.0，因此它与 REST 略有不同，但可以应用。
我们只使用主要版本，并尝试同时使用旧版本和新版本，以便更新消费者的时间。
注意事项
避免在生产中使用超过两个版本的服务（如果您有一些模型更新，真的很难管理）。
想办法告诉消费者正在使用的版本已弃用。
我知道有些微服务架构没有版本控制，但这意味着你在消费者和生产者之间有很强的耦合，所以我可能不推荐这种方法。
回答第二个问题
消费者如何能够使用不同的版本？
这听起来不可能，因为消费者一次只能使用一个版本。
如果您希望它知道该版本可以在运行时使用它，您可以通过功能翻转和服务发现来完成。
如果路由 x 存在，您的消费者将定期询问服务发现。如果为 true，则使用该功能，否则继续使用当前版本。它可以工作，但管理起来有点棘手。
【讨论】：
没有最佳实践。这将取决于版本控制在您的特定情况下应该如何工作。
Shawn Wildermuth 在pluralsight video 中讨论了 API 版本控制。不确定您的微服务实现细节，但如果您使用的是 rest api，您可以尝试对实际有效负载进行版本控制
您也可以使用 Accept 标头来执行此操作。接受允许您 根据您的 API 使用版本类型注释 Accept 标头 想看看。您也可以对内容类型执行此操作。 供应商的 application/vnd 指定返回的版本 数据，以便当应用程序发送它时，它知道什么 它是有效载荷的版本。这是一项重要的技术 版本控制，因为您必须对 API 和实际 URI 进行版本控制 调用，以及返回的数据的形状。
如果您发现一种机制在您的环境中以及您的客户和用户中运行良好，请继续使用它。
【讨论】：