微服务和版本控制如何处理部署答案

【问题标题】：Micro Services and Version Control how to handle deployment微服务和版本控制如何处理部署
【发布时间】：2019-08-09 12:15:37
【问题描述】：

我目前正在尝试弄清楚如何使用微服务处理版本控制。

根据我的阅读，最好的策略是为每个微服务拥有一个单独的 git 存储库。

然而，在部署时必须上传多个 git 存储库似乎相当复杂。

具体来说，我正在摸索如何部署更新，其中多个微服务需要相互依赖的更改，以及如果生产部署出现问题，如何回滚到以前的版本。

这似乎是大多数使用微服务的开发者不得不面对的一个难题。

任何建议都将不胜感激，尤其是如果这可以使用现有库而不是从头开始构建，

谢谢，西蒙

【问题讨论】：

【解决方案1】：

没有简单的答案或库可以解决问题，但是有一些策略可以提供帮助。我在下面概述了一些

服务的向后兼容性 - 每当您发布时，请确保您的 API（REST 或其他）与以前的使用者一起使用，这可以通过证明较新属性的默认值来完成。

API 版本控制 - 当您所做的更改不小且具有破坏性时，请引入新版本的 API，以便老用户可以继续使用以前的版本。

Canary 部署 - 当您部署新版本的微服务时，只会将一小部分调用路由到新服务和旧版本的其余部分。观察行为并在需要时回滚。

蓝绿色部署 - 有两个生产环境，一个蓝色被证明可以工作，另一个绿色正在暂存包含最新版本。当测试完成绿色环境并且您有足够的信心时，将所有调用路由到绿色。

参考文献

【讨论】：

感谢您的回复，我查看了您提到的 3 个解决方案，这似乎有助于在此过程中改进我的问题。虽然我肯定会创建一个类似于上面建议的部署策略，但我更关心的是部署的管理而不是部署本身。例如，如果我有 30 个微服务，而我所做的更改需要许多其他服务来更改，那么是否有管理这些依赖项的好方法？
从我目前所阅读的内容来看，我发现的唯一解决方案是在服务之间的调用期间传递版本号，并且始终提供以前的版本。虽然这足以满足我的需求，但我不是这种方法的忠实拥护者，我更喜欢自动处理依赖关系而不是在运行时处理的东西。