微服务聚合文档技术实现方案
1.前言
随着时代的发现，我们的项目也从以前的，单节点项目(所有功能都向一个项目中堆，维护性差)，最近几年，微服务使用的人群越越来越广，一个简单的电影系统，我们也可以按模块进行切换，例如，分为订单模块，电影模块，支付模块，会员模块等等。

而文档维护起来的成本也越来越高，有时候，我们一个系统，就可以拆分成上100个服务，这时，我们的文档如何维护了？假设，我们有100个服务，我们搭建100个swagger，那就得有100个网站，对于开发人员的文档维护，是非常繁琐的。

针对这种情况，我们只能通过swagger聚合文档的方式来解决。

2.系统环境
3.微服务面临的挑战
2.1当前面临的问题
1) 文档需要更新的时候，需要再次发送一份给前端，也就是文档更新交流不及时。

2) 接口返回结果不明确
3) 不能直接在线测试接口，通常需要使用工具，比如postman
4) 接口文档太多，不好管理
5) 接口文档与对应代码匹配不上，导致接口文档基本无用。

6) 对于有较多微服务的系统来说，一个服务一个文档地址，麻烦且不方便管理
由于接口众多，并且细节复杂（需要考虑不同的HTTP请求类型、HTTP头部信息、HTTP请求内容等），高质量地创建这份文档本身就是件非常吃力的事，下游的抱怨声不绝于耳。

随着时间推移，不断修改接口实现的时候都必须同步修改接口文档，而文档与代码又处于两个不同的媒介，除非有严格的管理机制，不然很容易导致不一致现象。

2.2 swagger介绍
为了解决上面这样的问题，本文将介绍RESTful API的重磅好伙伴Swagger2，它可以轻松的整合到Spring Boot和微服务当中，并与Spring MVC程序配合组织出强大RESTful API文档。

它既可以减少我们
创建文档的工作量，同时说明内容又整合入实现代码中，让维护文档和修改代码整合为一体，可以让我们在修改代码逻辑的同时方便的修改文档说明。

另外Swagger2也提供了强大的页面测试功能来调试每个RESTful API。

2.2swagger的不足
Swagger作为接口文档工具接入springboot工程很方便，只需一个starter，一个configuration就可集成完毕。

但是对于有较多微服务的系统来说，一个服务一个文档地址，便会觉得比较麻烦。

有没有什么好的办法可以都把他们集中起来？
这时候聚合文档的解决方案出现了，将所有的微服务地址以swagger分组的形式展现，切换分组的时候就相当于直接切换了整个微服务。

4.技术架构
5.功能特点
3.1文档聚合效果
点击图中所示下拉选，可切换不同服务模块的api文档
点击权限设置菜单，可查询该api的请求示例、请求参数、响应状态、响应参数、响应示例信息。

点击调试，可根据提供的请求参数说明，发送对应的请求
3.2 swagger聚合文档技术选型
目前采用：swagger2技术+ swagger-bootstrap-ui技术（页面增强型）
3.2.1 swagger2技术
3.2.1.1 swagger生态图
3.2.1.2 swagger2介绍
Swagger是一款让你更好的书写API文档的规范且完整框架，提供描述、生产、消费和可视化RESTful API。

是由庞大工具集合支撑的形式化规范。

这个集合涵盖了从终端用户接口、底层代码库到商业API管理的方方面面。

通过代码和注释自动生成文档。

在Swagger框架下，开发人员可对服务进行归类说明，对方法，模型，返回结果等进行详细说明。

方便开发人员在编写代码的同时，编写文档信息。

自动生成，只需很少的编辑工作，就能获得完整的REST APIs文档。

3.2.2 swagger-bootstrap-ui技术
3.2.2.1 swagger-bootstrap-ui简介
swagger-bootstrap-ui是springfox-swagger的增强UI实现，为Java开发者在使用Swagger的时候，能拥有一份简洁、强大的接口文档体验。

3.2.2.2 核心功能
该UI增强包主要包括两大核心功能：文档说明和在线调试。

文档说明：根据Swagger的规范说明，详细列出接口文档的说明，包括接口地址、类型、请求示例、请求参数、响应示例、响应参数、响应码等信息，使用swagger-bootstrap-ui能根据该文档说明，对该接口的使用情况一目了然。

在线调试：提供在线接口联调的强大功能，自动解析当前接口参数,同时包含表单验证，调用参数可返回接口响应内容、headers、Curl请求命令实例、响应时间、响应状态码等信息，帮助开发者在线调试，而不必通过其他测试工具测试接口是否正确,简介、强大。

3.2.2.3 swagger-bootstrap-ui与官方swagger-ui的区别
每一个增强的功能都是贴合实际,考虑到开发者的实际开发需要,是必不可少的功能，主要包括：
个性化配置：通过个性化ui配置项，可自定义UI的相关显示信息
离线文档：根据标准规范，生成的在线markdown离线文档，开发者可以进行拷贝生成markdown接口文档，通过其他第三方markdown转换工具转换成html或pdf，这样也可以放弃swagger2markdown组件
接口排序：自1.8.5后，ui支持了接口排序功能，例如一个注册功能主要包含了多个步骤,可以根据swagger-bootstrap-ui提供的接口排序规则实现接口的排序，step化接口操作，方便其他开发者进行接口对接
3.2.2.4 UI特点
●以markdown形式展示文档,将文档的请求地址、类型、请求参数、示例、响应参数分层次依次展示,
接口文档一目了然,方便开发者对接
●在线调试栏除了自动解析参数外,针对必填项着颜色区分,同时支持tab键快速输入上下切换.调试时
可自定义Content-Type请求头类型
●个性化配置项,支持接口地址、接口description属性、UI增强等个性化配置功能
●接口排序,支持分组及接口的排序功能
●支持markdown文档离线文档导出,也可在线查看离线文档
●调试信息全局缓存,页面刷新后依然存在,方便开发者调试
●以更人性化的treetable组件展示Swagger Models功能
●响应内容可全屏查看,针对响应内容很多的情况下，全屏查看，方便调试、复制
●文档以多tab方式可显示多个接口文档
●请求参数栏请求类型、是否必填着颜色区分
●主页中粗略统计接口不同类型数量
●支持接口在线搜索功能
●左右菜单和内容页可自由拖动宽度
●支持自定义全局参数功能，主页包括header及query两种类型
●i18n国际化支持,目前支持：中文简体、中文繁体、英文
●JSR-303 annotations 注解的支持
6.设计阶段
6.1 总体设计
功能规划：
1. 针对若干个微服务，每个类名controller、api请求增加swagger注解，以便动态生成api文当等。

2. 按照不同的服务进行分类，同时图形化展示api文当，并提供在线调试功能和离线文档功能。

3. 支持全局搜索、全局参数
4. 版本控制、国际化
6.2 微服务拆分原则
1.粒度微小：
根据业务功能划分服务粒度，总的原则是服务内部高内聚，服务之间低耦合。

2.责任单一：
每个服务只做一件事，即单一职责原则。

3.隔离性原则：
每个服务相互隔离，且不互相影响
4.业务无关优先原则：
基础服务，是一些基础组件，与具体的业务无关。

比如：短信服务、邮件服务。

这里的服务最容易划分出来做微服务，也是我们第一优先级分离出来的服务。

6.3 开发策略
总体规则：
针对多个不同的微服务模块，每个模块处理api请求类增加swagger注解。

常用注解：
●@Api()用于类；
表示标识这个类是swagger的资源
●@ApiOperation()用于方法；
表示一个http请求的操作
●@ApiParam()用于方法，参数，字段说明；
表示对参数的添加元数据（说明或是否必填等）
●@ApiModel()用于类
表示对类进行说明，用于参数用实体类接收
●@ApiModelProperty()用于方法，字段
表示对model属性的说明或者数据操作更改
●@ApiIgnore()用于类，方法，方法参数
表示这个方法或者类被忽略
●@ApiImplicitParam() 用于方法
表示单独的请求参数
●@ApiImplicitParams() 用于方法，包含多个@ApiImplicitParam
6.4 统一配置管理
集成nacos，可实时修改swagger的相应配置或其他配置
6.5 API鉴权
基于JWT 封装，每次请求的时候，会拦截到需要鉴权的API请求，并对其请求头携带的Token进行认证。

若Token过期、不存在、错误，都会导致鉴权失败，继而无法访问到对应的API。