如何自动化合并多个应用的Open API规范并支持按规则过滤接口

一、OAS自动合并+过滤工具（完全匹配你当前API优先的开发流程） #

这类方案不需要调整现有微服务的开发、发布逻辑，只需要在CI/CD环节加少量配置即可实现全自动化的聚合规范维护：

• openapi-merge：轻量CLI工具/JS库，支持多份OAS 3.0+规范合并，原生支持按接口标签、路径前缀、安全方案过滤接口。你可以在流水线中增加定时任务：拉取Swagger Hub上所有微服务的独立OAS文件，按消费者类型配置过滤规则（比如筛选仅要求user-token的接口生成「公开客户端API」，筛选要求M2M token的接口生成「后端集成API」），合并完成后自动推回Swagger Hub对应聚合规范的仓库，全程不需要人工介入。
• Redocly CLI：更专业的API治理工具，除了基础的合并过滤能力外，还支持合并后自动做规范校验、模块分类重命名，你需要的「按业务能力拆分分类模块」的需求可以直接通过配置实现。你还可以给微服务的OAS接口增加x-consumer-types: [public-client, backend-integration]这类自定义扩展字段，过滤的时候直接按扩展字段筛选，比读取安全配置灵活性更高。
• Swagger Hub 企业版原生能力：如果你用的是付费版Swagger Hub，本身内置了「规范引用+虚拟合并」功能，不需要手动复制内容，直接在聚合规范里用$ref引用各微服务独立规范的对应路径、组件，搭配内置的过滤规则就能生成面向不同消费者的规范视图，不需要额外搭建CI流程。

二、如果后续考虑切换代码生成OAS的流程，也有全自动化方案 #

如果你们后续确定改用.NET属性注解从代码生成OAS，可以用更底层的方案保证规范一致性：

• 借助API网关实现聚合：不管是商用的Azure APIM还是开源的Kong、APISIX，都支持自动拉取后端微服务的OAS，按标签过滤后生成不同维度的聚合规范，还能直接和网关的权限配置对齐，完全避免对外输出的OAS和实际可调用的接口不一致的问题。
• 自研轻量聚合工具：用微软官方的Microsoft.OpenApi库开发简单的.NET工具，批量拉取所有微服务的OAS，按自定义规则过滤合并，部署成定时任务或者接入Webhook，每次微服务发布就自动触发聚合规范更新，适配性更高。

落地建议 #

优先选择「开源CLI工具+CI/CD」的方案，完全不需要改动当前API优先的开发流程，也不需要调整微服务侧的代码，一周内就能跑通全流程，不会出现代码生成OAS和设计规范不一致的问题。

内容的提问来源于stack exchange，提问作者Ryan.Bartsch