Knife4j聚合EurekaNacos
简介
knife4j是为Java MVC框架集成Swagger⽣成Api⽂档的增强解决⽅案
Eureka模式原理是，在聚合⽂档⼯程配置Eureka注册中⼼地址和每个服务名称，这样聚合⽂档⼯程启动的时候可以从Eureka访问到每个微服务的http接⼝⽂档资源地址，从⽽聚合每个微服务的接⼝⽂档
由于聚合⽂档⼯程需要能访问到Eureka获取每个微服务的信息才能做聚合，所以在聚合⽂档⼯程启动之前要先启动Eureka和需要被聚合的每个微服务，并且每个微服务要成功注册到Eureka中
每个微服务⾃⼰要做好Swagger⽂档的相关配置
版本说明
⽬前Knife4j的主版本依然是沿⽤2.x的版本号，也就是从2.0.6版本开始逐步升级，迭代发布时版本会随之升级，但同时3.x版本也会同步更新发布，主要是满⾜开发者对于springfox3以及OpenAPI3规范的使⽤
2.x与
3.x的版本主要变化是底层springfox所引⽤的版本不同，但Knife4j提供的Ui其实是同⼀个，同时兼容OpenAPI2以及OpenAPI3
规范，源码请参考，如果开发者依然想沿⽤以前Knife4j⼀直以来发布的2.x版本，请继续更随Knife4j的更新步伐使⽤2.x的版本即可，如果开发者想尝鲜，则可以考虑3.x的版本
3.x的版本依赖springfox3.0.0，springfox3.0⽬前也只更新发布了⼀个版本，从功能稳定性来说，可能不如2.x系列，所以开发者慎
重使⽤，当然，如果是Ui上的⼀些功能性问题或者Bug，也欢迎开发者向Knife4j，等springfox3版本趋于稳定后，knife4j的2.x版本就不会在更新，会并向3.x
官⽹地址
依赖
knife4j-spring-boot-starter是knife4j基础依赖，在业务模块引⼊即可（例如订单服务，⽀付服务，详细请往下阅读）
knife4j-aggregation-spring-boot-starter是knife4j聚合依赖，在⽂档模块引⼊即可（详细请往下阅读）
如果觉得单独引⼊⿇烦，可以在⽗POM引⼊
<dependency>
<groupId>com.github.xiaoymin</groupId>
<artifactId>knife4j-spring-boot-starter</artifactId>
<version>2.0.9</version>
</dependency>
<dependency>
<groupId>com.github.xiaoymin</groupId>
<artifactId>knife4j-aggregation-spring-boot-starter</artifactId>
<version>2.0.9</version>
</dependency>
⼯程
⼯程⽬录（此处引⼊官⽹图⽚）
⼯程说明
⼯程名字说明
service-server（eureka或者nacos）Eureka注册中⼼
service-payment（业务模块）⼀个⾮常简单的⽀付服务，包含⽀付接⼝
service-order（业务模块）⼀个⾮常简单的订单服务，包含订单接⼝
service-doc（⽂档模块）聚合⽂档⼯程，也是⼀个Spring Boot⼯程，不过需要注意的是基于web的，⽽⾮webflux 依赖说明
在service-payment和service-order等业务模块引⼊knife4j-spring-boot-starter
在service-doc⽂档模块引⼊knife4j-aggregation-spring-boot-starter
服务配置
service-payment,service-order等业务模块创建各⾃的配置⽂件（不创建的话可能会缺失⼀些⽂档基础信息，但是不影响使⽤）
@EnableSwagger2WebMvc
public class SwaggerConfig {
/**
* 创建Docket存⼊容器，Docket代表⼀个接⼝⽂档
* @return
*/
@Bean
public Docket webApiConfig(){
return new Docket(DocumentationType.SWAGGER_2)
// 创建接⼝⽂档的具体信息
.apiInfo(webApiInfo())
// 创建选择器，控制哪些接⼝被加⼊⽂档
.select()
// 指定@ApiOperation标注的接⼝被加⼊⽂档
.apis(RequestHandlerSelectors.withMethodAnnotation(ApiOperation.class))
.build();
}
/**
* 创建接⼝⽂档的具体信息，会显⽰在接⼝⽂档页⾯中
* @return
*/
private ApiInfo webApiInfo(){
return new ApiInfoBuilder()
// ⽂档标题
.title("elon-cloud接⼝⽂档")
// ⽂档简介
.description("本⽂档描述了elon-cloud系统的接⼝定义")
/
/ 版本
.version("1.0")
// 联系⼈信息
.contact(new Contact("elon","eloncloud","1757xxx385@qq"))
// 版权
.license("elon")
.build();
}
service-doc 配置yml⽂件
server:
port:10909
knife4j:
enableAggregation:true
微服务注册中心有哪些eureka:
enable:true
serviceUrl: elon-eureka-7001:7001/eureka/ # 注册中⼼地址
routes:
-name:⽀付服务
serviceName: elon-payment-biz  # 业务模块服务名称
location: /v2/api-docs?group=default
servicePath: /payment
-name：订单服务
serviceName: elon-order-biz # 业务模块服务名称
location: /v2/api-docs?group=default
servicePath: /order
其余详细说明请见最下⽅
启动
按顺序启动service-server，service-payment，service-order，service-doc 即 先启动注册中⼼，在启动业务模块，最后启动knife4j⽂档模块
Nacos
Nacos的配置和⼏乎⼀模⼀样，唯⼀不同的区别是在yml进⾏配置的时候，使⽤的是knife4j.nacos开头，其他基本都是⼀样聚合⽂档doc模块yml详细配置
able：将该属性设置为true，则代表启⽤Eureka模式
knife4j.eureka.serviceUrl:Eureka注册中⼼的地址
knife4j.eureka.serviceAuth：该属性是⼀个公共Basic验证属性(可选)，如果Eureka的注册和获取服务需要进⾏Basic认证，开发者需要配置该属性
knife4j.able：是否启⽤Eureka注册中⼼Basic验证
knife4j.eureka.serviceAuth.usernae:Eureka注册中⼼Basic⽤户名
knife4j.eureka.serviceAuth.password:Eureka注册中⼼Basic密码
uteAuth：该属性是⼀个公共Basic验证属性(可选)，如果开发者提供的OpenAPI规范的服务需要以Basic验证进⾏鉴权访问，那么可以配置该属性，如果配置该属性，则该模式下所有配置的Routes节点接⼝都会以Basic验证信息访问接⼝
able：是否启⽤Basic验证
uteAuth.usernae:Basic⽤户名
uteAuth.password:Basic密码
utes：需要聚合的服务集合(必选)，可以配置多个
utes.name：服务名称(显⽰名称，最终在Ui的左上⾓下拉框进⾏显⽰)，如果该属性不配置，最终Ui会显⽰serviceName utes.serviceName:Eureka注册中⼼的服务名称
utes.uri：该服务的接⼝URI资源，如果是HTTPS，则需要完整配置
utes.location:：具体资源接⼝地址，最终Knife4j是通过注册服务uri+location的组合路径进⾏访问
utes.swaggerVersion：版本号，默认是2.0，可选配置
utes.servicePath：该属性是最终在Ui中展⽰的接⼝前缀属性，提供该属性的⽬的也是因为通常开发者在以Gateway等⽅式聚合时，需要⼀个前缀路径来进⾏转发，⽽最终这个前缀路径会在每个接⼝中进⾏追加
uteAuth：如果该Route节点的接⼝开启了Basic，并且和公共配置的Basic不⼀样，需要单独配置
able：是否启⽤Basic验证
uteAuth.usernae:Basic⽤户名
uteAuth.password:Basic密码

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。