如何在基于微服务的应用程序的生产中部署多个版本的应用程序

Question

是否可以同时在生产中部署多个版本的服务。从我的假设来看，对于基于微服务/ api的项目或移动项目来说，这应该是非常常见的模式。我想知道你是如何做到的，以及这类问题在行业中的常见模式。如果您的答案围绕AWS环境或Kubernetes环境，将会有所帮助。
提前致谢。

Answer 1

  

是否可以同时在生产中部署多个服务版本

是的，有可能。我们的想法是同时保留所有使用过的微服务（v1，v2 ......）并降低不再使用的版本。为此，应以某种方式知道何时不再使用某个版本。

AFAIK，您必须选择：

1. 对于每个新版本，您创建一个新端点（如/ v2 / someApiCall），该端点连接到相同（现已升级）的微服务，并逐渐指示客户端使用新的端点;当旧的端点不再使用时，你将其删除;这是首选方式。

2. 对于每个新版本，您都会创建一个与旧微服务具有相同持久性的新微服务;你应该避免使用这个解决方案;当改变旧消费者的成本太高时，Netflix在罕见的场合使用此策略。

您可以在{62}从Building microservices by Sam Newman了解更多信息。

Answer 2

假设您通过HTTP REST API公开服务，通常的标准是始终将您的服务URL与版本作为基线。

例如，

/v1/account/getUserInfo

如果您需要发布新版本，请将其公开：

/v2/account/getUserInfo

v2可以在代码库的不同分支上运行。

Answer 3

使用AWS API Gateway，您可以部署多个版本的代码，并在映射模板之间切换，如here所述。您可能还想查看stage variables。

Answer 4

我在博客中写道：Multi-version Service Discovery using Spring Cloud Netflix Eureka and Ribbon，专注于Spring Cloud Netflix组件/库。

但我们的想法是在新的主机/ VPS / Container中部署新版本的工件/二进制文件，并将服务注册表与注册服务器（Eureka，Consul，....）一起提供，并包含有关API的元数据它支持的版本（v1，v2，...）。客户端应用程序会发现哪个主机/容器/ ...提供所需的API版本。