为什么要学习Spring Cloud

在项目开发中随着业务越来越多，导致功能之间耦合性高、开发效率低、系统运行缓慢难以维护、不稳定。微服务

架构可以解决这些问题，而Spring Cloud是微服务架构最流行的实现.

1.微服务

微服务架构是使用一套小服务来开发单个应用的方式或途径，每个服务基于单一业务能力构建，运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，并能够通过自动化部署机制来独立部署。这些服务可以使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。微服务结构图：

API Gateway网关是一个服务器，是系统的唯一入口。网关提供RESTful/HTTP的方式访问服务。而服务端通过服务注册中心进行服务注册和管理。

微服务的特点：

单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责

面向服务：面向服务是说每个服务都要对外暴露服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供REST的接口即可。

自治：自治是说服务间互相独立，互不干扰

团队独立：每个服务都是一个独立的开发团队。

技术独立：因为是面向服务，提供REST接口，使用什么技术没有别人干涉

前后端分离：采用前后端分离开发，提供统一REST接口，后端不用再为PC、移动段开发不同接口

数据库分离：每个服务都使用自己的数据源

2.远程调用方式

常见的远程调用方式有以下几种：

RPC：Remote Procedure Call远程过程调用，类似的还有RMI。自定义数据格式，基于原生TCP通信，速度快，效率高。早期的Web Service，现在热门的Dubbo，都是RPC的典型。

HTTP：HTTP其实是一种网络传输协议，基于TCP，规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用HTTP协议。也可以用来进行远程服务调用。缺点是消息封装臃肿。现在热门的REST风格，就可以通过HTTP协议来实现。

2.1.认识RPC

RPC，即 Remote Procedure Call（远程过程调用），是一个计算机通信协议。该协议允许运行于一台计算机的序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。说得通俗一点就是：A计算机提供一个服务，B计算机可以像调用本地服务那样调用A计算机的服务。

RPC调用流程图：

2.2.认识HTTP

HTTP其实是一种网络传输协议，基于TCP，工作在应用层，规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用HTTP协议，也可以用来进行远程服务调用。缺点是消息封装臃肿，优势是对服务的提供和调用方没有任何技术限定，自由灵活，更符合微服务理念。现在热门的REST风格，就可以通过HTTP协议来实现。

2.3.如何选择？

如果你们公司全部采用Java技术栈，那么使用Dubbo作为微服务架构是一个不错的选择。

如果公司的技术栈多样化，而且你更青睐Spring家族，那么Spring Cloud搭建微服务是不二之选。会选择Spring Cloud套件，因此会使用HTTP方式来实现服务间调用。

3.Spring Cloud简介

3.1.简介

Spring Cloud是Spring旗下的项目之一，官网地址：点我进入

Spring最擅长的就是集成，把世界上最好的框架拿过来，集成到自己的项目中。

Spring Cloud也是一样，它将现在非常流行的一些技术整合到一起，实现了诸如：配置管理，服务发现，智能路由，负载均衡，熔断器，控制总线，集群状态等等功能。

其主要涉及的组件包括：

Netﬂix

Eureka：注册中心

Zuul：服务网关

Ribbon：负载均衡

Feign：服务调用

Hystrix：熔断器

以上只是其中一部分，架构图：

3.2.版本

Spring Cloud的版本命名比较特殊，因为它不是一个组件，而是许多组件的集合，它的命名是以A到Z为首字母的一些单词组成(其实是伦敦地铁站的名字)：

Spring Clound 和Spring Boot版本对应关系

4.微服务场景模拟

4.1. 创建父工程

微服务中需要同时创建多个项目，为了方便课堂演示，先创建一个父工程，后续的工程都以这个工程为父，使用Maven的聚合和继承。统一管理子工程的版本和配置

pom.xml文件：

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd"><modelVersion>4.0.0</modelVersion><groupId>com.lxs</groupId><artifactId>lxs-springcloud</artifactId><packaging>pom</packaging><version>1.0-SNAPSHOT</version><parent><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-parent</artifactId><version>2.1.5.RELEASE</version><relativePath/></parent><properties><java.version>1.8</java.version><spring-cloud.version>Greenwich.SR1</spring-cloud.version><mapper.starter.version>2.1.5</mapper.starter.version><mysql.version>5.1.46</mysql.version></properties><dependencyManagement><dependencies><!-- springCloud --><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-dependencies</artifactId><version>${spring-cloud.version}</version><type>pom</type><scope>import</scope></dependency><!-- 通用Mapper启动器 --><dependency><groupId>tk.mybatis</groupId><artifactId>mapper-spring-boot-starter</artifactId><version>${mapper.starter.version}</version></dependency><!-- mysql驱动 --><dependency><groupId>mysql</groupId><artifactId>mysql-connector-java</artifactId><version>${mysql.version}</version></dependency></dependencies></dependencyManagement><dependencies><dependency><groupId>org.projectlombok</groupId><artifactId>lombok</artifactId></dependency></dependencies><build><plugins><plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId></plugin></plugins></build>
</project>

注意：spring clound和spring boot 的版本对应 greenwich版本clound对应spring boot 2.1.x

注意：注意聚合父工程 <packaging>pom</packaging>

这里已经对大部分要用到的依赖的版本进行了管理，方便后续使用

4.2.服务提供者

我们新建一个项目，对外提供查询用户的服务。

4.2.1.创建Module

选中父工程-springclound，创建子工程：

pom.xml文件

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd"><parent><artifactId>lxs-springcloud</artifactId><groupId>com.lxs</groupId><version>1.0-SNAPSHOT</version></parent><modelVersion>4.0.0</modelVersion><artifactId>user-service</artifactId><dependencies><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency><!-- 通用Mapper启动器 --><dependency><groupId>tk.mybatis</groupId><artifactId>mapper-spring-boot-starter</artifactId></dependency><!-- mysql驱动 --><dependency><groupId>mysql</groupId><artifactId>mysql-connector-java</artifactId></dependency></dependencies>
</project>

项目结构如下

4.2.2.编写配置文件

创建 user-service\src\main\resources\application.yml 属性文件,这里我们采用了yaml语法，而不是

properties：

server:port: 9091
spring:datasource:driver-class-name: com.mysql.jdbc.Driverurl: jdbc:mysql://localhost:3306/springcloundusername: rootpassword: root
mybatis:type-aliases-package: com.zx.bean

启动类

@SpringBootApplication@MapperScan("com.zx.mapper")public class UserApplication {public static void main(String[] args) {SpringApplication.run(UserApplication.class, args);}}

实体类

service：

@Servicepublic class UserService {@Autowiredprivate UserMapper userMapper;public User queryById(Long id) {return this.userMapper.selectByPrimaryKey(id);}}

controller

@RestController@RequestMapping("/user")public class UserController {@Autowiredprivate UserService userService;@GetMapping("/{id}")public User queryById(@PathVariable Long id){return userService.queryById(id);}}

对外提供REST风格web 服务，根据id查询用户

完成上述代码后的项目结构

4.2.4. 启动并测试

启动项目，访问http://localhost:9091/user/7

4.3.服务调用者

4.3.1.创建工程

与上面类似，这里不再赘述，需要注意的是，我们调用 user-service 的功能，因此不需要Mybatis相关依赖了

拷贝之前的user-service 模块，更改响应的坐标

pom:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><parent><artifactId>lxs-springcloud</artifactId><groupId>com.lxs</groupId><version>1.0-SNAPSHOT</version></parent><modelVersion>4.0.0</modelVersion><artifactId>consumer-demo</artifactId><dependencies><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency></dependencies>
</project>

pom：

<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0http://maven.apache.org/xsd/maven-4.0.0.xsd"><parent><artifactId>lxs-springcloud</artifactId><groupId>com.lxs</groupId><version>1.0-SNAPSHOT</version></parent><modelVersion>4.0.0</modelVersion><artifactId>consumer-demo</artifactId><dependencies><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency></dependencies></project>

项目结构如下：

4.3.2.编写代码

启动器：

@SpringBootApplicationpublic class ConsumerApplication {public static void main(String[] args) {SpringApplication.run(ConsumerApplication.class, args);}   @Beanpublic RestTemplate restTemplate(){return new RestTemplate();}}

Spring提供了一个RestTemplate模板工具类，对基于http的客户端进行了封装，并且实现了对象与json的序列化和反序列化，非常方便。RestTemplate并没有限定http的客户端类型，而是进行了抽象，目前常用的3种都有支持：

httpClient

Okhttp

JDK原生的URLConnection（默认的）

实体类

@Datapublic class User {private Long id;// 用户名private String userName;// 密码private String password;// 姓名private String name;// 年龄private Integer age;// 性别，1男性，2女性private Integer sex;// 出生日期private Date birthday;// 创建时间private Date created;// 更新时间private Date updated;// 备注private String note;}

controller

@RestController@RequestMapping("/consumer")public class ConsumerController {@Autowiredprivate RestTemplate restTemplate;@GetMapping("/{id}")public User queryById(@PathVariable Long id){String url = "http://localhost:9091/user/" + id;return restTemplate.getForObject(url, User.class);}}

4.3.3.启动测试：

因为我们没有配置端口，那么默认就是8080，我们访问：http://localhost:8080/consume/7

一个简单的远程服务调用案例就实现了。

4.4.思考问题

简单回顾一下，刚才我们写了什么：

user-service：对外提供了查询用户的接口

consumer-demo：通过RestTemplate访问 http://locahost:9091/user/{id} 接口，查询用户数据

存在什么问题？

在consumer中，我们把url地址硬编码到了代码中，不方便后期维护

consumer需要记忆user-service的地址，如果出现变更，可能得不到通知，地址将失效

consumer不清楚user-service的状态，服务宕机也不知道

user-service只有1台服务，不具备高可用性

即便user-service形成集群，consumer还需自己实现负载均衡

以上的问题，我们都将在SpringCloud中得到答案。

6.Eureka注册中心

6.1.Eureka简介

问题分析

在刚才的案例中，user-service对外提供服务，需要对外暴露自己的地址。而consumer（调用者）需要记录服务提供者的地址。将来地址出现变更，还需要及时更新。这在服务较少的时候并不觉得有什么，但是在现在日益复杂的互联网环境，一个项目肯定会拆分出十几，甚至数十个微服务。此时如果还人为管理地址，不仅开发困难，将来测试、发布上线都会非常麻烦，

这就好比是网约车出现以前，人们出门叫车只能叫出租车。一些私家车想做出租却没有资格，被称为黑车。而很多

人想要约车，但是无奈出租车太少，不方便。私家车很多却不敢拦，而且满大街的车，谁知道哪个才是愿意载人

的。一个想要，一个愿意给，就是缺少引子，缺乏管理啊。

此时滴滴这样的网约车平台出现了，所有想载客的私家车全部到滴滴注册，记录你的车型（服务类型），身份信息（联系方式）。这样提供服务的私家车，在滴滴那里都能找到，一目了然。此时要叫车的人，只需要打开APP，输入你的目的地，选择车型（服务类型），滴滴自动安排一个符合需求的车到你面前，为你服务，完美！

Eureka做什么？

Eureka就好比是滴滴，负责管理、记录服务提供者的信息。服务调用者无需自己寻找服务，而是把自己的需求告诉Eureka，然后Eureka会把符合你需求的服务告诉你。

同时，服务提供方与Eureka之间通过 “心跳” 机制进行监控，当某个服务提供方出现问题，Eureka自然会把它从服务列表中剔除。

这就实现了服务的自动注册、发现、状态监控。

6.2.原理图

基本架构：

Eureka：就是服务注册中心（可以是一个集群），对外暴露自己的地址

提供者：启动后向Eureka注册自己信息（地址，提供什么服务）

消费者：向Eureka订阅服务，Eureka会将对应服务的所有提供者地址列表发送给消费者，并且定期更新

心跳(续约)：提供者定期通过http方式向Eureka刷新自己的状态

工作原理图解析

6.3.入门案例

6.3.1.编写EurekaServer

Eureka是服务注册中心，只做服务注册；自身并不提供服务也不消费服务。可以搭建Web工程使用Eureka，可以使用Spring Boot方式搭建。

1. pom.xml

<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0http://maven.apache.org/xsd/maven-4.0.0.xsd"><parent><artifactId>lxs-springcloud</artifactId><groupId>com.lxs</groupId><version>1.0-SNAPSHOT</version></parent><modelVersion>4.0.0</modelVersion><artifactId>eureka-server</artifactId><dependencies><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-eureka-server</artifactId></dependency></dependencies></project>

2. 编写启动类：

//声明当前应用时Eureka服务@EnableEurekaServer@SpringBootApplicationpublic class EurekaServerApplication {public static void main(String[] args) {SpringApplication.run(EurekaServerApplication.class, args);}}

3. 编写配置：

server:port: 10086spring:application:name: eureka-servereureka:client:service-url:# eureka 服务地址，如果是集群的话；需要指定其它集群eureka地址defaultZone: http://127.0.0.1:10086/eureka# 不注册自己register-with-eureka: false# 不拉取服务fetch-registry: false

4. 启动服务，并访问：http://127.0.0.1:10086/

6.3.2. 服务注册

在服务提供工程user-service上添加Eureka客户端依赖；自动将服务注册到EurekaServer服务地址列表。

1. 添加依赖

<!-- Eureka客户端 --><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-eureka-client</artifactId></dependency>

2. 在启动类上开启Eureka客户端功能

通过添加 @EnableDiscoveryClient 来开启Eureka客户端功能

@SpringBootApplication@MapperScan("com.zx.mapper")@EnableDiscoveryClient //开启Eureka客户端发现功能public class UserApplication {public static void main(String[] args) {SpringApplication.run(UserApplication.class, args);}}

3. 编写配置

server:port: 9091spring:datasource:driver-class-name: com.mysql.jdbc.Driverurl: jdbc:mysql://localhost:3306/springcloudusername: rootpassword: rootapplication:name: user-servicemybatis:type-aliases-package: com.zx.beaneureka:client:service-url:defaultZone: http://127.0.0.1:10086/eureka

注意：

这里我们添加了spring.application.name属性来指定应用名称，将来会作为应用的id使用。

不用指定register-with-eureka和fetch-registry，因为默认是true

重启项目，访问Eureka监控页面查看

localhost:10086/

我们发现user-service服务已经注册成功了

6.3.3. 服务发现

在服务消费工程consumer-demo上添加Eureka客户端依赖；可以使用工具类DiscoveryClient根据服务名称获取对

应的服务地址列表。

1）添加依赖：

<!-- Eureka客户端 -->
<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-eureka-client</artifactId></dependency>

2）在启动类添加开启Eureka客户端发现的注解

@SpringBootApplication@EnableDiscoveryClient // 开启Eureka客户端public class UserConsumerDemoApplication {@Beanpublic RestTemplate restTemplate() {return new RestTemplate(new Okhttp3ClienthttpRequestFactory());}public static void main(String[] args) {SpringApplication.run(UserConsumerDemoApplication.class, args);}}

3）修改配置：

 
spring:application:name: consumer-demoeureka:client:service-url:defaultZone: http://127.0.0.1:10086/eureka

4）修改代码，用DiscoveryClient类的方法，根据服务名称，获取服务实例：

@RestController@RequestMapping("/consumer")public class ConsumerController {@Autowiredprivate RestTemplate restTemplate;@Autowiredprivate DiscoveryClient discoveryClient;@GetMapping("/{id}")public User queryById(@PathVariable("id") Long id) {List<ServiceInstance> serviceInstances = discoveryClient.getInstances("user-service");ServiceInstance serviceInstance = serviceInstances.get(0);url = "http://" + serviceInstance.getHost() + ":" + serviceInstance.getPort() + "/user/"+ id;return restTemplate.getForObject(url, User.class);}}

5）Debug跟踪运行：

生成的URL：

访问结果：

6.4.Eureka详解

接下来我们详细讲解Eureka的原理及配置。

6.4.1.基础架构

Eureka架构中的三个核心角色：

服务注册中心

Eureka的服务端应用，提供服务注册和发现功能，就是刚刚我们建立的eureka-server

服务提供者

提供服务的应用，可以是Spring Boot应用，也可以是其它任意技术实现，只要对外提供的是REST风格服务即可。本例中就是我们实现的user-service

服务消费者

消费应用从注册中心获取服务列表，从而得知每个服务方的信息，知道去哪里调用服务方。本例中就是我们实现的consumer-demo

6.4.2.高可用的Eureka Server

Eureka Server即服务的 注册中心，在刚才的案例中，我们只有一个EurekaServer，事实上EurekaServer 也可以是一个集群，形成高可用的Eureka中心。

Eureka Server是一个web应用，可以启动多个实例（配置不同端口）保证Eureka Server的高可用

服务同步

多个Eureka Server之间也会互相注册为服务，当服务提供者注册到Eureka Server集群中的某个节点时，该节点会把服务的信息同步给集群中的每个节点，从而实现数据同步。因此，无论客户端访问到Eureka Server集群中的任意一个节点，都可以获取到完整的服务列表信息。而作为客户端，需要把信息注册到每个Eureka中

如果有三个Eureka，则每一个EurekaServer都需要注册到其它几个Eureka服务中。

例如：有三个分别为10086、10087、10088，则：

10086要注册到10087和10088上

10087要注册到10086和10088上

10088要注册到10086和10087上

动手搭建高可用的EurekaServer

我们假设要搭建两条EurekaServer的集群，端口分别为：10086和10087

1）我们修改原来的EurekaServer配置：

里面的${XX} : 含义如果没有port,那么使用默认的10086端口,如果有,就是指定的端口

server:port: ${port:10086}spring:application:name: eureka-servereureka:client:#eureka的服务地址，如果是集群，需要指定其他集群eureka地址service-url:defaultZone: ${defaultZone:http://127.0.0.1:10086/eureka}

所谓的高可用注册中心，其实就是把EurekaServer自己也作为一个服务进行注册，这样多个EurekaServer之间就能互相发现对方，从而形成集群。

因此我们做了以下修改：

删除了register-with-eureka=false和fetch-registry=false两个配置。因为默认值是true，这样就会吧自己注册到注册中心了。

把service-url的值改成了另外一台EurekaServer的地址，而不是自己

2）另外一台在启动的时候可以指定端口port和defaultZone配置：

修改原来的启动配置组件；

在如下界面中的 VM options 中设置 -DdefaultZone=http:127.0.0.1:10087/eureka 复制一份并修改；在如下界面中的 VM options 中设置

-Dport=10087 -DdefaultZone=http:127.0.0.1:10086/eureka

-Dport=10086 -DdefaultZone=http:127.0.0.1:10087/eureka

3）启动测试；同时启动两台eureka server

4）客户端注册服务到集群

因为EurekaServer不止一个，因此注册服务的时候，service-url参数需要变化：

eureka:client:service-url: 
# EurekaServer地址,多个地址以','隔开defaultZone: http://127.0.0.1:10086/eureka,http://127.0.0.1:10087/eureka

为了方便后面内容的修改，在测试完上述配置后可以再次改回单个eureka server的方式。

6.4.3.Eureka客户端和服务端配置

这个小节我们进行一系列的配置：

Eureka客户端工程

user-service 服务提供

服务地址使用ip方式

续约

consumer-demo 服务消费

获取服务地址的频率

Eureka服务端工程 eureka-server

失效剔除

自我保护

服务提供者要向EurekaServer注册服务，并且完成服务续约等工作。

服务注册

服务提供者在启动时，会检测配置属性中的： eureka.client.register-with-erueka=true 参数是否为true，事实上默认就是true。如果值确实为true，则会向EurekaServer发起一个Rest请求，并携带自己的元数据信息，

EurekaServer会把这些信息保存到一个双层Map结构中。

第一层Map的Key就是服务id，一般是配置中的 spring.application.name 属性, 例如:user-service

第二层Map的key是服务的实例id。一般host+ serviceId + port，例如： localhost:user-service:8081

值则是服务的实例对象，也就是说一个服务，这样可以同时启动多个不同实例，形成集群。默认注册时使用的是主机名或者localhost，如果想用ip进行注册，可以在 user-service 中添加配置如下：

 
eureka:instance:ip-address: 127.0.0.1 # ip地址prefer-ip-address: true # 更倾向于使用ip，而不是host名

修改完后先后重启 user-service 和 consumer-demo ；在调用服务的时候就已经变成ip地址；

服务续约

在注册服务完成以后，服务提供者会维持一个心跳（定时向EurekaServer发起Rest请求），告诉

EurekaServer：“我还活着”。这个我们称为服务的续约（renew）；

有两个重要参数可以修改服务续约的行为；可以在 user-service 中添加如下配置项：

eureka:instance:lease-expiration-duration-in-seconds: 90lease-renewal-interval-in-seconds: 30

lease-renewal-interval-in-seconds：服务续约(renew)的间隔，默认为30秒

lease-expiration-duration-in-seconds：服务失效时间，默认值90秒

也就是说，默认情况下每个30秒服务会向注册中心发送一次心跳，证明自己还活着。如果超过90秒没有发送心

跳，EurekaServer就会认为该服务宕机，会从服务列表中移除，这两个值在生产环境不要修改，默认即可。

获取服务列表

当服务消费者启动时，会检测 eureka.client.fetch-registry=true 参数的值，如果为true，则会从Eureka Server服务的列表拉取只读备份，然后缓存在本地。并且每隔30秒会重新拉取并更新数据。可以在 consumer-demo 项目中通过下面的参数来修改：

eureka:client:registry-fetch-interval-seconds: 30

生产环境中，我们不需要修改这个值。但是为了开发环境下，能够快速得到服务的最新状态，我们可以将其设置小一点。

6.4.5.失效剔除和自我保护

如下的配置都是在Eureka Server服务端进行：

服务下线

当服务进行正常关闭操作时，它会触发一个服务下线的REST请求给Eureka Server，告诉服务注册中心：“我要下线

了”。服务中心接受到请求之后，将该服务置为下线状态

失效剔除

有时我们的服务可能由于内存溢出或网络故障等原因使得服务不能正常的工作，而服务注册中心并未收到“服务下

线”的请求。相对于服务提供者的“服务续约”操作，服务注册中心在启动时会创建一个定时任务，默认每隔一段时间

（默认为60秒）将当前清单中超时（默认为90秒）没有续约的服务剔除，这个操作被称为失效剔除。可以通过

eureka.server.eviction-interval-timer-in-ms 参数对其进行修改，单位是毫秒。

自我保护

我们关停一个服务，就会在Eureka面板看到一条警告：

这是触发了Eureka的自我保护机制。当一个服务未按时进行心跳续约时，Eureka会统计最近15分钟心跳失败的服务实例的比例是否超过了85%，

当EurekaServer节点在短时间内丢失过多客户端（可能发生了网络分区故障）。在

生产环境下，因为网络延迟等原因，心跳失败实例的比例很有可能超标，但是此时就把服务剔除列表并不妥当

，因为服务可能没有宕机。Eureka就会把当前实例的注册信息保护起来，不予剔除。生产环境下这很有效，保证了大多数服务依然可用。

但是这给我们的开发带来了麻烦， 因此开发阶段我们都会关闭自我保护模式：

eureka:server:enable-self-preservation: false # 关闭自我保护模式（缺省为打开）eviction-interval-timer-in-ms: 1000 # 扫描失效服务的间隔时间（缺省为60*1000ms）

7.负载均衡Ribbon

在刚才的案例中，我们启动了一个user-service，然后通过DiscoveryClient来获取服务实例信息，然后获取ip和端口来访问。

但是实际环境中，我们往往会开启很多个user-service的集群。此时我们获取的服务列表中就会有多个，到底该访问哪一个呢？

一般这种情况下我们就需要编写负载均衡算法，在多个实例列表中进行选择。不过Eureka中已经帮我们集成了负载均衡组件：Ribbon，简单修改代码即可使用。

什么是Ribbon：

接下来，我们就来使用Ribbon实现负载均衡。

7.1.启动两个服务实例

首先我们启动两个user-service实例，一个9091，一个9092。

在user-service中配置如下端口：

server:port: ${port:9091}

Eureka监控面板：

7.2.开启负载均衡

因为Eureka中已经集成了Ribbon，所以我们无需引入新的依赖。直接修改代码：

在RestTemplate的配置方法上添加 @LoadBalanced 注解：

@Bean@LoadBalancedpublic RestTemplate restTemplate() {return new RestTemplate();}

修改调用方式，不再手动获取ip和端口，而是直接通过服务名称调用：访问页面，查看结果：

@GetMapping("/{id}")public User queryById(@PathVariable("id") Long id) {String url = "http://user-service/user/" + id;return restTemplate.getForObject(url, User.class);}

访问页面，查看结果；并可以在9091和9092的控制台查看执行情况：

7.3.源码跟踪

为什么只输入了service名称就可以访问了呢？之前还要获取ip和端口。

显然是有组件根据service名称，获取到了服务实例的ip和端口。因为 consumer-demo 使用的是RestTemplate，

spring使用LoadBalancerInterceptor拦截器，这个类会在对RestTemplate的请求进行拦截，然后从Eureka根据服务id获取服务列表，随后利用负载均衡算法得到真实的服务地址信息，替换服务id。

我们进行源码跟踪：

继续跟入execute方法：发现获取了9092端口的服务

再跟下一次，发现获取的是9092：

7.4.负载均衡策略

Ribbon默认的负载均衡策略是简单的轮询，我们可以测试一下：

编写测试类，在刚才的源码中我们看到拦截中是使用RibbonLoadBalanceClient来进行负载均衡的，其中有一个

choose方法，是这样介绍的：

现在这个就是负载均衡获取实例的方法。

我们对注入这个类的对象，然后对其测试：

@RunWith(SpringRunner.class)@SpringBootTest(classes = UserConsumerDemoApplication.class)public class LoadBalanceTest {@AutowiredRibbonLoadBalancerClient client;@Testpublic void test(){for (int i = 0; i < 100; i++) {ServiceInstance instance = this.client.choose("user-service");System.out.println(instance.getHost() + ":" + instance.getPort());}}}

结果：

符合了我们的预期推测，确实是轮询方式。

SpringBoot也帮我们提供了修改负载均衡规则的配置入口：

user-service:ribbon:NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

格式是：

{服务名称}:

ribbon:

NFLoadBalancerRuleClassName :XXXXX，

再次测试，发现结果变成了随机：

8.Hystrix(豪猪)

8.1.简介

主页：https://github.com/Netﬂix/Hystrix/

Hystix是Netﬂix开源的一个延迟和容错库，用于隔离访问远程服务，防止出现级联失败。

8.2.雪崩问题

微服务中，服务间调用关系错综复杂，一个请求，可能需要调用多个微服务接口才能实现，会形成非常复杂的调用

链路：

如图，一次业务请求，需要调用A、P、H、I四个服务，这四个服务又可能调用其它服务。如果此时，某个服务出现异常：

例如：微服务I 发生异常，请求阻塞，用户请求就不会得到响应，则tomcat的这个线程不会释放，于是越来越多的

用户请求到来，越来越多的线程会阻塞：

服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，形成

雪崩效应。

这就好比，一个汽车生产线，生产不同的汽车，需要使用不同的零件，如果某个零件因为种种原因无法使用，那么

就会造成整台车无法装配，陷入等待零件的状态，直到零件到位，才能继续组装。此时如果有很多个车型都需要这

个零件，那么整个工厂都将陷入等待的状态，导致所有生产都陷入瘫痪。一个零件的波及范围不断扩大

Hystrix解决雪崩问题的手段，主要包括：

线程隔离

服务降级

8.3. 线程隔离&服务降级

8.3.1原理

线程隔离示意图

解读：

Hystrix为每个依赖服务调用分配一个小的线程池，如果线程池已满调用将被立即拒绝，默认不采用排队，加速失败判定时间。

用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池已满，或者请求超时，则会进行降级处理，

什么是服务降级？

服务降级：可以优先保证核心服务。

用户的请求故障时，不会被阻塞，更不会无休止的等待或者看到系统崩溃，至少可以看到一个执行结果（例如返回友好的提示信息） 。

触发Hystrix服务降级的情况：

线程池已满

请求超时

8.3.2.动手实践

服务降级：及时返回服务调用失败的结果，让线程不因为等待服务而阻塞

1) 引入依赖

在 consumer-demo 消费端系统的pom.xml文件添加如下依赖：

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

2) 开启熔断

在启动类 ConsumerApplication 上添加注解：@EnableCircuitBreaker

@SpringBootApplication@EnableDiscoveryClient@EnableCircuitBreakerpublic class ConsumerApplication {// ...}

可以看到，我们类上的注解越来越多，在微服务中，经常会引入上面的三个注解，于是Spring就提供了一个组合注解：@SpringCloudApplication

因此，我们可以使用这个组合注解来代替之前的3个注解：

@SpringCloudApplicationpublic class ConsumerApplication {// ...}

3) 编写降级逻辑

当目标服务的调用出现故障，我们希望快速失败，给用户一个友好提示。因此需要提前编写好失败时的降级处理逻辑，要使用HystrixCommand来完成。

改造 consumer-demo\src\main\java\zx\com\consumer\controller\ConsumerController.java 处理器类，如下：

@RestController@RequestMapping("/consumer")@Slf4jpublic class ConsumerController {@Autowiredprivate RestTemplate restTemplate;@Autowiredprivate DiscoveryClient discoveryClient;@GetMapping("{id}")@HystrixCommand(fallbackMethod = "queryByIdFallback")public String queryById(@PathVariable Long id) {String url = "http://user-service/user/" + id;return restTemplate.getForObject(url, String.class);}public String queryByIdFallback(Long id) {log.error("查询用户信息失败。id：{}", id);return "对不起，网络太拥挤了！";}}

要注意；因为熔断的降级逻辑方法必须跟正常逻辑方法保证：相同的参数列表和返回值声明。失败逻辑中返回User对象没有太大意义，一般会返回友好提示。所以把queryById的方法改造为返回String，反正也是Json数据。这样失败逻辑中返回一个错误说明，会比较方便。

说明：

@HystrixCommand(fallbackMethod = "queryByIdFallBack")：用来声明一个降级逻辑的方法

测试：

当 user-service 正常提供服务时，访问与以前一致。但是当将 user-service 停机时，会发现页面返回了降级处理信息：

4) 默认的fallback

刚才把fallback写在了某个业务方法上，如果这样的方法很多，那岂不是要写很多。所以可以把Fallback配置加在

类上，实现默认fallback；再次改造 consumer-

demo\src\main\java\com\lxs\consumer\controller\ConsumerController.java

@RestController@RequestMapping("/consumer")@Slf4j@DefaultProperties(defaultFallback = "defaultFallback")public class ConsumerController {@Autowiredprivate RestTemplate restTemplate;@Autowiredprivate DiscoveryClient discoveryClient;@GetMapping("{id}")//@HystrixCommand(fallbackMethod = "queryByIdFallback")@HystrixCommandpublic String queryById(@PathVariable Long id) {String url = "http://user-service/user/" + id;return restTemplate.getForObject(url, String.class);}public String queryByIdFallback(Long id) {log.error("查询用户信息失败。id：{}", id);return "对不起，网络太拥挤了！";}public String defaultFallback() {return "默认提示：对不起，网络太拥挤了！";}}

@DefaultProperties(defaultFallback = "defaultFallBack")：在类上指明统一的失败降级方法；该类中所有方法返回类型要与处理失败的方法的返回类型一致。

5) 超时设置

在之前的案例中，请求在超过1秒后都会返回错误信息，这是因为Hystrix的默认超时时长为1，我们可以通过配置

修改这个值；修改 consumer-demo\src\main\resources\application.yml 添加如下配置：

hystrix:command:default:execution:isolation:thread:timeoutInMilliseconds: 2000

这个配置会作用于全局所有方法。为了方便复制到yml配置文件中，可以复制

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=2000 到yml文件中会自动格式化后再进行修改。

为了触发超时，可以在 user-service\src\main\java\com\lxs\user\service\UserService.java 的方法中休眠2秒；

@RequestMapping("/{id}")public User queryById(@PathVariable("id") Long id) {try {Thread.sleep(2000);} catch (InterruptedException e) {e.printStackTrace();}return userService.queryById(id);}

测试：

可以发现，请求的时长已经到了2s+，证明配置生效了。如果把修改时间修改到2秒以下，又可以正常访问。

8.4 服务熔断

8.4.1熔断原理

在服务熔断中，使用的熔断器，也叫断路器，其英文单词为：Circuit Breaker 熔断机制与家里使用的电路熔断原理类似；

当如果电路发生短路的时候能立刻熔断电路，避免发生灾难。在分布式系统中应用服务熔断后；服务调用方可以自己进行判断哪些服务反应慢或存在大量超时，可以针对这些服务进行主动熔断，防止整个系统被拖垮。Hystrix的服务熔断机制，可以实现弹性容错；当服务请求情况好转之后，可以自动重连。通过断路的方式，将后续请求直接拒绝，一段时间（默认5秒）之后允许部分请求通过，如果调用成功则回到断路器关闭状态，否则继续打开，拒绝请求的服务。

Hystrix的熔断状态机模型：

状态机有3个状态：

Closed：关闭状态（断路器关闭），所有请求都正常访问。

Open：打开状态（断路器打开），所有请求都会被降级。Hystrix会对请求情况计数，当一定时间内失败请求百分比达到阈值，则触发熔断，断路器会完全打开。默认失败比例的阈值是50%，请求次数最少不低于20次。

Half Open：半开状态，不是永久的，断路器打开后会进入休眠时间（默认是5S）。随后断路器会自动进入半开状态。此时会释放部分请求通过，若这些请求都是健康的，则会关闭断路器，否则继续保持打开，再次进行休眠计时

分析图：

8.4.2动手实践

为了能够精确控制请求的成功或失败，在 consumer-demo 的处理器业务方法中加入一段逻辑；

修改 consumer-demo\src\main\java\com\lxs\consumer\controller\ConsumerController.java

@GetMapping("{id}")@HystrixCommandpublic String queryById(@PathVariable Long id) {if (id == 1) {throw new RuntimeException("太忙了");}String url = "http://user-service/user/" + id;String user = restTemplate.getForObject(url, String.class);return user;}

这样如果参数是id为1，一定失败，其它情况都成功。（不要忘了清空user-service中的休眠逻辑）

我们准备两个请求窗口：

一个请求：http://localhost:8080/consumer/1，注定失败

一个请求：http://localhost:8080/consumer/2，肯定成功

当我们疯狂访问id为1的请求时（超过20次），就会触发熔断。断路器会打开，一切请求都会被降级处理。

此时你访问id为2的请求，会发现返回的也是失败，而且失败时间很短，只有20毫秒左右；因进入半开状态之后2是可以的。

不过，默认的熔断触发要求较高，休眠时间窗较短，为了测试方便，我们可以通过配置修改熔断策略：

hystrix:

command:

default:

execution:

isolation:

thread:

timeoutInMilliseconds: 2000 #服务降级超时时间

circuitBreaker:

errorThresholdPercentage: 50 # 触发熔断错误比例阈值，默认值50%

sleepWindowInMilliseconds: 10000 # 熔断后休眠时长，默认值5秒

requestVolumeThreshold: 10 # 熔断触发最小请求次数，默认值是20

9.Feign

在前面的学习中，我们使用了Ribbon的负载均衡功能，大大简化了远程调用时的代码：

如果就学到这里，你可能以后需要编写类似的大量重复代码，格式基本相同，无非参数不一样。有没有更优雅的方式，来对这些代码再次优化呢？这就是我们接下来要学的Feign的功能了。

2.1.简介

为什么叫伪装？

Feign可以把Rest的请求进行隐藏，伪装成类似SpringMVC的Controller一样。你不用再自己拼接url，拼接参数等操作，一切都交给Feign去做。

项目主页： https://github.com/OpenFeign/feign

2.2.快速入门

2.2.1.导入依赖

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

2.2.2.Feign的客户端

@FeignClient("user-service")public interface UserClient {//http://user-service/user/123@GetMapping("/user/{id}")User queryById(@PathVariable("id") Long id);}

首先这是一个接口，Feign会通过动态代理，帮我们生成实现类。这点跟Mybatis的mapper很像

@FeignClient ，声明这是一个Feign客户端，同时通过 value 属性指定服务名称接口中的定义方法，完全采用SpringMVC的注解，Feign会根据注解帮我们生成URL，并访问获取结果

@GetMapping中的/user，请不要忘记；因为Feign需要拼接可访问的地址编写新的控制器类 ConsumerFeignController ，使用UserClient访问：

@RestController@RequestMapping("/cf")public class ConsumerFeignController {@Autowiredprivate UserClient userClient;@GetMapping("/{id}")public User queryById(@PathVariable Long id){return userClient.queryById(id);}}

2.2.3.开启Feign功能在 ConsumerApplication 启动类上，添加注解，开启Feign功能

 
@SpringCloudApplication@EnableFeignClients //开启feign功能public class ConsumerApplication {public static void main(String[] args) {SpringApplication.run(ConsumerApplication.class, args);}@Bean@LoadBalancedpublic RestTemplate restTemplate() {return new RestTemplate();}}

Feign中已经自动集成了Ribbon负载均衡，因此不需要自己定义RestTemplate进行负载均衡的配置。

2.2.4.启动测试：

访问接口：http://localhost:8080/cf/2

正常获取到了结果。

2.3.负载均衡

Feign中本身已经集成了Ribbon依赖和自动配置：

因此不需要额外引入依赖，也不需要再注册 RestTemplate 对象。

Fegin内置的ribbon默认设置了请求超时时长，默认是1000，我们可以通过手动配置来修改这个超时时长：

ribbon:ReadTimeout: 2000 # 读取超时时长ConnectTimeout: 1000 # 建立链接的超时时长

或者为某一个具体service指定

user-service   ribbon:ReadTimeout: 2000 # 读取超时时长ConnectTimeout: 1000 # 建立链接的超时时长

在user-service中增加睡眠时间2s测试因为ribbon内部有重试机制，一旦超时，会自动重新发起请求。如果不希望重试，可以添加配置：

修改 consumer-demo\src\main\resources\application.yml 添加如下配置：

ribbon:ConnectTimeout: 1000 # 连接超时时长ReadTimeout: 2000 # 数据通信超时时长MaxAutoRetries: 0 # 当前服务器的重试次数MaxAutoRetriesNextServer: 0 # 重试多少次服务OkToRetryOnAllOperations: false # 是否对所有的请求方式都重试

2.4.Hystrix支持

Feign默认也有对Hystrix的集成：

只不过，默认情况下是关闭的。需要通过下面的参数来开启：

0)修改 consumer-demo\src\main\resources\application.yml 添加如下配置：

feign:hystrix:enabled: true # 开启Feign的熔断功能

但是，Feign中的Fallback配置不像Ribbon中那样简单了。

1）首先，要定义一个类，实现刚才编写的UserFeignClient，作为fallback的处理类

package com.lxs.consumer.client.fallback;import com.lxs.consumer.client.UserClient;import com.lxs.consumer.pojo.User;import org.springframework.stereotype.Component;@Componentpublic class UserClientFallback implements UserClient {@Overridepublic User queryById(Long id) {User user = new User();user.setId(id);user.setName("用户异常");return user;}}

2）然后在UserClient中，指定刚才编写的实现类

@FeignClient(value = "user-service", fallback = UserFeignClientFallback.class)public interface UserFeignClient {@GetMapping("/user/{id}")User queryUserById(@PathVariable("id") Long id);}

3）重启测试：

重启启动 consumer-demo 并关闭 user-service 服务，然后在页面访问：http://localhost:8080/cf/7

2.5.请求压缩(了解)

Spring Cloud Feign 支持对请求和响应进行GZIP压缩，以减少通信过程中的性能损耗。通过下面的参数即可开启请

求与响应的压缩功能：

feign:compression:request:enabled: true # 开启请求压缩response:enabled: true # 开启响应压缩

同时，我们也可以对请求的数据类型，以及触发压缩的大小下限进行设置：

feign:compression:request:enabled: true # 开启请求压缩mime-types: text/html,application/xml,application/json # 设置压缩的数据类型min-request-size: 2048 # 设置触发压缩的大小下限

注：上面的数据类型、压缩大小下限均为默认值。

2.6.日志级别(了解)

前面讲过，通过 logging.level.lxs.xx=debug 来设置日志级别。然而这个对Fegin客户端而言不会产生效果。因为

@FeignClient 注解修改的客户端在被代理时，都会创建一个新的Fegin.Logger实例。我们需要额外指定这个日志的

级别才可以。

1）在 consumer-demo 的配置文件中设置com.zx包下的日志级别都为 debug

修改 consumer-demo\src\main\resources\application.yml 添加如下配置：

logging:level:com.zx: debug

2）编写配置类，定义日志级别

package com.lxs.consumer.config;import feign.Logger;import org.springframework.context.annotation.Bean;import org.springframework.context.annotation.Configuration;@Configurationpublic class FeignConfig {@BeanLogger.Level feignLoggerLevel(){//记录所有请求和响应的明细，包括头信息、请求体、元数据return Logger.Level.FULL;}}

这里指定的Level级别是FULL，Feign支持4种级别：

NONE：不记录任何日志信息，这是默认值。

BASIC：仅记录请求的方法，URL以及响应状态码和执行时间

HEADERS：在BASIC的基础上，额外记录了请求和响应的头信息

FULL：记录所有请求和响应的明细，包括头信息、请求体、元数据。

3）在 consumer-demo 的 UserClient 接口类上的@FeignClient注解中指定配置类：

别忘了去掉user-service的休眠时间

@FeignClient(value = "user-service", fallback = UserClientFallback.class, configuration =FeignConfig.class)public interface UserClient {@GetMapping("/user/{id}")User queryById(@PathVariable("id") Long id);}

4）重启项目，即可看到每次访问的日志：

10. Spring Cloud Gateway网关

10.1. 简介

Spring Cloud Gateway是Spring官网基于Spring 5.0、 Spring Boot 2.0、Project Reactor等技术开发的网关服务。

Spring Cloud Gateway基于Filter链提供网关基本功能：安全、监控／埋点、限流等。

Spring Cloud Gateway为微服务架构提供简单、有效且统一的API路由管理方式。

Spring Cloud Gateway是替代Netﬂix Zuul的一套解决方案。

Spring Cloud Gateway组件的核心是一系列的过滤器，通过这些过滤器可以将客户端发送的请求转发（路由）到对应的微服务。 Spring Cloud Gateway是加在整个微服务最前沿的防火墙和代理器，隐藏微服务结点IP端口信息，从而加强安全保护。 Spring Cloud Gateway本身也是一个微服务，需要注册到Eureka服务注册中心。

网关的核心功能是：过滤和路由

10.2 Gateway加入后的架构

不管是来自于客户端（PC或移动端）的请求，还是服务内部调用。一切对服务的请求都可经过网关，然后再由网关来实现鉴权、动态路由等等操作。Gateway就是我们服务的统一入口。

10.3. 核心概念

route路由

路由信息的组成：由一个ID、一个目的URL、一组断言工厂、一组Filter组成。如果路由断言为真，说明请求URL和配置路由匹配。

Predicate断言

Spring Cloud Gateway中的断言函数输入类型是Spring 5.0框架中的ServerWebExchange。Spring Cloud Gateway的断言函数允许开发者去定义匹配来自于http Request中的任何信息比如请求头和参数。

过滤器Filter

一个标准的Spring WebFilter。 Spring Cloud Gateway中的Filter分为两种类型的Filter，分别是Gateway Filter和Global Filter。过滤器Filter将会对请求和响应进行修改处理

10.4. 快速入门

需求：通过网关系统lxs-gateway将包含有 /user 的请求路由到 http://127.0.0.1:9091/user/id

10.4.1. 新建工程

打开父类-springcloud\zx-gateway\pom.xml 文件修改为如下：

<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><parent><artifactId>lxs-springcloud</artifactId><groupId>com.zx</groupId><version>1.0-SNAPSHOT</version></parent><modelVersion>4.0.0</modelVersion><artifactId>zx-gateway</artifactId><dependencies><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-gateway</artifactId></dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-eureka-client</artifactId></dependency></dependencies></project>

10.4.2. 编写启动类

在zx-gateway中创建 com.zx.gateway.GatewayApplication 启动类

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

10.4.2. 编写配置

创建 zx-gateway\src\main\resources\application.yml 文件，内容如下：

server:port: 10010spring:application:name: api-gatewayeureka:client:service-url:defaultZone: http://127.0.0.1:10086/eurekainstance:prefer-ip-address: true

需要用网关来代理 user-service 服务，先看一下控制面板中的服务状态：

ip为：127.0.0.1

端口为：9091

修改 zx-gateway\src\main\resources\application.yml 文件为：

server: port: 10010

spring:application:name: api-gatewaycloud:gateway:routes:# 路由id，可以随意写- id: user-service-route# 代理的服务地址uri: http://127.0.0.1:9091# 路由断言，可以配置映射路径predicates:- Path=/user/**eureka:client:service-url:defaultZone: http://127.0.0.1:10086/eurekainstance:prefer-ip-address: true

将符合 Path uri 参数指定的地址本例中，我们将路径中包含有 /user/** 开头的请求，代理到http://127.0.0.1:9091

10.4.5. 启动测试

访问的路径中需要加上配置规则的映射路径，我们访问：http://localhost:10010/user/7

http://localhost:10010/user/7 ----> http://localhost:9091/user/7

10.5. 面向服务的路由

在刚才的路由规则中，把路径对应的服务地址写死了！如果同一服务有多个实例的话，这样做显然不合理。应该根据服务的名称，去Eureka注册中心查找 服务对应的所有实例列表，然后进行动态路由！

10.5.1. 修改映射配置，通过服务名称获取

修改 zx-gateway\src\main\resources\application.yml 文件如下：

server:port: 10010spring:application:name: api-gatewaycloud:gateway:routes:# 路由id，可以随意写- id: user-service-route# 代理的服务地址uri: lb://user-service# 路由断言，可以配置映射路径predicates:- Path=/user/**eureka:client:service-url:defaultZone: http://127.0.0.1:10086/eurekainstance:prefer-ip-address: true

路由配置中uri所用的协议为 lb 时（以uri: lb://user-service为例），gateway将使用 LoadBalancerClient把user-service通过eureka解析为实际的主机和端口，并进行ribbon负载均衡。

10.5.2. 启动测试

zx-gateway 进行代理时，会利用Ribbon进行负载均衡访问： http://localhost:10010/user/8 日志中可以看到使用了负载均衡器：

10.6. 路由前缀

客户端的请求地址与微服务的服务地址如果不一致的时候，可以通过配置路径过滤器实现路径前缀的添加和

去除。

提供服务的地址：http://127.0.0.1:9091/user/8

添加前缀：对请求地址添加前缀路径之后再作为代理的服务地址；

http://127.0.0.1:10010/8 --> http://127.0.0.1:9091/user/8 添加前缀路径/user

去除前缀：将请求地址中路径去除一些前缀路径之后再作为代理的服务地址；

http://127.0.0.1:10010/api/user/8 --> http://127.0.0.1:9091/user/8 去除前缀路径/api

10.6.1. 添加前缀

在gateway中可以通过配置路由的过滤器PreﬁxPath，实现映射路径中地址的添加；

修改 zx-gateway\src\main\resources\application.yml 文件：

server:port: 10010spring:application:name: api-gatewaycloud:gateway:routes:# 路由id，可以随意写- id: user-service-route# 代理的服务地址uri: lb://user-service# 路由断言，可以配置映射路径predicates:- Path=/**filters:# 添加请求路径的前缀- PrefixPath=/usereureka:client:service-url:defaultZone: http://127.0.0.1:10086/eurekainstance:prefer-ip-address: true

通过 PreﬁxPath=/xxx 来指定了路由要添加的前缀。也就是：

PreﬁxPath=/user
http://localhost:10010/8 -->http://localhost:9091/user/8

PreﬁxPath=/user/abc

http://localhost:10010/8 -->http://localhost:9091/user/abc/8

10.6.2. 去除前缀

在gateway中可以通过配置路由的过滤器StripPreﬁx，实现映射路径中地址的去除；

修改 zx-gateway\src\main\resources\application.yml 文件：

server:port: 10010spring:application:name: api-gatewaycloud:gateway:routes:# 路由id，可以随意写- id: user-service-route# 代理的服务地址uri: lb://user-service# 路由断言，可以配置映射路径predicates:- Path=/api/user/**filters:# 表示过滤1个路径，2表示两个路径，以此类推- StripPrefix=1eureka:client:service-url:defaultZone: http://127.0.0.1:10086/eurekainstance:prefer-ip-address: true

通过 StripPreﬁx=1 来指定了路由要去掉的前缀个数。如：路径 /api/user/1 将会被代理到 /user/1 。也就是：

StripPreﬁx=1
http://localhost:10010/api/user/8 --》http://localhost:9091/user/8

StripPreﬁx=2

http://localhost:10010/api/user/8 --》http://localhost:9091/8

10.7. 过滤器

10.7.1. 简介

Gateway作为网关的其中一个重要功能，就是实现请求的鉴权。而这个动作往往是通过网关提供的过滤器来实现的。前面的路由前缀章节中的功能也是使用过滤器实现的。

Gateway自带过滤器有几十个，常见自带过滤器有：

配置全局默认过滤器

这些自带的过滤器可以和使用路由前缀章节中的用法类似，也可以将这些过滤器配置成不只是针对某个路由；而是可以对所有路由生效，也就是配置默认过滤器：

server:port: 10010spring:application:name: api-gatewaycloud:gateway:routes:# 路由id，可以随意写- id: user-service-route# 代理的服务地址uri: lb://user-service# 路由断言，可以配置映射路径predicates:- Path=/api/user/**filters:# 表示过滤1个路径，2表示两个路径，以此类推- StripPrefix=1# 默认过滤器，对所有路由都生效default-filters:- AddResponseHeader=X-Response-Foo, Bar- AddResponseHeader=abc-myname,zxeureka:client:service-url:defaultZone: http://127.0.0.1:10086/eurekainstance:prefer-ip-address: true

上述配置后，再访问 http://localhost:10010/api/user/7 的话；那么可以从其响应中查看到如下信息：

过滤器类型：Gateway实现方式上，有两种过滤器；

局部过滤器：通过 spring.cloud.gateway.routes.ﬁlters 配置在具体路由下，只作用在当前路由上；如果配置spring.cloud.gateway.default-ﬁlters 上会对所有路由生效也算是全局的过滤器；但是这些过滤器的实现上都是要实现GatewayFilterFactory接口。

全局过滤器：不需要在配置文件中配置，作用在所有的路由上；实现 GlobalFilter 接口即可。

10.7.2. 执行生命周期

Spring Cloud Gateway 的 Filter 的生命周期也类似Spring MVC的拦截器有两个：“pre” 和 “post”。“pre”和 “post”

分别会在请求被执行前调用和被执行后调用

这里的 pre 和 post 可以通过过滤器的 GatewayFilterChain 执行ﬁlter方法前后来实现

10.7.3. 使用场景

常见的应用场景如下：

请求鉴权：一般 GatewayFilterChain 执行ﬁlter方法前，如果发现没有访问权限，直接就返回空。

异常处理：一般 GatewayFilterChain 执行ﬁlter方法后，记录异常并返回。

服务调用时长统计： GatewayFilterChain 执行ﬁlter方法前后根据时间统计。

10.8. 自定义过滤器

10.8.1. 自定义局部过滤器

需求：

在过滤器（MyParamGatewayFilterFactory）中将http://localhost:10010/api/user/8?name=zx name的

值获取到并输出到控制台；并且参数名是可变的，也就是不一定每次都是name；需要可以通过配置过滤器的时候

做到配置参数名。

在application.yml中对某个路由配置过滤器，该过滤器可以在控制台输出配置文件中指定名称的请求参数的值。

1）编写过滤器

package com.zx.gateway.filter;import org.springframework.cloud.gateway.filter.GatewayFilter;import org.springframework.cloud.gateway.filter.factory.AbstractGatewayFilterFactory;import org.springframework.http.server.reactive.ServerhttpRequest;import org.springframework.stereotype.Component;import java.util.Arrays;import java.util.List;@Componentpublic class MyParamGatewayFilterFactory extendsAbstractGatewayFilterFactory<MyParamGatewayFilterFactory.Config> {static final String PARAM_NAME = "param";public MyParamGatewayFilterFactory() {super(Config.class);}public List<String> shortcutFieldOrder() {return Arrays.asList(PARAM_NAME);}@Overridepublic GatewayFilter apply(Config config) {return (exchange, chain) -> {// http://localhost:10010/api/user/8?name=lxs   config.param ==> name//获取请求参数中param对应的参数名  的参数值ServerhttpRequest request = exchange.getRequest();if(request.getQueryParams().containsKey(config.param)){request.getQueryParams().get(config.param).forEach(value -> System.out.printf("------------局部过滤器--------%s = %s------", config.param, value));}return chain.filter(exchange);};}public static class Config{//对应在配置过滤器的时候指定的参数名private String param;public String getParam() {return param;}public void setParam(String param) {this.param = param;}}}

2）修改配置文件

server:port: 10010spring:application:name: api-gatewaycloud:gateway:routes:# 路由id，可以随意写- id: user-service-route# 代理的服务地址uri: lb://user-service# 路由断言，可以配置映射路径predicates:- Path=/api/user/**filters:# 表示过滤1个路径，2表示两个路径，以此类推- StripPrefix=1# 自定义过滤器- MyParam=name# 默认过滤器，对所有路由都生效default-filters:- AddResponseHeader=X-Response-Foo, Bar- AddResponseHeader=abc-myname,zxeureka:client:service-url:defaultZone: http://127.0.0.1:10086/eurekainstance:prefer-ip-address: true

注意：自定义过滤器的命名应该为：XXXGatewayFilterFactory

http://localhost:10010/api/user/7?name=zx；但是若访问

http://localhost:10010/api/user/7?name2=xiaoming 则是不会输出的

10.8.2. 自定义全局过滤器

需求：编写全局过滤器，在过滤器中检查请求中是否携带token请求头。如果token请求头存在则放行；如果token

为空或者不存在则设置返回的状态码为：未授权也不再执行下去。

在zx-gateway工程编写全局过滤器类MyGlobalFilter

@Componentpublic class MyGlobalFilter implements GlobalFilter, Ordered {@Overridepublic Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {System.out.println("--------------全局过滤器MyGlobalFilter------------------");String token = exchange.getRequest().getHeaders().getFirst("token");if(StringUtils.isBlank(token)){//设置响应状态码为未授权exchange.getResponse().setStatusCode(httpStatus.UNAUTHORIZED);return exchange.getResponse().setComplete();}return chain.filter(exchange);}@Overridepublic int getOrder() {//值越小越先执行return 1;}}

访问 http://localhost:10010/api/user/7

访问 http://localhost:10010/api/user/7?token=abc

10.9. 负载均衡和熔断（了解）

Gateway中默认就已经集成了Ribbon负载均衡和Hystrix熔断机制。但是所有的超时策略都是走的默认值，比如熔

断超时时间只有1S，很容易就触发了。因此建议手动进行配置：

hystrix:command:default:execution:isolation:thread:timeoutInMilliseconds: 6000 #服务降级超时时间，默认1Sribbon:ConnectTimeout: 1000 # 连接超时时长ReadTimeout: 2000 # 数据通信超时时长MaxAutoRetries: 0 # 当前服务器的重试次数MaxAutoRetriesNextServer: 0 # 重试多少次服务

10.10. Gateway跨域配置

一般网关都是所有微服务的统一入口，必然在被调用的时候会出现跨域问题。

跨域：在js请求访问中，如果访问的地址与当前服务器的域名、ip或者端口号不一致则称为跨域请求。若不解决则

不能获取到对应地址的返回结果。

如：从在http://localhost:9090 js访问 http://localhost:9000 的数据，因为端口不同，所以也是跨域请求。

在访问Spring Cloud Gateway网关服务器的时候，出现跨域问题的话；可以在网关服务器中通过配置解决，允许哪

些服务是可以跨域请求的；具体配置如下：

server:port: 10010spring:application:name: api-gatewaycloud:gateway:routes:# 路由id，可以随意写- id: user-service-route# 代理的服务地址uri: lb://user-service# 路由断言，可以配置映射路径predicates:- Path=/api/user/**filters:# 表示过滤1个路径，2表示两个路径，以此类推- StripPrefix=1# 自定义过滤器- MyParam=name# 默认过滤器，对所有路由都生效default-filters:- AddResponseHeader=X-Response-Foo, Bar- AddResponseHeader=abc-myname,zxglobalcors:corsConfigurations:'[/**]':#allowedOrigins: * # 这种写法或者下面的都可以，*表示全部allowedOrigins:- "http://docs.spring.io"allowedMethods:- GETeureka:client:service-url:defaultZone: http://127.0.0.1:10086/eurekainstance:prefer-ip-address: truehystrix:command:default:execution:isolation:thread:timeoutInMilliseconds: 6000 #服务降级超时时间，默认1Sribbon:ConnectTimeout: 1000 # 连接超时时长ReadTimeout: 2000 # 数据通信超时时长MaxAutoRetries: 0 # 当前服务器的重试次数MaxAutoRetriesNextServer: 0 # 重试多少次服务

说明

上述配置表示：可以允许来自 http://docs.spring.io 的get请求方式获取服务数据。

'[/**]' 表示对所有访问到网关服务器的请求地址

https://cloud.spring.io/spring-cloud-static/spring-cloud-gateway/2.1.1.RELEASE/multi/multi__cors_conﬁguration.html

10.11. Gateway的高可用（了解）

启动多个Gateway服务，自动注册到Eureka，形成集群。如果是服务内部访问，访问Gateway，自动负载均衡，没

问题。但是，Gateway更多是外部访问，PC端、移动端等。它们无法通过Eureka进行负载均衡，那么该怎么办？此时，可以使用其它的服务网关，来对Gateway进行代理。比如：Nginx

10.12. Gateway与Feign的区别

Gateway 作为整个应用的流量入口，接收所有的请求，如PC、移动端等，并且将不同的请求转- 发至不同的

处理微服务模块，其作用可视为nginx；大部分情况下用作权限鉴定、服务端流量控制

Feign 则是将当前微服务的部分服务接口暴露出来，并且主要用于各个微服务之间的服务调用

11.Spring Cloud Conﬁg分布式配置中心

11.1. 简介

在分布式系统中，由于服务数量非常多，配置文件分散在不同的微服务项目中，管理不方便。为了方便配置文件集中管理，需要分布式配置中心组件。在Spring Cloud中，提供了Spring Cloud Conﬁg，它支持配置文件放在配置服务的本地，也支持放在远程Git仓库（GitHub、码云）。

使用Spring Cloud Conﬁg配置中心后的架构如下图

配置中心本质上也是一个微服务，同样需要注册到Eureka服务注册中心！

11.2. Git配置管理

码云访问地址：https://gitee.com/

11.2.2. 创建远程仓库

首先要使用码云上的私有远程git仓库需要先注册帐号；请先自行访问网站并注册帐号，然后使用帐号登录码云控制

台并创建公开仓库。(私有也可以,只不过需要在yml中配置账号密码)

11.2.3. 创建配置文件

在新建的仓库中创建需要被统一配置管理的配置文件。

{application}-{proﬁle}.yml 或 {application}-{proﬁle}.properties

application为应用名称

proﬁle用于区分开发环境，测试环境、生产环境等

如user-dev.yml，表示用户微服务开发环境下使用的配置文件。

这里将user-service工程的配置文件application.yml文件的内容复制作为user-dev.yml文件的内容，具体配置如

下：

创建完user-dev.yml配置文件之后，gitee中的仓库如下：

11.3. 搭建配置中心微服务

11.3.1.创建项目

创建配置中心微服务工程：

添加依赖，修改 conﬁg-server\pom.xml 如下：

<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><parent><artifactId>lxs-springcloud</artifactId><groupId>com.lxs</groupId><version>1.0-SNAPSHOT</version></parent><modelVersion>4.0.0</modelVersion><artifactId>config-server</artifactId><dependencies><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-eureka-client</artifactId></dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-config-server</artifactId></dependency></dependencies></project>

11.3.2. 启动类

创建配置中心工程 conﬁg-server 的启动类；

conﬁg-server\src\main\java\com\zx\conﬁg\ConﬁgServerApplication.java 如下：

package com.zx.config;import org.springframework.boot.SpringApplication;import org.springframework.boot.autoconfigure.SpringBootApplication;import org.springframework.cloud.config.server.EnableConfigServer;@SpringBootApplication@EnableConfigServer //开启配置服务public class ConfigServerApplication {public static void main(String[] args) {SpringApplication.run(ConfigServerApplication.class, args);}}

11.3.3. 配置文件

 
server:port: 12000spring:application:name: config-servercloud:config:server:git:uri: https://gitee.com/root121toor/my-config.giteureka:client:service-url:defaultZone: http://127.0.0.1:10086/eureka

注意上述的 spring.cloud.conﬁg.server.git.uri 则是在码云创建的仓库地址；可修改为你自己创建的仓库地址

11.3.4. 启动测试

启动eureka注册中心和配置中心；然后访问http://localhost:12000/user-dev.yml ，查看能否输出在码云存储管理的user-dev.yml文件。并且可以在gitee上修改user-dev.yml然后刷新上述测试地址也能及时到最新数据。

11.4. 获取配置中心配置

前面已经完成了配置中心微服务的搭建，下面我们就需要改造一下用户微服务 user-service ，配置文件信息不再由微服务项目提供，而是从配置中心获取。如下对 user-service 工程进行改造。

11.4.1. 添加依赖

在 user-service 工程中的pom.xml文件中添加如下依赖：

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

11.4.2. 修改配置

1. 删除 user-service 工程的 user-service\src\main\resources\application.yml 文件（因为该文件从配置中心获取）

2. 创建 user-service 工程 user-service\src\main\resources\bootstrap.yml 配置文件

spring:cloud:config:# 要与仓库中的配置文件的application保持一致name: user# 要与仓库中的配置文件的profile保持一致profile: dev# 要与仓库中的配置文件所属的版本（分支）一样label: masterdiscovery:# 使用配置中心enabled: true# 配置中心服务名service-id: config-servereureka:client:service-url:defaultZone: http://127.0.0.1:10086/eureka

user-service 工程修改后结构：

bootstrap.yml文件也是Spring Boot的默认配置文件，而且其加载的时间相比于application.yml更早。

application.yml和bootstrap.yml虽然都是Spring Boot的默认配置文件，但是定位却不相同。bootstrap.yml可以理解成系统级别的一些参数配置，这些参数一般是不会变动的。application.yml 可以用来定义应用级别的参数，如果搭配 spring cloud conﬁg 使用，application.yml 里面定义的文件可以实现动态替换。

总结就是，bootstrap.yml文件相当于项目启动时的引导文件，内容相对固定。application.yml文件是微服务的一些常规配置参数，变化比较频繁。

11.4.3. 启动测试

启动注册中心 eureka-server 、配置中心 conﬁg-server 、用户服务 user-service ，如果启动没有报错其实已经使用上配置中心内容，可以到注册中心查看，也可以检验 user-service 的服务。

12.Spring Cloud Bus服务总线

12.1. 问题

前面已经完成了将微服务中的配置文件集中存储在远程Git仓库，并且通过配置中心微服务从Git仓库拉取配置文件，当用户微服务启动时会连接配置中心获取配置信息从而启动用户微服务。如果我们更新Git仓库中的配置文件，那用户微服务不能及时接收到新的配置信息并更新

12.1.1. 修改远程Git配置

修改在码云上的user-dev.yml文件，添加一个属性test.name 。

12.1.2. 修改UserController

修改 user-service 工程中的处理器类；

user-service\src\main\java\com\zx\user\controller\UserController.java 如下：

@RestControllerpublic class UserController {@Autowiredprivate UserService userService;@Value("${test.name}")private String name;@GetMapping("/user/{id}")public User queryById(@PathVariable Long id){System.out.println("配置文件中的test.name为：" + name);return userService.queryById(id);}@RequestMapping("/user/all")public String all() {return "return all user list..........";}}

12.1.3. 测试

依次启动注册中心 eureka-server 、配置中心 conﬁg-server 、用户服务 user-service ；然后修改Git仓库中的配置信息，访问用户微服务，查看输出内容。

结论：通过查看用户微服务控制台的输出结果可以发现，我们对于Git仓库中配置文件的修改并没有及时更新到用户微服务，只有重启用户微服务才能生效。

如果想在不重启微服务的情况下更新配置该如何实现呢? 可以使用Spring Cloud Bus来实现配置的自动更新。

需要注意的是Spring Cloud Bus底层是基于RabbitMQ实现的，默认使用本地的消息队列服务，所以需要提前启动本地RabbitMQ服务（安装RabbitMQ以后才有）

12.2. Spring Cloud Bus简介

Spring Cloud Bus是用轻量的消息代理将分布式的节点连接起来，可以用于广播配置文件的更改或者服务的监控管理。也就是消息总线可以为微服务做监控，也可以实现应用程序之间相互通信。 Spring Cloud Bus可选的消息代理有RabbitMQ和Kafka。

使用了Bus之后：

准备工作

win 安装资料中\otp_win64_23.0.exe和rabbitmq-server-3.8.5.exe

mac 使用

brew install rabbitmq

进入到 /usr/local/Cellar/rabbitmq/3.6.6，执行

sbin/rabbitmq-server

3
地址栏输入:  http://localhost:15672/    账号密码都是 guest12.3.  改造配置中心

在 conﬁg-server 项目的pom.xml文件中加入Spring Cloud Bus相关依赖

<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-bus</artifactId></dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-stream-binder-rabbit</artifactId></dependency>

在 conﬁg-server 项目修改application.yml文件如下：

server:port: 12000spring:application:name: config-servercloud:config:server:git:uri: https://gitee.com/lxsong77/lxs-config.git# 配置rabbitmq信息；如果是都与默认值一致则不需要配置rabbitmq:host: localhostport: 5672username: guestpassword: guesteureka:client:service-url:defaultZone: http://127.0.0.1:10086/eurekamanagement:endpoints:web:exposure:# 暴露触发消息总线的地址include: bus-refresh

12.4. 改造用户服务

1. 在用户微服务 user-service 项目的pom.xml中加入Spring Cloud Bus相关依赖

<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-bus</artifactId></dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-stream-binder-rabbit</artifactId></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-actuator</artifactId></dependency>

2. 修改 user-service 项目的bootstrap.yml如下

spring:cloud:config:# 要与仓库中的配置文件的application保持一致name: user# 要与仓库中的配置文件的profile保持一致profile: dev# 要与仓库中的配置文件所属的版本（分支）一样label: masterdiscovery:# 使用配置中心enabled: true# 配置中心服务名service-id: config-server# 配置rabbitmq信息；如果是都与默认值一致则不需要配置rabbitmq:host: localhostport: 5672username: guestpassword: guesteureka:client:service-url:defaultZone: http://127.0.0.1:10086/eureka

3. 改造用户微服务 user-service 项目的UserController

12.5. 测试

前面已经完成了配置中心微服务和用户微服务的改造，下面来测试一下，当我们修改了Git仓库中的配置文件，用户微服务是否能够在不重启的情况下自动更新配置信息。

测试步骤：

第零步: 开启rabbit cd usr/local/Cellar/rabbitmq/3.8.8/sbin/ 然后执行 ./rabbitmq-server restart

第一步：依次启动注册中心 eureka-server conﬁg-server 、用户服务 user-service

第二步：访问用户微服务http://localhost:9091/user/7；查看IDEA控制台输出结果

第三步：修改Git仓库中配置文件 user-dev.yml 的 test.name 内容

第四步:POST方式请求访问地址http://127.0.0.1:12000/actuator/bus-refresh

第五步：再次访问用户微服务http://localhost:9091/user/7；查看IDEA控制台输出结果

请求http://127.0.0.1:12000/actuator/bus-refresh目的: 服务接收到请求后会向消息队列中发送消息，各个微服务会监听消息队列。当微服务接收到队列中的消息后，会重新从配置中心获取最新的配置信息

---------------------
作者：alibaba_张无忌
来源：CSDN
原文：https://blog.csdn.net/weixin_45434902/article/details/110673405
版权声明：本文为作者原创文章，转载请附上博文链接！
内容解析By：CSDN,CNBLOG博客文章一键转载插件