如果存在影响多个服务的更改，我一直在努力同时部署多个微服务的最佳方法 .
虽然我对任何一般方法感兴趣，但让我提供一个我正在遇到的具体例子 .
我们公司使用AWS和Elastic Beanstalk为相对分离的网站部署微服务容器 . 现在我们的Web应用程序包括：
-
以Angular编写的SPA，在S3存储桶中部署和托管（称之为SPA）
-
一个webapi服务，用.NET Core编写，dockerized并部署到弹性beanstalk应用程序（Call it WebAPI）
-
一个集成服务，用Node.JS编写，dockerized并部署到弹性beanstalk应用程序（称之为IntService）
SPA和WebAPI通过REST API进行通信
WebAPI和IntService松散耦合，并通过AWS SQS队列相互通信 .
如果我们对这些服务中的任何一个进行了更改，我们的部署过程相当简单 . 例如，如果我们对WebAPI进行了更改，我们就会启动一个新的弹性beanstalk应用程序环境，在那里进行部署，然后交换URL（这样基本的蓝绿色部署） .
但是，如果存在影响多个服务的更改，我正在努力采用正确的方法 . 例如，假设有一项功能需要更改WebAPI和IntService . 由于每个都在他们自己的回购中，他们每个都有自己的CI和CD管道彼此独立 .
如果只部署了一个服务，整个应用程序可能会中断 . 人们如何处理这种类型的部署？您是否克隆WebAPI和IntService环境，部署它们，然后交换两个URL，只是确保您几乎同时执行它以最小化只有一个服务处于活动状态的时间窗口？
或者，我们正在考虑使用API网关 . 但这是否意味着我们每次要部署时都会创建一个新的API网关阶段？如果我们这样做，蓝色部署“交换”实际上是否在API网关中发生？
很抱歉，如果这令人困惑，但我只是想绕过我想象的微服务相当普遍的问题 .
1 回答
这就是我所说的在汽车行驶时更换车轮 .
微服务的重点是使它们分离，这样你就可以自己发布任何给定的部分 .
因此，您必须进行向后兼容的增量更改 .
这与您更改数据库的方式类似 . 假设您要删除布尔列并将其替换为en enum . 你这样做不是通过一次更改数据库和所有代码，因为这不仅会导致部署问题，而且如果出现问题并且你必须回滚会怎样？相反，您最好先添加新列，然后更改一些代码以开始写入两列，然后更改所有使用者，最后删除旧列 . 每个都是独立的，独立的，向后兼容的变化 .
简而言之，我怀疑有一些神奇的部署方法可以用来同时部署多个具有依赖关系的独立系统（至少不能不接受停机时间） .
解决方案是构建变更，以便在完成小向后兼容的更改时进行细分，直到完成并最终清理/删除旧代码 .
这个BTW，是系统积累技术债务的原因 . 随着时间的推移和系统的复杂性增加，主要升级可能难以分解和实施，因此您不得不做出妥协，需要时间进行清理 .
无论如何，也许其他人可以描述一些黑魔法，但正如我所说，这不是一个部署问题，而是一个架构问题 .
希望有所帮助