spring - 进行微服务 REST API 版本控制的最佳方法是什么？

Question

我正在使用 Spring 开发这个项目并在 AWS EC2 实例中托管。由于很少有新需求出现，我不得不更改我的 API 契约(Contract)。但我不想破坏当前的客户。所以，我正在尝试使用版本控制来实现一些 REST API。这样无论何时我更新端点，消费者应用程序都不会崩溃。但我对如何进行 API 版本控制感到困惑。我想到了两种方法。

在同一台服务器中创建下一个版本的端点，(在 Spring 使用 RequestMaping("/v1/api1"),RequestMaping("/v2/api1") 类似的东西。)

其他明智的做法是在新服务器实例中完全运行 v2 API，但保持相同的 API 端点足迹并使用 AWS APIGateway 作为代理并在那里配置版本控制，然后根据请求中的版本号路由到旧服务器和新服务器。

但是我相信第一种方法会导致大量代码重复和代码管理困惑。因为我们保持相同的功能和变化。

在第二种方法中，如果我的版本增加，我必须为机器人版本保留两组实例，那么很难管理这些实例，特别是当我将有大约 15 个微服务实例时。而且它也不会具有成本效益。因为我的公司是一家初创公司，所以我也需要考虑这个事实。

是否有关于 API 版本控制和管理多个版本端点的最佳实践？我愿意接受任何建议和指导。如果多服务器也是解决方案，我愿意重新考虑成本限制。我需要这个问题的最佳解决方案。

Answer 1

第一个问题是为什么你需要一个新版本？
您的契约(Contract)是否发生了变化，或者内部逻辑是否发生了一些变化，以及您是否真的需要公开新版本。下一个要问的问题是您需要支持旧版本多长时间以及您打算拥有多少个版本。
对于成熟的 api，您可以使用方法 2，如果可能，占用空间较小。对于其他人，您会更好地通过相同的服务公开 v2 并解决它。
代码复制是一个因素，但取决于您所做的更改。如果一切都与契约(Contract)变更有关，您可以尝试使用相同的业务逻辑，并使其适用于新旧契约(Contract)。

以下是一些您可能会觉得有用的链接

https://www.mnot.net/blog/2012/12/04/api-evolution

Best practices for API versioning?