Springcloud 微服务全家桶组件介绍

时间  2019-12-04 标签 springcloud 微服 全家 组件 介绍

Springcloud 微服务全家桶组件介绍

何为微服务介绍和理解

简介：微服务是最近的一两年的时间里是很火的一个概念。感受不学习一下都快跟不上时代的步伐了，下边作一下简单的总结和介绍。
何为微服务？简而言之，微服务架构风格这种开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每一个小型服务都运行在本身的进程中，并常常采用HTTP资源API这样轻量的机制来相互通讯。这些服务围绕业务功能进行构建，并能经过全自动的部署机制来进行独立部署。这些微服务可使用不一样的语言来编写，而且可使用不一样的数据存储技术。对这些微服务咱们仅作最低限度的集中管理。
一个微服务通常完成某个特定的功能，好比下单管理、客户管理等等。每个微服务都是微型六角形应用，都有本身的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。其它微服务完成一个Web UI，运行时，每个实例多是一个云VM或者是Docker容器，服务与服务之间相互隔离，独立部署，相互调用，使用HTTP协议json格式进行传输和调用。javascript

Netflix

在介绍Spring Cloud 全家桶以前，首先要介绍一下Netflix ，Netflix 是一个很伟大的公司，在Spring Cloud项目中占着重要的做用，Netflix 公司提供了包括Eureka、Hystrix、Zuul、Archaius等在内的不少组件，在微服务架构中相当重要，Spring在Netflix 的基础上，封装了一系列的组件，命名为：Spring Cloud Eureka、Spring Cloud Hystrix、Spring Cloud Zuul等，下边对各个组件进行分别得介绍html

一:Eureka(微服务注册中心)

咱们使用微服务，微服务的本质仍是各类API接口的调用，那么咱们怎么产生这些接口、产生了这些接口以后如何进行调用那？如何进行管理哪？前端

答案：就是Spring Cloud Eureka，咱们能够将本身定义的API 接口注册到Spring Cloud Eureka上，Eureka负责服务的注册于发现，若是学习过Zookeeper的话，就能够很好的理解，Eureka的角色和 Zookeeper的角色差很少，都是服务的注册和发现，构成Eureka体系的包括：服务注册中心、服务提供者、服务消费者。
在这里插入图片描述java

  1. 服务注册中心功能概述
    在服务治理框架中，一般都会构建一个注册中心，每一个服务单元向注册中心登记本身提供的服务，包括服务的主机与端口号、服务版本号、通信协议等一些附加信息。注册中心按照服务名分类组织服务清单，同时还须要以心跳检测的方式去监测清单中的服务是否可用，若不可用须要从服务清单中剔除，以达到排除故障服务的效果。
  2. Eureka服务端
    Eureka服务端，即服务注册中心。它同其余服务注册中心同样，支持高可用配置。依托于强一致性提供良好的服务实例可用性，能够应对多种不一样的故障场景。
    Eureka服务端支持集群模式部署，当集群中有分片发生故障的时候，Eureka会自动转入自我保护模式。它容许在分片发生故障的时候继续提供服务的发现和注册，当故障分配恢复时，集群中的其余分片会把他们的状态再次同步回来。集群中的的不一样服务注册中心经过异步模式互相复制各自的状态，这也意味着在给定的时间点每一个实例关于全部服务的状态可能存在不一致的现象。
    在默认配置下，Eureka Server会将本身也做为客户端来尝试注册本身
  3. Eureka客户端
    Eureka客户端，主要处理服务的注册和发现。客户端服务经过注册和参数配置的方式，嵌入在客户端应用程序的代码中。在应用程序启动时，Eureka客户端向服务注册中心注册自身提供的服务，并周期性的发送心跳来更新它的服务租约。同时，他也能从服务端查询当前注册的服务信息并把它们缓存到本地并周期行的刷新服务状态

pom依赖

// eureka
 <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka-server</artifactId>
</dependency>

@注解

@EnableEurekaServer //服务端注解
	EnableEurekaClient //客户端注解
  1. Eureka高可用服务注册中心
    考虑到发生故障的状况，服务注册中心发生故障必将会形成整个系统的瘫痪，所以须要保证服务注册中心的高可用。
    Eureka Server在设计的时候就考虑了高可用设计，在Eureka服务治理设计中，全部节点既是服务的提供方，也是服务的消费方，服务注册中心也不例外。
    Eureka Server的高可用实际上就是将本身作为服务向其余服务注册中心注册本身，这样就能够造成一组互相注册的服务注册中心，以实现服务清单的互相同步，达到高可用的效果。
  2. 失效剔除
    有些时候，咱们的服务实例并不必定会正常下线，可能因为内存溢出、网络故障等缘由使服务不能正常运做。而服务注册中心并未收到“服务下线”的请求，为了从服务列表中将这些没法提供服务的实例剔除，Eureka Server在启动的时候会建立一个定时任务，默认每隔一段时间（默认为60秒）将当前清单中超时（默认为90秒）没有续约的服务剔除出去。
  3. 自我保护
    服务注册到Eureka Server后，会维护一个心跳链接，告诉Eureka Server本身还活着。Eureka Server在运行期间会统计心跳失败的比例在15分钟以以内是否低于85%，若是出现低于的状况，Eureka Server会将当前实例注册信息保护起来，让这些实例不会过时。（目的就是在该服务可能存在网络延迟等问题，服务其实没有真正的宕机，若是服务恢复了可使他快速恢复，宁肯保存，也不误剔除）可是这样作会使客户端很容易拿到实际已经不存在的服务实例，会出现调用失败的状况。所以客户端要有容错机制，好比请求重试、断路器。
    也能够关闭自我保护属性：
    eureka.server.enableSelfPreservation=true.
    能够设置改参数值为false，以确保注册中心将不可用的实例删除。

二:Spring Cloud RestTemplate(服务接口调用模板)

简介：Spring为了简化客户端的Http访问的核心类。它简化了与Http服务端的通讯，而且遵循了RESTful的原则。处理了HTTP的链接，使得应用简单的运用提供的URLs（提供的模版参数）运行获得结果。RestTemplate是Spring提供的用于访问Rest服务的客户端，RestTemplate提供了多种便捷访问远程Http服务的方法，可以大大提升客户端的编写效率。nginx

  1. 模版主要有六种HTTP方法
    在这里插入图片描述
  2. @LoadBalanced 注解
    经过spring cloud Ribbon的封装，客户端的负载均衡只要完成如下二步：服务提供者只须要启动多个服务实例并注册到注册中心，服务端直接经过在RestTemplate上使用@LoadBalanced注解
    在这里插入图片描述

三:Spring Cloud Ribbon(本地客户端负载均衡)

简介：在SpringCloud中Ribbon负载均衡客户端，会从eureka注册中心服务器端上获取服务注册信息列表，缓存到本地。让后在本地实现轮训负载均衡策略Round Robin策略。
Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netfilx Ribbon实现。经过Spring Cloud封装，能够轻松地将面向服务的Rest模版请求自动转换为客户端负载均衡的服务调用。
Spring cloud Ribbon虽然只是一个工具类框架，它不像服务注册中心，配置中心，api网关那样须要独立部署，可是它几乎存在于每个Spring cloud构建的微服务和基础设施中。由于微服务间的调用，API网关的请求转发等内容，实际上都是经过Ribbon来实现的，包括Feign也是基于Ribbon实现的工具。git

  1. Ribbon与Nginx区别

服务器端负载均衡Nginx.web

#nginx是客户端全部请求统一交给nginx，由nginx进行实现负载均衡请求转发，属于服务器端负载均衡。既请求有nginx服务器端进行转发。算法

客户端负载均衡Ribbonspring

# Ribbon是从eureka注册中心服务器端上获取服务注册信息列表，缓存到本地，让后在本地实现轮训负载均衡策略。既在客户端实现负载均衡。json

应用场景的区别

# Nginx适合于服务器端实现负载均衡 好比Tomcat jboss，Ribbon适合与在微服务中RPC远程调用实现本地服务负载均衡，好比Dubbo、SpringCloud中都是采用本地负载均衡。

四:Spring Cloud Feign(声明式客户端调用工具)

简介：SpringCloudFeign是将二者作了更高层次的封装以简化开发。它基于Netfix Feign实现，整合了SpringCloudRibbon和SpringCloudHystrix，除了提供这二者的强大功能外，还提供了一种声明是的Web服务客户端定义的方式。SpringCloudFeign在NetFixFeign的基础上扩展了对SpringMVC注解的支持，在其实现下，咱们只需建立一个接口并用注解的方式来配置它，便可完成对服务提供方的接口绑定。简化了SpringCloudRibbon自行封装服务调用客户端的开发量。

@注解

@EnableFeignClients //注解开启SpringCloudFeign的支持功能
	@FeignClient（name=指定服务名，fallback=指定降级类） //接口声明调用

pom依赖

// feign
<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>
  1. Feign超时时间
    使用Feign调用接口分两层，ribbon的调用和hystrix的调用，因此ribbon的超时时间和Hystrix的超时时间的结合就是Feign的超时时间 默认调用接口超时1秒钟将会返回异常 能够进行时间加大配置

配置Feign客户端超时时间

###设置feign客户端超时时间
	ribbon:
		###指的是创建链接所用的时间，适用于网络情况正常的状况下，两端链接所用的时间。
 		ReadTimeout: 5000
		###指的是创建链接后从服务器读取到可用资源所用的时间。 
 		ConnectTimeout: 5000

在这里插入图片描述

五:Spring Cloud Hystrix(服务保护组件)

简介：Hystrix是国外知名的视频网站Netflix所开源的很是流行的高可用架构框架。Hystrix可以完美的解决分布式系统架构中打造高可用服务面临的一系列技术难题。
Hystrix “豪猪”，具备自我保护的能力。hystrix 经过以下机制来解决服务雪崩效应问题。
在微服务架构中，咱们把每一个业务都拆成了单个服务模块，而后当有业务需求时，服务间可互相调用，可是，因为网络缘由或者其余一些因素，有可能出现服务不可用的状况，当某个服务出现问题时，其余服务若是继续调用这个服务，就有可能出现线程阻塞，但若是同时有大量的请求，就会形成线程资源被用完，这样就可能会致使服务瘫痪，因为服务间会相互调用，很容易形成蝴蝶效应致使整个系统宕掉。所以，就有人提出来断路器来解决这一问题。

  1. 服务雪崩
     在微服务架构中，根据业务来拆分红一个个的服务，服务与服务之间能够相互调用（RPC），在Spring Cloud能够用RestTemplate+Ribbon和Feign来调用。为了保证其高可用，单个服务一般会集群部署。因为网络缘由或者自身的缘由，服务并不能保证100%可用，若是单个服务出现问题，调用这个服务就会出现线程阻塞，此时如有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，致使服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统形成灾难性的严重后果，这就是服务故障的“雪崩”效应。
     大型复杂的分布式系统中，高可用相关的技术架构很是重要。高可用架构很是重要的一个环节，就是如何将分布式系统中的各个服务打形成高可用的服务，从而足以应对分布式系统环境中的各类各样的问题，，避免整个分布式系统被某个服务的故障给拖垮。
    好比：服务间的调用超时服务间的调用失败要解决这些棘手的分布式系统可用性问题，就涉及到了高可用分布式系统中的不少重要的技术。
     例如：服务使用tomcat部署，tomcat会有一个线程池，线程池存在多个线程，每一个线程来负责处理每个请求，如 一个服务tomcat最大访问请求量为500 若是同时发送1000个请求过来，那么500个线程会去处理这个请求，其他500个就会进行等待状态，那么这个时候就会致使服务未及时响应，一直在排队状态，直到空闲的线程轮流处理这个请求，这个状态就能够叫作服务雪崩状态。
  2. 服务降级
    在高并发状况下，防止用户一直等待，使用服务降级方式(直接返回一个友好的提示给客户端，调用fallBack方法，或者使用其余回调方法进行处理。)
  3. 服务熔断
    熔断机制目的为了保护服务，在高并发的状况下（默认访问数量为10个请求），若是请求达到必定极限(能够本身设置阔值)若是流量超出了设置阈值，而后直接拒绝访问，保护当前服务。使用服务降级方式返回一个友好提示，服务熔断和服务降级一块儿使用。
  4. 服务隔离
    由于默认状况下，只有一个线程池会维护全部的服务接口，若是大量的请求访问同一个接口，达到tomcat 线程池默认极限，可能会致使其余服务没法访问。
    解决服务雪崩效应:使用服务隔离机制(线程池方式和信号量)，使用线程池方式实現隔离的原理: 至关于每一个接口(服务)都有本身独立的线程池，由于每一个线程池互不影响，这样的话就能够解决服务雪崩效应。
    线程池隔离
    每一个服务接口，都有本身独立的线程池，每一个线程池互不影响。
    信号量隔离:
    使用一个原子计数器（或信号量）来记录当前有多少个线程在运行，当请求进来时先判断计数器的数值，若超过设置的最大线程个数则拒绝该请求，若不超过则通行，这时候计数器+1，请求返 回成功后计数器-1。
  5. 服务限流
    服务限流就是对接口访问进行限制，经常使用服务限流算法令牌桶、漏桶。计数器也能够进行粗暴限流实现。

@注解

@EnableHystrix //开启服务保护

pom依赖

// hystrix
<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

配置文件

# 熔断器启用（默认关闭）
feign.hystrix.enabled=true
hystrix.command.default.execution.timeout.enabled=true

# 超时时间（默认1000ms，单位：ms） 
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=60000

# 线程池核心线程数（请求数10）
hystrix.threadpool.default.coreSize
#断路器默认20个

#断路器详细设置
#当在配置时间窗口内达到此数量的失败后，进行短路。默认20个）
#hystrix.command.default.circuitBreaker.requestVolumeThreshold=20

#短路多久之后开始尝试是否恢复，默认5s
#hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds=5

#出错百分比阈值，当达到此阈值后，开始短路。默认50%
#hystrix.command.default.circuitBreaker.errorThresholdPercentage=50%

服务降级两种实现

// hystrix
1.方法注解 @HystrixCommand  //默认已开启线程隔离、服务降级、 服务熔断默认10个请求）

2.接口方式 @FeignClient(fallback = xxxxx.class) //通常使用接口

仪表盘监控连接

参考连接: 仪表盘hystrix豪猪.
在这里插入图片描述
在这里插入图片描述

六:Spring Cloud config(分布式配置中心)

config架构
在这里插入图片描述

简介：当一个系统中的配置文件发生改变的时候，咱们须要从新启动该服务，才能使得新的配置文件生效，spring cloud config能够实现微服务中的全部系统的配置文件的统一管理，并且还能够实现当配置文件发生变化的时候，系统会自动更新获取新的配置。
 在分布式系统中，每个功能模块都能拆分红一个独立的服务，一次请求的完成，可能会调用不少个服务协调来完成，为了方便服务配置文件统一管理，更易于部署、维护，因此就须要分布式配置中心组件了，在spring cloud中，有分布式配置中心组件spring cloud config，它支持配置文件放在在配置服务的内存中（本地），也支持放在远程Git仓库里。引入spring cloud config后，咱们的外部配置文件就能够集中放置在一个git仓库里，再新建一个config server，用来管理全部的配置文件，维护的时候须要更改配置时，只须要在本地更改后，推送到远程仓库，全部的服务实例均可以经过config server来获取配置文件，分两个角色，一是config server，二是config client。

config 服务端依赖

// config
<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-config-server</artifactId>
</dependency>

config 服务端注解@

// config
@EnableConfigServer  //启动config配置中心

Git环境搭建

使用码云环境搭建git服务器端

百度搜索：码云 https://gitee.com/

在这里插入图片描述

yml配置文件

// config
###服务注册到eureka地址
eureka:
client:
 service-url:
        defaultZone: http://localhost:8100/eureka
spring:
application:
 ####注册中心应用名称
 name: config-server
cloud:
 config:
   server:
     git:
       ###git环境地址
       uri: https://gitee.com/xxxx/config.git
       ####搜索目录
       search-paths:
         - config  
   ####读取分支      
   label: master
####端口号      
server:
port: 8888

服务端启动类

@EnableConfigServer
@SpringBootApplication
public class ConfigServerApplication {
  public static void main(String[] args) {
  	SpringApplication.run(ConfigServerApplication.class, args);
  }
}

config 客户端依赖

<dependency>
  		<groupId>org.springframework.cloud</groupId>
  		<artifactId>spring-cloud-config-client</artifactId>
</dependency>

创建bootstrap.yml

// config
pring:
  application:
    ####注册中心应用名称
    name:  config-client
  cloud:
    config:
    ####读取后缀
      profile: dev
      ####读取config-server注册地址
      discovery:
        service-id: config-server
        enabled: true
#####    eureka服务注册地址    
eureka:
  client:
    service-url:
           defaultZone: http://localhost:8100/eureka    
server:
  port: 8882

config客户端读取配置文件

@RestController
public class IndexController {

 	@Value("${name}")
 	private String name;
 	
 	@RequestMapping("/name")
 	private String name() {
 		return name;
 	}
}

动态刷新数据

在SpringCloud中有手动刷新配置文件和实时刷新配置文件两种方式。
1.手动方式采用actuator端点刷新数据
2.使用bus消息总线刷新

actuator 使用端点刷新

//端点发送post请求刷新
<dependency> 
  <groupId>org.springframework.boot</groupId> 
  <artifactId>spring-boot-starter-actuator</artifactId> 
</dependency>

actuator 控制层

//端点发送post请求刷新，生效前提 在须要刷新的Bean上添加@RefreshScope注解。
@RestController
@RefreshScope
public class ConfigClientController {

 	// http://127.0.0.1:8882/actuator/refresh 发送post请求
 	//就可使用/refresh 这个节点来刷新带有@RefreshScope注解服务的bean
 	@Value("${userName}")
 	private String userName;
}

Bootstrap.xml 新增 （开启监控断点）

#监控全部
management:
	endpoints:
  	web:
   	 exposure:
      include: "*"

使用工具发送POST请求 http://127.0.0.1:8882/actuator/refresh 启动刷新器 从cofnig server读取最新配置

bus消息总线刷新集合RabbitMQ完成

三个项目中都加上该依赖信息

<!--核心jar包 -->
 	<dependency>
 		<groupId>org.springframework.cloud</groupId>
 		<artifactId>spring-cloud-starter-bus-amqp</artifactId>
 	</dependency>
 	<!-- actuator监控中心 -->
 	<dependency>
 		<groupId>org.springframework.boot</groupId>
 		<artifactId>spring-boot-starter-actuator</artifactId>
 	</dependency>

配置文件

###开启bus刷新
management:
  endpoints:
 	web:
   	exposure:
     include: bus-refresh
#下面配置默认链接本地能够忽略
spring.rabbitmq.host=localhost
spring.rabbitmq.port=5672
spring.rabbitmq.username=用户名
spring.rabbitmq.password=密码

刷新接口 http://127.0.0.1:8882/actuator/bus-refresh

七:Spring Cloud zuul(网关中心)

简介：网关的做用，能够实现负载均衡、路由转发、日志、权限控制、监控等。

API网关是一个更为智能的应用服务器，它的定义相似于面向对象设计模式中的Facade模式，它的存在就像是整个微服务架构系统的门面同样，全部的外部客户端访问都须要通过它来进行调度和过滤。它除了要实现请求路由、 负载均衡、 校验过滤等功能以外，还须要更多能力，好比与服务治理框架的结合、请求转发时的熔断机制、服务的聚合等一系列高级功能。

在SpringCloud中了提供了基于NetflixZuul实现的API网关组件Spring Cloud Zuul。那么，它是如何解决上面这两个广泛问题的呢？

首先，对于路由规则与服务实例的维护间题。SpringCloud Zuul经过与SpringCloud Eureka进行整合，将自身注册为Eureka服务治理下的应用，同时从Eureka中得到了全部其余微服务的实例信息。这样的设计很是巧妙地将服务治理体系中维护的实例信息利用起来，使得将维护服务实例的工做交给了服务治理框架自动完成，再也不须要人工介入。

其次，对千相似签名校验、登陆校验在微服务架构中的冗余问题。SpringCloud Zuul提供了一套过滤器机制，它能够 很好地支持这样的任务。开发者能够经过使用Zuul来建立各类校验过滤器，而后指定哪些规则的请求须要执行校验逻辑，只有经过校验的才会被路由到具体的微服务接口，否则就返回错误提示。经过这样的改造，各个业务层的微服务应用就再也不须要非业务性质的校验逻辑了，这使得咱们的微服务应用能够更专一千业务逻辑的开发，同时微服务的自动化测试也变得更容易实现。

简单来讲，就是既具有路由转发功能，又具有过滤器功能，好比将/aaa/**路径请求转发到service-ribbon服务上，将/bbb/***路径请求转发到service-feign服务上，好比过滤，对请求参数的信息进行过滤，不符合的进行过滤拦截等。

  1. 网关与过滤器区别
    网关是拦截全部服务器请求进行控制
    过滤器拦截某单个服务器请求进行控制
  2. Nginx与Zuul的区别
    Nginx是采用服务器负载均衡进行转发
    Zuul依赖Ribbon和eureka实现本地负载均衡转发
    相对来讲Nginx功能比Zuul功能更增强大可以整合其余语言好比lua脚本实现强大的功能

pom依赖

<dependency>
  		<groupId>org.springframework.cloud</groupId>
  		<artifactId>spring-cloud-starter-netflix-zuul</artifactId>
</dependency>

application.yml依赖

###注册 中心
eureka:
client:
  serviceUrl:
    defaultZone: http://localhost:8100/eureka/
server:
port: 80
###网关名称
spring:
application:
  name: service-zuul
### 配置网关反向代理    
zuul:
routes:
  api-a:
   ### 以 /api-member/访问转发到会员服务
    path: /api-member/** serviceId: app-itmayiedu-member api-b: ### 以 /api-order/访问转发到订单服务 path: /api-order/** serviceId: app-itmayiedu-order

Zuul 默认开启了 Ribbon本地负载均衡功能。

八:Swagger（api接口规范文档）

简介：对API文档进行更新的时候，须要通知前端开发人员，致使文档更新交流不及时；
API接口返回信息不明确

大公司中确定会有专门文档服务器对接口文档进行更新。

缺少在线接口测试，一般须要使用相应的API测试工具，好比postman、SoapUI等
接口文档太多，不便于管理
为了解决传统API接口文档维护的问题，为了方便进行测试后台Restful接口并实现动态的更新，于是引入Swagger接口工具。

Swagger具备如下优势
1.功能丰富：支持多种注解，自动生成接口文档界面，支持在界面测试API接口功能；
2.及时更新：开发过程当中花一点写注释的时间，就能够及时的更新API文档，省心省力；
3.整合简单：经过添加pom依赖和简单配置，内嵌于应用中就可同时发布API接口文档界面，不须要部署独立服务。

pom依赖

<!-- swagger2 -->
  	<dependency>
  		<groupId>io.springfox</groupId>
  		<artifactId>springfox-swagger2</artifactId>
  		<version>2.8.0</version>
  	</dependency>
  	<dependency>
  		<groupId>io.springfox</groupId>
  		<artifactId>springfox-swagger-ui</artifactId>
  		<version>2.8.0</version>
  	</dependency>

SwaggerConfig

@Configuration
@EnableSwagger2
public class SwaggerConfig {

 @Bean
 public Docket createRestApi() {
 	return new Docket(DocumentationType.SWAGGER_2).apiInfo(apiInfo()).select()
 			// api扫包
 			.apis(RequestHandlerSelectors.basePackage("com.xxxx.api")).paths(PathSelectors.any()).build();
 }

 private ApiInfo apiInfo() {
 	return new ApiInfoBuilder().title(" 微服务系统").description("Java分布式&微服务培训")
 			.termsOfServiceUrl("http://www.xxxx.com")
 			// .contact(contact)
 			.version("1.0").build();
 }
 
}

启动类

在这里插入图片描述

controller类

在这里插入图片描述

访问地址:http://localhost:8060/swagger-ui.html#/swagger-controller
在这里插入图片描述

Zull整合Swagger管理微服务全部API

会员和订单引入Maven依赖

<!-- swagger-spring-boot -->
 	<dependency>
 		<groupId>com.spring4all</groupId>
 		<artifactId>swagger-spring-boot-starter</artifactId>
 		<version>1.7.0.RELEASE</version>
 	</dependency>

application.yml配置

#Api接口扫描范围
swagger:
base-package: com.ai.api

项目启动引入开启生成文档

@EnableSwagger2Doc

ZuulGateway网关

#Api接口扫描范围
swagger:
base-package: com.ai.api

项目启动引入开启生成文档

@SpringBootApplication
@EnableEurekaClient
@EnableZuulProxy
@EnableSwagger2Doc
public class AppGateWay {

 // @EnableZuulProxy 开启网关代理

 public static void main(String[] args) {
 	SpringApplication.run(AppGateWay.class, args);
 }

 // zuul配置可以使用config实现实时更新
 @RefreshScope
 @ConfigurationProperties("zuul")
 public ZuulProperties zuulProperties() {
 	return new ZuulProperties();
 }

 // 添加文档来源
 @Component
 @Primary
 class DocumentationConfig implements SwaggerResourcesProvider {
 	@Override
 	public List<SwaggerResource> get() {
 		List resources = new ArrayList<>();
 		// app-itmayiedu-order
 		resources.add(swaggerResource("app-ai-member", "/api-member/v2/api-docs", "2.0"));
 		resources.add(swaggerResource("app-ai-order", "/api-order/v2/api-docs", "2.0"));
 		return resources;
 	}

 	private SwaggerResource swaggerResource(String name, String location, String version) {
 		SwaggerResource swaggerResource = new SwaggerResource();
 		swaggerResource.setName(name);
 		swaggerResource.setLocation(location);
 		swaggerResource.setSwaggerVersion(version);
 		return swaggerResource;
 	}
 }

}

Maven依赖信息

<dependency>
  		<groupId>com.spring4all</groupId>
  		<artifactId>swagger-spring-boot-starter</artifactId>
  		<version>1.7.0.RELEASE</version>
  	</dependency>

在这里插入图片描述

总结:SpringCloud与Dubbo区别

为何放弃Dubbo 使用SpringCloud？


相同点：SpringCloud 和Dubbo能够实现RPC远程调用框架，能够实现服务治理。

不一样点:
SpringCloud是一套目前比较网站微服务框架了，整合了分布式经常使用解决方案遇到了问题注册中心Eureka、负载均衡器Ribbon ，客户端调用工具Rest和Feign，分布式配置中心Config，服务保护Hystrix，网关Zuul Gateway ，服务链路Zipkin，消息总线Bus等。 

从架构上分析
Dubbo内部实现功能没有SpringCloud强大，只是实现服务治理，缺乏分布式配置中心、网关、链路、总线等，若是须要用到这些组件，须要整合其余框架。

从更新迭代速度分析
Dubbo目前更新速度没有SpringCloud快，到SpringCloud2.0后SpringCloud会越来完善和稳定。

从开发背景角度分析
Dubbo的开发背景是阿里巴巴， 在中国也推出了很是多的优秀的开源框架
可是在SpringCloud的背景是Spring家族，Spring是专一于企业级开源框架开发，在中国，或者在整个世界上Spring框架都应用的很是普遍。全部相对来讲SpringCloud的背景比Dubbo更增强大。

最后总结下：若是学习Dubbo的话，学习其余的分布式解决方案须要本身组装，反而若是学习SpringCloud，它已经把整个经常使用分布式解决都整合好了。



SpringCloud与Dubbo区别


相同点:都是rpc远程调用框架，能够实现服务治理（管理服务关系注册中心）

不一样点：springcloud是目前比就完善的微服务框架，整合了netflix，集成了注册中心Eureka,负载均衡ribbon,客户端调用工具feign，分布式配置中心cofig,服务保护Hystrix，网关zuul gateway,服务链路zipkin,消息总线bus，

架构方面：
dubbo只有实现了服务治理，负载均衡，其余组件须要本身集成第三方应用，而springcloud已经帮忙集成全部组件，因此使用整合更加完善。

更新迭代方面
Dubbo更新缓慢，前几年基本无更新，springcloud更新维护快，更加完善稳定。

开发背景分析
dubbo是阿里开发，在国内是比较承认的，可是springcloud是spring家族开发的，国际化使用，专门专一开源框架开发，在全球使用更加普遍。

总结
Dubbo若是开发许多组件没有集成不完善，须要主动集成第三方组件，springcloud已经帮咱们集成，只须要引入依赖和注解就搞定了，简单，稳定，快捷。

以上总结所有是我的和网上经验总结，若有雷同，请谅解，欢迎你们研讨技术，点关注，后续继续更新…

联系我们 沪ICP备13005482号-10