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