微服务版本控制 [英] Microservice Versioning
问题描述
在基于微服务的架构中适应版本控制的最佳实践是什么，在运行时支持同一服务的多个版本化部署以及消费者如何能够使用不同的版本?1)如果我们使用基于路由的版本控制作为此处提到的方法之一那么我想我们会有以下缺点
What is the best practice to adapt for versioning in a Microservice Based Architecture, in terms of supporting multiple versioned deployment of the same service during runtime and how the consumers would be able to use different versions? 1) If we use Routing based Versioning as one of the approaches mentioned here then I guess we would have the following drawbacks
- 内部服务必须通过反向代理才能使用.
- 消费者必须始终了解所需的版本控制.
向消费者公开版本信息是最佳做法吗?
Is it a best practice to expose the version information to consumers?
在任何情况下，我觉得以下始终适用:
In any case, as I feel, the following always applies:
- 对于主要版本更改，必须更改使用者.
- 对于 MINOR 版本更改(向后兼容)，只有需要添加功能的使用者需要更改.
- 对于 PATCH 版本更改，它是可选的，任何消费者都可能无缝地使用它.
什么样的微服务版本控制策略可以帮助我们实现上述目标?
What kind of Microservice versioning strategy can help us in enabling the above?
注意 - 如果这需要分成多个问题，请随时告诉我.
NOTE - Please feel free to let me know if this needs to be split in multiple questions.
推荐答案
我认为可以肯定地说，到目前为止，这还不是一个已解决的问题.在微服务架构中，每个服务都应该是松散耦合的.如果你换了一个生产者，你也必须追捕消费者来改变他们，那就说明你有设计缺陷.链接中提出的基于路由的版本控制似乎不仅仅是一些缺点".
I think it is safe to say that as of now it is not a solved problem. In a Microservice Architecture, each service should be loosely coupled. If when you change a producer, you have to hunt down consumers to change them too, then it indicates that you have a design flaw. The routing based versioning presented in the link seems to have much more than a "few drawbacks".
您应该对整个服务进行版本控制还是只对 API 进行版本控制?
如果您对整个服务进行版本控制，您将不可避免地打开一大堆蠕虫病毒.假设您实现了服务 A 的第一个版本 (v1).现在想象一下，一段时间后，由于业务原因，必须实现新版本 (v2).如果在此服务的 v2 上发现错误会怎样?团队应该检查 v1 上也不存在相同的错误.如果是，则也应更正并重新部署 v1.即使只是复制粘贴，两个版本都需要重新测试和重新部署.如果版本之间存在重构并且修复 v1 的方式与修复 v2 的方式不同呢?如果不是 2 个版本，而是 5 个或 10 个版本怎么办?比我更有趣的人应该为此制作一个迅速升级"的模因.
If you version the entire service, you will invariably open quite a can of worms. Imagine that you implemented the first version (v1) of a service A. Imagine now that after a while, a new version (v2) had to be implemented because of the business. What happens if a bug is discovered on the v2 of this service? The team should check that the same bug doesnt exist on v1 too. If it does, v1 should be corrected and redeployed too. Even if it is just copy and paste, both versions need to be retested and redeployed. And what if there was refactoring between versions and the way to fix v1 is diferent from the way to fix v2? And what if instead of 2 versions, there are 5 or 10? Someone funnier than me should make a "That scalated quickly" meme for this.
仅仅从表面上看这个选项会带来多少麻烦，我们基本上已经可以通过只对 api 进行版本控制来决定.但基本上，如果您在代码级别对服务进行版本控制:
Just by scratching the surface of how much headache this option could give, we basically can already decide by versioning just the api. But basically if you version your service on the code level:
- 团队只需要支持一个版本的服务(错误只需纠正一次)
- 减少团队的认知消耗，因为不必了解大量不同且可能非常不同的服务版本
- 更少的资源消耗
- 保证版本之间的一切都是一致的(如果不是保证，至少它更有可能)
客户端如何传达他们将使用的 API 版本?
对于这个答案，我将仅参考 REST api，因为我知道的足以谈论它.基本上有 4 种方式来控制 api(我能想到的):
For this answer, I will refer only to REST apis because its what i know enough to talk about. There are basically 4 ways of versioning the api (that i can think of):
- 对 URI 进行版本控制:"http://host/serviceA/v3/whatever"
- 接受标头中的版本
- 自定义标题中的版本
- 版本作为参数
这个教程将解释每一个缺点比我好，但基本上这些中的任何一个都应该做得很好 =)
This tutorial will explain each one of these with their drawbacks better than me, but basically anyone of these should do just fine =)
我如何(该死的)在同一个代码中维持无数的服务版本?(你疯了吗???)
您的服务本身只是其中之一.您应该做的是应用适配器设计模式，以便存在与您的服务的业务层交互的不同版本的输入和输出.这样你就只有一些对象的一些版本，它对服务的核心是透明的.这与问题中提到的文章的结论相同，甚至还有一个很好的例子来展示它.
Your service per se is just one. What you should do is apply Adapter Design pattern, so as to exist different versions of ins and outs interacting with the business layer of your service. This way you just have some versions of some objects, with it being transparent to the core of the service. It is the same conclusion of the article mentioned in the question, and it even has a neat example to showcase it.
这篇关于微服务版本控制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
