同时部署多个微服务的最佳实践有哪些？

Question

如果发生影响多个服务的更改，我一直在努力寻找同时部署多个微服务的最佳方法。

虽然我对任何通用方法都感兴趣，但让我提供一个我遇到的具体示例。

我们公司使用AWS和Elastic Beanstalk为一个网站部署微服务容器，相对解耦。现在我们的网络应用程序包括：

• 用 Angular 编写的 SPA，部署并托管在 S3 存储桶中（称为 SPA）

• 一个 webapi 服务，用 .NET Core 编写，经过 Docker 化，并部署到弹性 beanstalk 应用程序（称为 WebAPI）

• 一个集成服务，用 Node.JS 编写，经过 Docker 化，并部署到弹性 beanstalk 应用程序（称为 IntService）

SPA 和 WebAPI 通过 REST API 进行对话

WebAPI 和 IntService 是松散耦合的，并通过 AWS SQS 队列相互通信。

如果我们对其中任何一项服务进行更改，我们的部署过程都相当简单。例如，如果我们对 WebAPI 进行了更改，我们会启动一个新的 Elastic beanstalk 应用程序环境，部署在那里，然后交换 URL（基本的蓝绿部署）。

但是，如果发生影响多个服务的更改，我将很难找到正确的方法。例如，假设有一项功能需要同时更改 WebAPI 和 IntService。由于它们都位于自己的存储库中，因此它们都有自己的 CI 和 CD 管道，彼此独立。

如果只部署一项服务，整个应用程序可能会崩溃。人们如何处理这种类型的部署？您是否克隆 WebAPI 和 IntService 环境，部署这两个环境，然后交换两个 URL，只是确保几乎同时执行此操作，以最大限度地缩短只有一项服务处于活动状态的时间窗口？

或者，我们正在考虑使用 API 网关。但这是否意味着每次我们想要部署时，我们都会创建一个新的 API 网关阶段？如果我们这样做，蓝绿部署“交换”实际上是否发生在 API 网关中？

抱歉，如果这令人困惑，但我只是想了解一下我所想象的微服务的一个相当常见的问题。

Answer 1

这就是我所说的在汽车行驶时更换车轮。

微服务的全部意义在于使它们解耦，以便您可以自行发布任何给定的部分。

因此，您必须进行增量更改，并且彼此向后兼容。

这与更改数据库的方式类似。假设您要删除布尔列并将其替换为 enum。您不能通过立即更改数据库和所有代码来做到这一点，因为这不仅会带来部署问题，而且如果出现问题而您必须回滚怎么办？相反，您最好首先添加新列，然后更改一些代码以开始写入两个列，然后更改所有使用者，最后删除旧列。每一个都是单独的、独立的、向后兼容的变化。

简而言之，我怀疑是否有某种神奇的部署方法可以用来同时部署多个具有依赖关系的独立系统（至少不能在不接受停机时间的情况下）。

解决方案是将更改构建为小的向后兼容更改，直到完成并最终可以清理/删除旧代码。

顺便说一句，这就是系统积累技术债务的原因。随着时间的推移和系统复杂性的增加，重大升级可能很难像这样分解和实施，因此您被迫做出妥协，需要时间来清理。

无论如何，也许其他人可以描述一些黑魔法，但正如我所说，这不是部署问题，而是架构问题。

希望有帮助