「第二部:容器和微服务架构](13) API和契约的创建发展和版本控制

2023-05-25 55

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 「第二部:容器和微服务架构](13) API和契约的创建发展和版本控制

微服务API是服务与其客户端之间的契约。只有在不破坏微服务的API契约的情况下，您才能独立地开发微服务，这就是契约如此重要的原因。如果您更改合同，它将影响您的客户端应用程序或您的API网关。

API定义的性质取决于您使用的协议。例如，如果您使用消息传递（如AMQP），则API由消息类型组成。如果您使用的是HTTP和RESTful服务，那么API由URL、请求和响应JSON格式组成。

然而，即使您对最初的合同考虑周到，也需要随着时间的推移更改服务API。当这种情况发生时，尤其是当您的API是由多个客户端应用程序使用的公共API时，您通常不能强制所有客户端升级到新的API契约。通常需要以服务契约的旧版本和新版本同时运行的方式增量部署服务的新版本。因此，有一个服务版本控制策略是很重要的。

当API更改很小时，比如向API添加属性或参数，使用旧API的客户机应该切换并使用新版本的服务。您可能能够为所需的任何缺少的属性提供默认值，并且客户端可能能够忽略任何额外的响应属性。

但是，有时需要对服务API进行重大且不兼容的更改。由于您可能无法强制客户端应用程序或服务立即升级到新版本，因此服务必须在一段时间内支持旧版本的API。如果使用基于HTTP的机制（如REST），一种方法是将API版本号嵌入URL或HTTP头中。然后，您可以决定是在同一个服务实例中同时实现两个版本的服务，还是部署每个实例处理一个版本的API。一个很好的方法是中介模式（例如，MediatR库）将不同的实现版本分离成独立的处理程序。

最后，如果您使用的是REST架构，那么超媒体是对服务进行版本控制并允许可演化API的最佳解决方案。

后面会有专门的章节介绍API的版本控制和API的金丝雀部署，消息的版本控制和怎么保证不同版本的消息的兼容。