为什么要聚合Swagger接口文档

在微服务架构的项目开发中，可能每个独立的微服务实例都有其独立的 Swagger 接口调试页面。比如，本书的微服务架构项目，有用户微服务、商品微服务、订单微服务等，这些微服务的工程源代码中都各自配置了 Swagger 接口文档工具的相关属性，实例启动后都能够通过访问特定的网址链接查看和调试相应的接口，各微服务实例的 Swagger 接口文档网址如表 9-1 所示。

当前项目只有 5 个微服务实例，如果有更多的微服务实例，那么对真实开发场景中前后端开发人员联调接口会造成一些小困扰，毕竟在联调接口时不可能在浏览器中打开多个链接查看不同的 Swagger UI 页面。在微服务实例多的情况下，如果不聚合 Swagger 接口文档，那么访问每个服务的 API 文档都需要单独访问一个 Swagger UI 页面，很不方便。另外，一旦服务实例的 IP 地址或端口更换，就要重新沟通和修改，也比较麻烦。

在微服务架构项目中基本上都会整合网关服务，所有的请求都要经过网关层。既然请求有统一的入口，如果在网关层统一聚合这些 Swagger 接口文档，在网关层进行接口的查看和联调，就会更方便也更符合真实开发场景，毕竟在部署的时候不会对外暴露内部微服务实例工程的 IP 地址和端口。

当然，这个步骤并不是必需的，只是聚合接口文档会更方便、更规范一些。