qidao123.com技术社区-IT企服评测·应用市场

标题: SpringCloud带你走进微服务的世界 [打印本页]

---

作者: 南飓风    时间: 2025-3-13 06:42
标题: SpringCloud带你走进微服务的世界
认识微服务

随着互联网行业的发展，对服务的要求也越来越高，服务架构也从单体架构逐渐演变为现在盛行的微服务架构。这些架构之间有怎样的差别呢？
单体架构

单体架构：将业务的所有功能会集在一个项目中开发，打成一个包摆设。

单体架构的优缺点如下：
优点：

• 架构简朴
  
• 摆设成本低
  

缺点：

• 耦合度高（维护困难、升级困难）
  

分布式架构

分布式架构：根据业务功能对系统做拆分，每个业务功能模块作为独立项目开发，称为一个服务。

分布式架构的优缺点：
优点：

• 降低服务耦合
  
• 有利于服务升级和拓展
  

缺点：

• 服务调用关系错综复杂
  

分布式架构固然降低了服务耦合，但是服务拆分时也有很多问题需要思索：

• 服务拆分的粒度如何界定？
  
• 服务之间如何调用？
  
• 服务的调用关系如何管理？
  

人们需要制定一套行之有效的标准来束缚分布式架构。
微服务

微服务的架构特征：

• 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责
  
• 自治：团队独立、技术独立、数据独立，独立摆设和交付
  
• 面向服务：服务提供统一标准的接口，与语言和技术无关
  
• 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题
  

微服务的上述特性其实是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚，低耦合。
因此，可以以为微服务是一种经过良好架构计划的分布式架构方案 。
但方案该怎么落地？选用什么样的技术栈？全球的互联网公司都在积极尝试本身的微服务落地方案。
此中在Java范畴最引人注目标就是SpringCloud提供的方案了。
SpringCloud

SpringCloud是目前国内利用最广泛的微服务框架。官网地址：https://spring.io/projects/spring-cloud。
SpringCloud集成了各种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用体验。
此中常见的组件包括：

springcloud是一个基于Spring Boot实现的微服务架构开发工具。spring cloud包含多个子项目：

• Spring Cloud Config：配置管理工具，支持利用Git存储配置内容， 可以利用它实现应用配置的外部化存储， 并支持客户端配置信息革新、加密／解密配置内容等。
  
• Spring Cloud Netflix：核心 组件，对多个Netflix OSS开源套件进行整合。
  
  
  
  • Eureka: 服务管理组件， 包含服务注册中心、服务注册与发现机制的实现。
    
  • Hystrix: 容错管理组件，实现断路器模式， 帮助服务依靠中出现的延迟和为故障提供强大的容错能力。
    
  • Ribbon: 客户端负载均衡的服务调用组件。
    
  • Feign: 基于Ribbon 和Hystrix 的声明式服务调用组件。
    
  • Zuul: 网关组件， 提供智能路由、访问过滤等功能。
    
  • Archaius: 外部化配置组件。
    
  
  
• Spring Cloud Gateway：
  
• Spring Cloud Bus: 事件、消息总线， 用于传播集群中的状态变化或事件， 以触发后续的处理， 好比用来动态革新配置等。
  
• Spring Cloud Cluster: 针对ZooKeeper、Redis、Hazelcast、Consul 的推举算法和通用状态模式的实现。
  
• Spring Cloud Consul: 服务发现与配置管理工具。
  
• Spring Cloud ZooKeeper: 基于ZooKeeper 的服务发现与配置管理组件。
  
• Spring Cloud Security：Spring Security组件封装，提供用户验证和权限验证，一样平常与Spring Security OAuth2 组一起利用，通过搭建授权服务，验证Token大概JWT这种形式对整个微服务系统进行安全验证
  
• Spring Cloud Sleuth：分布式链路追踪组件，他分封装了Dapper、Zipkin、Kibana 的组件
  
• Spring Cloud Stream：Spring Cloud框架的数据流操纵包，可以封装RabbitMq，ActiveMq，Kafka，Redis等消息组件，利用Spring Cloud Stream可以实现消息的接收和发送
  

spring-boot-starter-actuator：该模块能够自动为Spring Boot 构建的应用提供一系列用于监控的端点。
总结

• 单体架构：简朴方便，高度耦合，扩展性差，得当小型项目。例如：门生管理系统
  
• 分布式架构：松耦合，扩展性好，但架构复杂，难度大。得当大型互联网项目，例如：京东、淘宝
  
• 微服务：一种良好的分布式架构方案
  ①优点：拆分粒度更小、服务更独立、耦合度更低
  ②缺点：架构非常复杂，运维、监控、摆设难度提高
  
• SpringCloud是微服务架构的一站式解决方案，集成了各种良好微服务功能组件
  

服务拆分和远程调用

任何分布式架构都离不开服务的拆分，微服务也是一样。
服务拆分原则

这里我总结了微服务拆分时的几个原则：

• 不同微服务，不要重复开发相同业务
  
• 微服务数据独立，不要访问其它微服务的数据库
  
• 微服务可以将本身的业务暴露为接口，供其它微服务调用
  

服务拆分示例

以课前资料中的微服务cloud-demo为例，其布局如下：

cloud-demo：父工程，管理依靠

• order-service：订单微服务，负责订单相干业务
  
• user-service：用户微服务，负责用户相干业务
  

要求：

• 订单微服务和用户微服务都必须有各自的数据库，相互独立
  
• 订单服务和用户服务都对外暴露Restful的接口
  
• 订单服务如果需要查询用户信息，只能调用用户服务的Restful接口，不能查询用户数据库
  

实现远程调用案例

在order-service服务中，有一个根据id查询订单的接口：

根据id查询订单，返回值是Order对象，如图：

此中的user为null
在user-service中有一个根据id查询用户的接口：

查询的结果如图：

案例需求：

修改order-service中的根据id查询订单业务，要求在查询订单的同时，根据订单中包含的userId查询出用户信息，一起返回。

因此，我们需要在order-service中 向user-service发起一个http的哀求，调用http://localhost:8081/user/{userId}这个接口。
大概的步骤是这样的：

• 注册一个RestTemplate的实例到Spring容器
  
• 修改order-service服务中的OrderService类中的queryOrderById方法，根据Order对象中的userId查询User
  
• 将查询的User填充到Order对象，一起返回
  

注册RestTemplate

首先，我们在order-service服务中的OrderApplication启动类中，注册RestTemplate实例：

1. import org.mybatis.spring.annotation.MapperScan;
2. import org.springframework.boot.SpringApplication;
3. import org.springframework.boot.autoconfigure.SpringBootApplication;
4. import org.springframework.context.annotation.Bean;
5. import org.springframework.web.client.RestTemplate;
7. @MapperScan("com.seven.order.mapper")
8. @SpringBootApplication
9. public class OrderApplication {
11.     public static void main(String[] args) {
12.         SpringApplication.run(OrderApplication.class, args);
13.     }
15.     @Bean
16.     public RestTemplate restTemplate() {
17.         return new RestTemplate();
18.     }
19. }

复制代码

实现远程调用

修改order-service服务中的cn.seven.order.service包下的OrderService类中的queryOrderById方法：

提供者与消耗者

在服务调用关系中，会有两个不同的角色：
服务提供者：一次业务中，被其它微服务调用的服务。（提供接口给其它微服务）
服务消耗者：一次业务中，调用其它微服务的服务。（调用其它微服务提供的接口）

但是，服务提供者与服务消耗者的角色并不是绝对的，而是相对于业务而言。
如果服务A调用了服务B，而服务B又调用了服务C，服务B的角色是什么？

• 对于A调用B的业务而言：A是服务消耗者，B是服务提供者
  
• 对于B调用C的业务而言：B是服务消耗者，C是服务提供者
  

因此，服务B既可以是服务提供者，也可以是服务消耗者。
Eureka注册中心

如果我们的服务提供者user-service摆设了多个实例，如图：

各人思索几个问题：

• order-service在发起远程调用的时候，该如何得知user-service实例的ip地址和端口？
  
• 有多个user-service实例地址，order-service调用时该如何选择？
  
• order-service如何得知某个user-service实例是否依然健康，是不是已经宕机？
  

Eureka的布局

这些问题都需要利用SpringCloud中的注册中心来解决，此中最广为人知的注册中心就是Eureka，其布局如下：

Spring Cloud Eureka实现微服务架构中的服务管理功能，利用 Netflix Eureka 实现服务注册与发现，包含客户端组件和服务端组件。服务管理是微服务架构中最为核心和基础的模块。
Eureka 服务端就是服务注册中心。Eureka 客户端用于处理服务的注册和发现。客户端服务通过注解和参数配置的方式，嵌入在客户端应用程序的代码中， 在应用程序运行时，Eureka客户端向注册中心注册自身提供的服务并周期性地发送心跳来更新它的服务租约。同时，它也能从服务端查询当前注册的服务信息并把它们缓存到本地并周期性地革新服务状态。
答复之前的各个问题。
问题1：order-service如何得知user-service实例地址？
获取地址信息的流程如下：

• user-service服务实例启动后，将本身的信息注册到eureka-server（Eureka服务端）。这个叫服务注册
  
• eureka-server生存服务名称到服务实例地址列表的映射关系
  
• order-service根据服务名称，拉取实例地址列表。这个叫服务发现或服务拉取
  

问题2：order-service如何从多个user-service实例中选择具体的实例？

• order-service从实例列表中利用负载均衡算法选中一个实例地址
  
• 向该实例地址发起远程调用
  

问题3：order-service如何得知某个user-service实例是否依然健康，是不是已经宕机？

• user-service会每隔一段时间（默认30秒）向eureka-server发起哀求，报告本身状态，称为心跳
  
• 当超过肯定时间没有发送心跳时，eureka-server会以为微服务实例故障，将该实例从服务列表中剔除
  
• order-service拉取服务时，就能将故障实例排除了
  

留意：一个微服务，既可以是服务提供者，又可以是服务消耗者，因此eureka将服务注册、服务发现等功能统一封装到了eureka-client端

服务注册：在微服务架构中每每会有一个注册中心，每个微服务都会向注册中心去注册本身的地址及端口信息，注册中心维护着服务名称与服务实例的对应关系。每个微服务都会定时从注册中心获取服务列表，同时报告本身的运行情况，这样当有的服务需要调用其他服务时，就可以从本身获取到的服务列表中获取实例地址进行调用。
服务发现：服务间的调用不是通过直接调用具体的实例地址，而是通过服务名发起调用。调用方需要向服务注册中心咨询服务，获取服务的实例清单，从而访问具体的服务实例。
因此，接下来我们动手实践的步骤包括：

搭建eureka-server

首先各人注册中心服务端：eureka-server，这必须是一个独立的微服务
引入eureka依靠

引入SpringCloud为eureka提供的starter依靠：

1. <dependency>
2.     <groupId>org.springframework.cloud</groupId>
3.     <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
4. </dependency>

复制代码

编写启动类

给eureka-server服务编写一个启动类，肯定要添加一个@EnableEurekaServer注解，开启eureka的注册中心功能：

1. import org.springframework.boot.SpringApplication;
2. import org.springframework.boot.autoconfigure.SpringBootApplication;
3. import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;
5. @SpringBootApplication
6. @EnableEurekaServer
7. public class EurekaApplication {
8.     public static void main(String[] args) {
9.         SpringApplication.run(EurekaApplication.class, args);
10.     }
11. }

复制代码

编写配置文件

编写一个application.yml文件，内容如下：

1. server:
2.   port: 10086
3. spring:
4.   application:
5.     name: eureka-server
6. eureka:
7.   client:
8.     service-url:
9.       defaultZone: http://127.0.0.1:10086/eureka

复制代码

启动服务

启动微服务，然后在欣赏器访问：http://127.0.0.1:10086
看到下面结果就是成功了：

服务注册

下面，我们将user-service注册到eureka-server中去。
引入依靠

在user-service的pom文件中，引入下面的eureka-client依靠：

1. <dependency>
2.     <groupId>org.springframework.cloud</groupId>
3.     <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
4. </dependency>

复制代码

配置文件

在user-service中，修改application.yml文件，添加服务名称、eureka地址：

1. spring:
2.   application:
3.     name: userservice
4. eureka:
5.   client:
6.     service-url:
7.       defaultZone: http://127.0.0.1:10086/eureka

复制代码

启动多个user-service实例

为了演示一个服务有多个实例的场景，我们添加一个SpringBoot的启动配置，再启动一个user-service。
然后，在弹出的窗口中，填写信息：

启动两个user-service实例：

查看eureka-server管理页面：

服务发现

下面，我们将order-service的逻辑修改：向eureka-server拉取user-service的信息，实现服务发现。
引入依靠

之前说过，服务发现、服务注册统一都封装在eureka-client依靠，因此这一步与服务注册时一致。
在order-service的pom文件中，引入下面的eureka-client依靠：

1. <dependency>
2.     <groupId>org.springframework.cloud</groupId>
3.     <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
4. </dependency>

复制代码

配置文件

服务发现也需要知道eureka地址，因此第二步与服务注册一致，都是配置eureka信息：
在order-service中，修改application.yml文件，添加服务名称、eureka地址：

1. spring:
2.   application:
3.     name: orderservice
4. eureka:
5.   client:
6.     service-url:
7.       defaultZone: http://127.0.0.1:10086/eureka

复制代码

服务拉取和负载均衡

最后，我们要去eureka-server中拉取user-service服务的实例列表，而且实现负载均衡。
不外这些动作不用我们去做，只需要添加一些注解即可。
在order-service的OrderApplication中，给RestTemplate这个Bean添加一个@LoadBalanced注解：

修改order-service服务中的cn.seven.order.service包下的OrderService类中的queryOrderById方法。修改访问的url路径，用服务名代替ip、端口：

spring会自动帮助我们从eureka-server端，根据userservice这个服务名称，获取实例列表，而后完成负载均衡。
自我保护模式

什么是自我保护模式？

• 自我保护的条件：一样平常情况下，微服务在 Eureka 上注册后，会每 30 秒发送心跳包，Eureka 通过心跳来判断服务是否健康，同时会定期删除超过 90 秒没有发送心跳服务。
  
• 有两种情况会导致 Eureka Server 收不到微服务的心跳
  
  
  • 是微服务自身的缘故原由
    
  • 是微服务与 Eureka 之间的网络故障
    
  
  

通常(微服务的自身的故障关闭)只会导致个别服务出现故障，一样平常不会出现大面积故障，而(网络故障)通常会导致 Eureka Server 在短时间内无法收到大批心跳。考虑到这个区别，Eureka 设置了一个阀值，当判断挂掉的服务的数量超过阀值时，Eureka Server 以为很大程度上出现了网络故障，将不再删除心跳过期的服务。

• 那么这个阀值是多少呢？
  

15 分钟之内是否低于 85%；Eureka Server 在运行期间，会统计心跳失败的比例在 15 分钟内是否低于 85%,这种算法叫做 Eureka Server 的自我保护模式。
为什么要自我保护？

• 因为同时生存"好数据"与"坏数据"总比丢掉任何数据要更好，当网络故障规复后，这个 Eureka 节点会退出"自我保护模式"。
  
• Eureka 还有客户端缓存功能(也就是微服务的缓存功能)。即便 Eureka 集群中所有节点都宕机失效，微服务的 Provider 和 Consumer都能正常通讯。
  
• 微服务的负载均衡策略会自动剔除死亡的微服务节点。
  

Ribbon负载均衡

上一节中，我们添加了@LoadBalanced注解，即可实现负载均衡功能，这是什么原理呢？
负载均衡原理

SpringCloud底层其实是利用了一个名为Ribbon的组件，来实现负载均衡功能的。

那么我们发出的哀求明明是http://userservice/user/1，怎么酿成了http://localhost:8081的呢？
什么是 Ribbon

• Ribbon 是一个基于 Http 和 TCP 的客服端负载均衡工具，它是基于 Netflix Ribbon 实现的。
  
• 它不像 spring cloud 服务注册中心、配置中心、API 网关那样独立摆设，但是它几乎存在于每个Spring cloud 微服务中。包括 feign 提供的声明式服务调用也是基于该 Ribbon实现的。
  
• Ribbon 默认提供很多种负载均衡算法，例如 轮询、随机 等等。乃至包含自定义的负载均衡算法。
  

在客户端节点会维护可访问的服务器清单，服务器清单来自服务注册中心，通过心跳维持服务器清单的健康性。
开启客户端负载均衡调用：

• 服务提供者启动多个服务实例注册到服务注册中心；
  
• 服务消耗者直接通过调用被@LoadBalanced 注解修饰过的RestTemplate 来实现面向服务的接口调用。
  

会集式与历程内负载均衡的区别

目前业界主流的负载均衡方案可分成两类：

• 会集式负载均衡, 即在 consumer 和 provider 之间利用独立的负载均衡设施(可以是硬件，如F5, 也可以是软件，如 Nginx), 由该设施负责把 访问哀求 通过某种策略转发至 provider；
  
• 历程内负载均衡，将负载均衡逻辑集成到 consumer，consumer 从服务注册中心获知有哪些地址可用，然后本身再从这些地址中选择出一个合适的 provider。Ribbon 就属于后者，它只是一个类库，集成于 consumer 历程，consumer 通过它来获取到 provider 的地址。
  

源码跟踪

为什么我们只输入了service名称就可以访问了呢？之前还要获取ip和端口。
显然有人帮我们根据service名称，获取到了服务实例的ip和端口。它就是LoadBalancerInterceptor，这个类会在对RestTemplate的哀求进行拦截，然后从Eureka根据服务id获取服务列表，随后利用负载均衡算法得到真实的服务地址信息，替换服务id。
我们进行源码跟踪：
LoadBalancerIntercepor

可以看到这里的intercept方法，拦截了用户的HttpRequest哀求，然后做了几件事：

• request.getURI()：获取哀求uri，本例中就是 http://user-service/user/8
  
• originalUri.getHost()：获取uri路径的主机名，其实就是服务id，user-service
  
• this.loadBalancer.execute()：处理服务id，和用户哀求。
  

这里的this.loadBalancer是LoadBalancerClient类型，我们继续跟入。
LoadBalancerClient

继续跟入execute方法：

代码是这样的：

• getLoadBalancer(serviceId)：根据服务id获取ILoadBalancer，而ILoadBalancer会拿着服务id去eureka中获取服务列表并生存起来。
  
• getServer(loadBalancer)：利用内置的负载均衡算法，从服务列表中选择一个。本例中，可以看到获取了8082端口的服务
  

放行后，再次访问并跟踪，发现获取的是8081：

果然实现了负载均衡。
负载均衡策略IRule

在刚才的代码中，可以看到获取服务使通过一个getServer方法来做负载均衡:

我们继续跟入：

继续跟踪源码chooseServer方法，发现这么一段代码：

我们看看这个rule是谁：

这里的rule默认值是一个RoundRobinRule，看类的介绍：

这不就是轮询的意思嘛。
到这里，整个负载均衡的流程我们就清楚了。
总结

SpringCloudRibbon的底层采用了一个拦截器，拦截了RestTemplate发出的哀求，对地址做了修改。用一幅图来总结一下：

基本流程如下：

• 拦截我们的RestTemplate哀求http://userservice/user/1
  
• RibbonLoadBalancerClient会从哀求url中获取服务名称，也就是user-service
  
• DynamicServerListLoadBalancer根据user-service到eureka拉取服务列表
  
• eureka返回列表，localhost:8081、localhost:8082
  
• IRule利用内置负载均衡规则，从列表中选择一个，例如localhost:8081
  
• RibbonLoadBalancerClient修改哀求地址，用localhost:8081替代userservice，得到http://localhost:8081/user/1，发起真实哀求
  

负载均衡策略

负载均衡策略

负载均衡的规则都定义在IRule接口中，而IRule有很多不同的实现类：

不同规则的含义如下：
内置负载均衡规则类规则描述RoundRobinRule简朴轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。AvailabilityFilteringRule对以下两种服务器进行忽略：   
（1）在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将连续30秒，如果再次连接失败，短路的连续时间就会几何级地增加。  
（2）并发数过高的服务器。如果一个服务器的并发连接数过高，配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限，可以由客户端的..ActiveConnectionsLimit属性进行配置。WeightedResponseTimeRule为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。ZoneAvoidanceRule以区域可用的服务器为基础进行服务器的选择。利用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。BestAvailableRule忽略那些短路的服务器，并选择并发数较低的服务器。RandomRule随机选择一个可用的服务器。RetryRule重试机制的选择逻辑默认的实现就是ZoneAvoidanceRule，是一种轮询方案
自定义负载均衡策略

通过定义IRule实现可以修改负载均衡规则，有两种方式：

• 代码方式：在order-service中的OrderApplication类中，定义一个新的IRule：
  

1. @Bean
2. public IRule randomRule(){
3.     return new RandomRule();
4. }

复制代码

• 配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改规则：
  

1. userservice: # 给某个微服务配置负载均衡规则，这里是userservice服务
2.   ribbon:
3.     NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则

复制代码

留意，一样平常用默认的负载均衡规则，不做修改。

饥饿加载

Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient，哀求时间会很长。
而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载：

1. ribbon:
2.   eager-load:
3.     enabled: true
4.     clients: userservice

复制代码

Hystrix

在微服务架构中，服务与服务之间通过远程调用的方式进行通讯，一旦某个被调用的服务发生了故障，其依靠服务也会发生故障，此时就会发生故障的蔓延，最终导致灾难性雪崩效应。Hystrix实现了断路器模式，当某个服务发生故障时，通过断路器的监控，给调用方返回一个错误响应，而不是长时间的等待，这样就不会使得调用方由于长时间得不到响应而占用线程，从而防止故障的蔓延。Hystrix具备服务降级、服务熔断、线程隔离、哀求缓存、哀求合并及服务监控等强大功能。
Hystrix介绍

什么是灾难性的雪崩效应

什么是灾难性的雪崩效应?我们通过布局图来阐明，如下

正常情况下各个节点相互配置，完成用户哀求的处理工作

当某种哀求增多，造成"服务T"故障的情况时，会延伸的造成"服务U"不可用，及继续扩展，如下

最终造成下面这种所有服务不可用的情况

这就是我们讲的灾难性雪崩，造成雪崩的缘故原由可以归纳为以下三个:

• 服务提供者不可用(硬件故障，程序Bug，缓存击穿，用户大量哀求)
  
• 重试加大流量(用户重试，代码逻辑重试)
  
• 服务调用者不可用(同步等待造成的资源耗尽)
  

最终的结果就是一个服务不可用，导致一系列服务的不可用，而每每这种后果是无法预料的。
如何解决灾难性雪崩效应

我们可以通过以下5种方式来解决雪崩效应

• 降级：超时降级、资源不足时(线程或信号量)降级，降级后可以共同降级接口返回托底数据。实现一个 fallback 方法, 当哀求后端服务出现非常的时候, 可以利用 fallback 方法返回的值.
  
• 缓存：Hystrix 为了降低访问服务的频率，支持将一个哀求与返回结果做缓存处理。如果再次哀求的 URL 没有变化，那么 Hystrix 不会哀求服务，而是直接从缓存中将结果返回。这样可以大大降低访问服务的压力。
  
• 哀求合并：在微服务架构中，我们将一个项目拆分成很多个独立的模块，这些独立的模块通过远程调用来互相共同工作，但是，在高并发情况下，通讯次数的增加会导致总的通讯时间增加，同时，线程池的资源也是有限的，高并发情况会导致有大量的线程处于等待状态，进而导致响应延迟，为了解决这些问题，我们需要来了解 Hystrix 的哀求合并。
  
• 熔断：当失败率(如因网络故障/超时造成的失败率高)达到阀值自动触发降级，熔断器触发的快速失败会进行快速规复。
  
• 隔离（线程池隔离和信号量隔离）
    限制调用分布式服务的资源利用，某一个调用的服务出现问题不会影响其他服务调用。
  

降级

场景介绍

先来看下正常服务调用的情况

当consumer调用provider服务出现问题的情况下:

此时我们对consumer的服务调用做降级处理

实现案例

创建一个基于Ribbon的Consumer服务，并添加对应的依靠

1. <dependency>
2.     <groupId>org.apache.httpcomponents</groupId>
3.     <artifactId>httpclient</artifactId>
4. </dependency>
6. <dependency>
7.     <groupId>org.springframework.cloud</groupId>
8.     <artifactId>spring-cloud-starter-hystrix</artifactId>
9.     <version>1.3.2.RELEASE</version>
10. </dependency>

复制代码

配置文件

1. spring.application.name=eureka-consumer-hystrix
2. server.port=9091
4. # 设置服务注册中心地址 执行Eureka服务端 如果有多个注册地址 那么用逗号连接
5. eureka.client.service-url.defaultZone=http://seven:123456@192.168.100.120:8761/eureka/,http://seven:123456@192.168.100.121:8761/eureka/

复制代码

修改启动类

在启动类中添加 开启熔断

1. import org.springframework.boot.SpringApplication;
2. import org.springframework.boot.autoconfigure.SpringBootApplication;
3. import org.springframework.cloud.client.circuitbreaker.EnableCircuitBreaker;
5. @EnableCircuitBreaker // 开启Hystrix的熔断
6. @SpringBootApplication
7. public class SpringcloudEurekaConsumerApplication {
9.     public static void main(String[] args) {
10.         SpringApplication.run(SpringcloudEurekaConsumerApplication.class, args);
11.     }
13. }

复制代码

业务层修改

业务层代码中的方法是通过Ribbon来获取负载均衡的服务器地址的，通过RestTemplate来调用服务，在方法的头部添加@HystrixCommand注解，通过fallbackMethod属性指定当调用Provider方法非常的时候fallback方法哀求返回托底数据

1. import com.seven.pojo.User;
2. import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;
3. import org.springframework.beans.factory.annotation.Autowired;
4. import org.springframework.cloud.client.ServiceInstance;
5. import org.springframework.cloud.client.loadbalancer.LoadBalancerClient;
6. import org.springframework.core.ParameterizedTypeReference;
7. import org.springframework.http.HttpMethod;
8. import org.springframework.http.ResponseEntity;
9. import org.springframework.stereotype.Service;
10. import org.springframework.web.client.RestTemplate;
12. import java.util.ArrayList;
13. import java.util.List;
15. @Service
16. public class UserService {
18.     /**
19.      * Ribbon 实现的负载均衡
20.      *    LocadBalancerClient 通过服务名称可以获取对应服务的相关信息
21.      *                         ip 端口 等
22.      */
23.     @Autowired
24.     private LoadBalancerClient loadBalancerClient;
26.     /**
27.      * 远程调用 服务提供者获取用户信息的方法
28.      * 1.发现服务
29.      * 2.调用服务
30.      */
31.     @HystrixCommand(fallbackMethod = "fallBack")
32.     public List<User> getUsers(){
33.         // 1. 服务发现
34.         // 获取服务提供者的信息 ServiceInstance封装的有相关的信息
35.         ServiceInstance instance = loadBalancerClient.choose("eureka-provider");
36.         StringBuilder sb = new StringBuilder();
37.         // http://localhost:9090/user
38.         sb.append("http://")
39.                 .append(instance.getHost())
40.                 .append(":")
41.                 .append(instance.getPort())
42.                 .append("/user");
43.         System.out.println(sb.toString());
44.         // 2. 服务调用 SpringMVC中提供的有 调用组件 RestTemplate
45.         RestTemplate rt = new RestTemplate();
46.         ParameterizedTypeReference<List<User>> type = new ParameterizedTypeReference<List<User>>() {};
47.         ResponseEntity<List<User>> response = rt.exchange(sb.toString(), HttpMethod.GET, null, type);
48.         List<User> list = response.getBody();
49.         return list;
50.     }
52.     /**
53.      * 托底方法
54.      * @return
55.      */
56.     public List<User> fallBack(){
57.         List<User> list = new ArrayList<>();
58.         list.add(new User(333,"我是托底数据",28));
59.         return list;
60.     }
61. }

复制代码

缓存

Hystrix 为了降低访问服务的频率，支持将一个哀求与返回结果做缓存处理。如果再次哀求的 URL 没有变化，那么 Hystrix 不会哀求服务，而是直接从缓存中将结果返回。这样可以大大降低访问服务的压力。
Hystrix 自带缓存。有两个缺点：

• 是一个本地缓存。在集群情况下缓存是不能同步的。
  
• 不支持第三方缓存容器。Redis，memcache 不支持的。
  

所以我们利用Spring的cache。
启动Redis服务

利用Redis作为缓存服务器
添加相干的依靠

因为需要用到SpringDataRedis的支持，需要添加对应的依靠

1. <dependency>
2.     <groupId>org.springframework.cloud</groupId>
3.     <artifactId>spring-cloud-starter-hystrix</artifactId>
4.     <version>1.3.2.RELEASE</version>
5. </dependency>
7. <dependency>
8.     <groupId>org.springframework.boot</groupId>
9.     <artifactId>spring-boot-starter-data-redis</artifactId>
10. </dependency>

复制代码

修改属性文件

需要在属性文件中添加Redis的配置信息

1. spring.application.name=eureka-consumer-hystrix
2. server.port=9091
4. # 设置服务注册中心地址 执行Eureka服务端 如果有多个注册地址 那么用逗号连接
5. eureka.client.service-url.defaultZone=http://seven:123456@192.168.100.120:8761/eureka/,http://seven:123456@192.168.100.121:8761/eureka/        # Redisspring.redis.database=0#Redis 服务器地址spring.redis.host=192.168.100.120#Redis 服务器连接端口spring.redis.port=6379#Redis 服务器连接密码（默以为空）spring.redis.password=#连接池最大连接数（负值表现没有限制）spring.redis.pool.max-active=100#连接池最大壅闭等待时间（负值表现没有限制）spring.redis.pool.max-wait=3000#连接池最大空闭连接数spring.redis.pool.max-idle=200#连接汉最小空闲连接数spring.redis.pool.min-idle=50#连接超时时间（毫秒）spring.redis.pool.timeout=600

复制代码

修改启动类

需要在启动类中开启缓存的利用

1. @EnableCaching // 开启缓存
2. @EnableCircuitBreaker // 开启Hystrix的熔断
3. @SpringBootApplication
4. public class SpringcloudEurekaConsumerApplication {
6.     public static void main(String[] args) {
7.         SpringApplication.run(SpringcloudEurekaConsumerApplication.class, args);
8.     }
10. }

复制代码

业务处理

1. import com.seven.pojo.User;
2. import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;
3. import org.springframework.beans.factory.annotation.Autowired;
4. import org.springframework.cache.annotation.CacheConfig;
5. import org.springframework.cache.annotation.Cacheable;
6. import org.springframework.cloud.client.ServiceInstance;
7. import org.springframework.cloud.client.loadbalancer.LoadBalancerClient;
8. import org.springframework.core.ParameterizedTypeReference;
9. import org.springframework.http.HttpMethod;
10. import org.springframework.http.ResponseEntity;
11. import org.springframework.stereotype.Service;
12. import org.springframework.web.client.RestTemplate;
14. import java.util.ArrayList;
15. import java.util.List;
17. @Service
18. // cacheNames 当前类中的方法在Redis中添加的Key的前缀
19. @CacheConfig(cacheNames = {"com.seven.cache"})
20. public class UserService {
23.     /**
24.      * Ribbon 实现的负载均衡
25.      *    LocadBalancerClient 通过服务名称可以获取对应服务的相关信息
26.      *                         ip 端口 等
27.      */
28.     @Autowired
29.     private LoadBalancerClient loadBalancerClient;
31.     /**
32.      * 远程调用 服务提供者获取用户信息的方法
33.      * 1.发现服务
34.      * 2.调用服务
35.      */
36.     @HystrixCommand(fallbackMethod = "fallBack")
37.     public List<User> getUsers(){
38.         // 1. 服务发现
39.         // 获取服务提供者的信息 ServiceInstance封装的有相关的信息
40.         ServiceInstance instance = loadBalancerClient.choose("eureka-provider");
41.         StringBuilder sb = new StringBuilder();
42.         // http://localhost:9090/user
43.         sb.append("http://")
44.                 .append(instance.getHost())
45.                 .append(":")
46.                 .append(instance.getPort())
47.                 .append("/user");
48.         System.out.println(sb.toString());
49.         // 2. 服务调用 SpringMVC中提供的有 调用组件 RestTemplate
50.         RestTemplate rt = new RestTemplate();
51.         ParameterizedTypeReference<List<User>> type = new ParameterizedTypeReference<List<User>>() {};
52.         ResponseEntity<List<User>> response = rt.exchange(sb.toString(), HttpMethod.GET, null, type);
53.         List<User> list = response.getBody();
54.         return list;
56.     }
58.     /**
59.      * 托底方法
60.      * @return
61.      */
62.     public List<User> fallBack(){
63.         List<User> list = new ArrayList<>();
64.         list.add(new User(333,"我是托底数据",28));
65.         return list;
66.     }
68.     @Cacheable(key="'user'+#id")
69.     public User getUserById(Integer id){
70.         System.out.println("*************查询操作*************"+ id);
71.         return new User(id,"缓存测试数据",22);
72.     }
73. }

复制代码

利用到了缓存，所以会对POJO对象做持久化处理，所以需要实现序列化接口，否则会抛非常
哀求合并

没有合并哀求的场景

没有合并的场景中，对于provider的调用会非常的频繁，容易造成处理不外来的情况

合并哀求的场景

什么情况下利用哀求合并

在微服务架构中，我们将一个项目拆分成很多个独立的模块，这些独立的模块通过远程调用来互相共同工作，但是，在高并发情况下，通讯次数的增加会导致总的通讯时间增加，同时，线程池的资源也是有限的，高并发情况会导致有大量的线程处于等待状态，进而导致响应延迟，为了解决这些问题，我们需要来了解 Hystrix 的哀求合并。
哀求合并的缺点

设置哀求合并之后，本来一个哀求可能 5ms 就搞定了，但是现在必须再等 10ms 看看还有没有其他的哀求一起的，这样一个哀求的耗时就从 5ms 增加到 15ms 了，不外，如果我们要发起的命令本身就是一个高延迟的命令，那么这个时候就可以利用哀求合并了，因为这个时候时间窗的时间消耗就显得微不足道了，另外高并发也是哀求合并的一个非常重要的场景。
案例实现

业务处理代码

1. import com.seven.pojo.User;
2. import com.netflix.hystrix.contrib.javanica.annotation.HystrixCollapser;
3. import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;
4. import com.netflix.hystrix.contrib.javanica.annotation.HystrixProperty;
5. import org.springframework.beans.factory.annotation.Autowired;
6. import org.springframework.cache.annotation.CacheConfig;
7. import org.springframework.cache.annotation.Cacheable;
8. import org.springframework.cloud.client.ServiceInstance;
9. import org.springframework.cloud.client.loadbalancer.LoadBalancerClient;
10. import org.springframework.core.ParameterizedTypeReference;
11. import org.springframework.http.HttpMethod;
12. import org.springframework.http.ResponseEntity;
13. import org.springframework.stereotype.Service;
14. import org.springframework.web.client.RestTemplate;
16. import java.util.ArrayList;
17. import java.util.List;
18. import java.util.concurrent.Future;
20. @Service
21. // cacheNames 当前类中的方法在Redis中添加的Key的前缀
22. @CacheConfig(cacheNames = {"com.seven.cache"})
23. public class UserService {
26.     /**
27.      * Ribbon 实现的负载均衡
28.      *    LocadBalancerClient 通过服务名称可以获取对应服务的相关信息
29.      *                         ip 端口 等
30.      */
31.     @Autowired
32.     private LoadBalancerClient loadBalancerClient;
34.     /**
35.      * 远程调用 服务提供者获取用户信息的方法
36.      * 1.发现服务
37.      * 2.调用服务
38.      * @return
39.      */
40.     @HystrixCommand(fallbackMethod = "fallBack")
41.     public List<User> getUsers(){
42.         // 1. 服务发现
43.         // 获取服务提供者的信息 ServiceInstance封装的有相关的信息
44.         ServiceInstance instance = loadBalancerClient.choose("eureka-provider");
45.         StringBuilder sb = new StringBuilder();
46.         // http://localhost:9090/user
47.         sb.append("http://")
48.                 .append(instance.getHost())
49.                 .append(":")
50.                 .append(instance.getPort())
51.                 .append("/user");
52.         System.out.println(sb.toString());
53.         // 2. 服务调用 SpringMVC中提供的有 调用组件 RestTemplate
54.         RestTemplate rt = new RestTemplate();
55.         ParameterizedTypeReference<List<User>> type = new ParameterizedTypeReference<List<User>>() {};
56.         ResponseEntity<List<User>> response = rt.exchange(sb.toString(), HttpMethod.GET, null, type);
57.         List<User> list = response.getBody();
58.         return list;
60.     }
62.     /**
63.      * 托底方法
64.      * @return
65.      */
66.     public List<User> fallBack(){
67.         List<User> list = new ArrayList<>();
68.         list.add(new User(333,"我是托底数据",28));
69.         return list;
70.     }
72.     @Cacheable(key="'user'+#id")
73.     public User getUserById(Integer id){
74.         System.out.println("*************查询操作*************"+ id);
75.         return new User(id,"缓存测试数据",22);
76.     }
78.     /**
79.      * Consumer中的Controller要调用的方法
80.      * 这个方法的返回值必须是 Future 类型
81.      *    利用Hystrix 合并请求
82.      */
83.     @HystrixCollapser(
84.             batchMethod = "batchUser"
85.             ,scope = com.netflix.hystrix.HystrixCollapser.Scope.GLOBAL
86.             ,collapserProperties = {
87.                     // 请求时间间隔在20ms以内的请求会被合并，默认值是10ms
88.                     @HystrixProperty(name = "timerDelayInMilliseconds",value = "20")
89.                     // 设置触发批处理执行之前 在批处理中允许的最大请求数
90.                     ,@HystrixProperty(name = "maxRequestsInBatch",value = "200")
91.     }
92.     )
93.     public Future<User> getUserId(Integer id){
94.         System.out.println("*****id*****");
95.         return null;
96.     }
98.     @HystrixCommand
99.     public List<User> batchUser(List<Integer> ids){
100.         for (Integer id : ids) {
101.             System.out.println(id);
102.         }
103.         List<User> list = new ArrayList<>();
104.         list.add(new User(1,"张三1",18));
105.         list.add(new User(2,"张三2",18));
106.         list.add(new User(3,"张三3",18));
107.         list.add(new User(4,"张三4",18));
108.         return list;
109.     }
110. }

复制代码

控制器处理

1. @RequestMapping("/getUserId")
2. public void getUserId() throws Exception{
3.         Future<User> f1 = service.getUserId(1);
4.         Future<User> f2 = service.getUserId(1);
5.         Future<User> f3 = service.getUserId(1);
7.         System.out.println("*************************");
8.         System.out.println(f1.get().toString());
9.         System.out.println(f2.get().toString());
10.         System.out.println(f3.get().toString());
11. }

复制代码

熔断

熔断其实是在降级的基础上引入了重试的机制。当某个时间内失败的次数达到了多少次就会触发熔断机制，具体的流程如下

案例核心代码

1.     @HystrixCommand(fallbackMethod = "fallback",
2.             commandProperties = {
3.                     //默认 20 个;10s 内请求数大于 20 个时就启动熔断器，当请求符合熔断条件时将触发 getFallback()。
4.                     @HystrixProperty(name= HystrixPropertiesManager.CIRCUIT_BREAKER_REQUEST_VOLUME_THRESHOLD,
5.                             value="10"),
6.                     //请求错误率大于 50%时就熔断，然后 for 循环发起请求，当请求符合熔断条件时将触发 getFallback()。
7.                     @HystrixProperty(name=HystrixPropertiesManager.CIRCUIT_BREAKER_ERROR_THRESHOLD_PERCENTAGE,
8.                             value="50"),
9.                     //默认 5 秒;熔断多少秒后去尝试请求
10.                     @HystrixProperty(name=HystrixPropertiesManager.CIRCUIT_BREAKER_SLEEP_WINDOW_IN_MILLISECONDS,
11.                             value="5000"),
12.             })
13.     public List<User> getUsers(){
14.         // 1. 服务发现
15.         // 获取服务提供者的信息 ServiceInstance封装的有相关的信息
16.         ServiceInstance instance = loadBalancerClient.choose("eureka-provider");
17.         StringBuilder sb = new StringBuilder();
18.         // http://localhost:9090/user
19.         sb.append("http://")
20.                 .append(instance.getHost())
21.                 .append(":")
22.                 .append(instance.getPort())
23.                 .append("/user");
24.         System.out.println("---->"+sb.toString());
25.         // 2. 服务调用 SpringMVC中提供的有 调用组件 RestTemplate
26.         RestTemplate rt = new RestTemplate();
27.         ParameterizedTypeReference<List<User>> type = new ParameterizedTypeReference<List<User>>() {};
28.         ResponseEntity<List<User>> response = rt.exchange(sb.toString(), HttpMethod.GET, null, type);
29.         List<User> list = response.getBody();
30.         return list;
32.     }

复制代码

隔离

在应对服务雪崩效应时，除了前面介绍的降级，缓存，哀求合并及熔断外还有一种方式就是隔离，隔离又分为线程池隔离和信号量隔离。接下来我们分别来介绍。
线程池隔离

概念介绍

我们通过以下几个图片来解释线程池隔离到底是怎么回事
在没有利用线程池隔离时：

当接口A压力增大，接口C同时也会受到影响

利用线程池的场景

当服务接口A访问量增大时，因为接口C在不同的线程池中所以不会受到影响

通过上面的图片来看，线程池隔离的作用照旧蛮明显的。但线程池隔离的利用也不是在任何场景下都适用的，线程池隔离的优缺点如下:
优点

• 利用线程池隔离可以完全隔离依靠的服务(例如图中的A，B，C服务)，哀求线程可以快速放回
  
• 当线程池出现问题时，线程池隔离是独立的不会影响其他服务和接口
  
• 当失败的服务再次变得可用时，线程池将清理并可立即规复，而不需要一个长时间的规复
  
• 独立的线程池提高了并发性
  

缺点：线程池隔离的主要缺点是它们增加盘算开销(CPU)，每个命令的执行涉及到排队，调理和上下文切换都是在一个单独的线程上运行的。
案例实现

1.     @HystrixCommand(
2.             groupKey = "eureka-provider"
3.             ,threadPoolKey = "getUsers"
4.             ,threadPoolProperties = {
5.                     @HystrixProperty(name = "coreSize",value = "30") // 线程池大小
6.                     ,@HystrixProperty(name = "maxQueueSize",value = "100") // 最大队列长度
7.                     ,@HystrixProperty(name = "keepAliveTimeMinutes",value = "2") // 线程存活时间
8.                     ,@HystrixProperty(name = "queueSizeRejectionThreshold",value = "15") // 拒绝请求
9.             },fallbackMethod = "fallBack"
10.     )
11.     public List<User> getUsersThreadPool(Integer id){
12.         System.out.println("--------》" + Thread.currentThread().getName());
13.         // 1. 服务发现
14.         // 获取服务提供者的信息 ServiceInstance封装的有相关的信息
15.         ServiceInstance instance = loadBalancerClient.choose("eureka-provider");
16.         StringBuilder sb = new StringBuilder();
17.         // http://localhost:9090/user
18.         sb.append("http://")
19.                 .append(instance.getHost())
20.                 .append(":")
21.                 .append(instance.getPort())
22.                 .append("/user");
23.         System.out.println("---->"+sb.toString());
24.         // 2. 服务调用 SpringMVC中提供的有 调用组件 RestTemplate
25.         RestTemplate rt = new RestTemplate();
26.         ParameterizedTypeReference<List<User>> type = new ParameterizedTypeReference<List<User>>() {};
27.         ResponseEntity<List<User>> response = rt.exchange(sb.toString(), HttpMethod.GET, null, type);
28.         List<User> list = response.getBody();
29.         return list;
31.     }

复制代码

相干参数的描述

信号量隔离

信号量隔离其实就是我们定义的队列并发时最多支持多大的访问，其他的访问通过托底数据来响应，如下布局图

1.     @HystrixCommand(
2.             fallbackMethod = "fallBack"
3.             ,commandProperties = {
4.                     @HystrixProperty(name=HystrixPropertiesManager.EXECUTION_ISOLATION_STRATEGY
5.                             ,value = "SEMAPHORE") // 信号量隔离
6.                     ,@HystrixProperty(name=HystrixPropertiesManager.EXECUTION_ISOLATION_SEMAPHORE_MAX_CONCURRENT_REQUESTS
7.             ,value="100" // 信号量最大并发度
8.     )
9.     }
10.     )
11.     public List<User> getUsersSignal(Integer id){
12.         System.out.println("--------》" + Thread.currentThread().getName());
13.         // 1. 服务发现
14.         // 获取服务提供者的信息 ServiceInstance封装的有相关的信息
15.         ServiceInstance instance = loadBalancerClient.choose("eureka-provider");
16.         StringBuilder sb = new StringBuilder();
17.         // http://localhost:9090/user
18.         sb.append("http://")
19.                 .append(instance.getHost())
20.                 .append(":")
21.                 .append(instance.getPort())
22.                 .append("/user");
23.         System.out.println("---->"+sb.toString());
24.         // 2. 服务调用 SpringMVC中提供的有 调用组件 RestTemplate
25.         RestTemplate rt = new RestTemplate();
26.         ParameterizedTypeReference<List<User>> type = new ParameterizedTypeReference<List<User>>() {};
27.         ResponseEntity<List<User>> response = rt.exchange(sb.toString(), HttpMethod.GET, null, type);
28.         List<User> list = response.getBody();
29.         return list;
31.     }

复制代码

两者的区别

线程池隔离和信号量隔离的区别

Feign远程调用

基于Netflix Feign 实现，整合了Spring Cloud Ribbon 与Spring Cloud Hystrix， 它提供了一种声明式服务调用的方式。
先来看我们以前利用RestTemplate发起远程调用的代码：

存在下面的问题：

• 代码可读性差，编程体验不统一
  
• 参数复杂URL难以维护
  

Feign是一个声明式的http客户端，官方地址：https://github.com/OpenFeign/feign
其作用就是帮助我们优雅的实现http哀求的发送，解决上面提到的问题。
什么是声明式，有什么作用，解决什么问题？声明式调用就像调用本地方法一样调用远程方法;无感知远程 http 哀求。

• Spring Cloud 的声明式调用, 可以做到利用 HTTP 哀求远程服务时能就像调用本地方法一样的体验，开发者完全感知不到这是远程方法，更感知不到这是个 HTTP 哀求。
  
• 它像 Dubbo 一样，consumer 直接调用接口方法调用 provider，而不需要通过常规的Http Client 构造哀求再解析返回数据。
  
• 它解决了让开发者调用远程接口就跟调用本地方法一样，无需关注与远程的交互细节，更无需关注分布式情况开发。
  

Feign替代RestTemplate

Fegin的利用步骤如下：
引入依靠

我们在order-service服务的pom文件中引入feign的依靠：

1. <dependency>
2.     <groupId>org.springframework.cloud</groupId>
3.     <artifactId>spring-cloud-starter-openfeign</artifactId>
4. </dependency>

复制代码

添加注解

在order-service的启动类添加注解开启Feign的功能，@EnableFeignClients
编写Feign的客户端

在order-service中新建一个接口，内容如下：

1. import cn.seven.order.pojo.User;
2. import org.springframework.cloud.openfeign.FeignClient;
3. import org.springframework.web.bind.annotation.GetMapping;
4. import org.springframework.web.bind.annotation.PathVariable;
6. @FeignClient("userservice")
7. public interface UserClient {
8.     @GetMapping("/user/{id}")
9.     User findById(@PathVariable("id") Long id);
10. }

复制代码

这个客户端主要是基于SpringMVC的注解来声明远程调用的信息，好比：

• 服务名称：userservice
  
• 哀求方式：GET
  
• 哀求路径：/user/
  
• 哀求参数：Long id
  
• 返回值类型：User
  

这样，Feign就可以帮助我们发送http哀求，无需本身利用RestTemplate来发送了。
测试

修改order-service中的OrderService类中的queryOrderById方法，利用Feign客户端代替RestTemplate：

是不是看起来优雅多了。
总结

利用Feign的步骤：

• 引入依靠
  
• 添加@EnableFeignClients注解
  
• 编写FeignClient接口
  
• 利用FeignClient中定义的方法代替RestTemplate
  

自定义配置

Feign可以支持很多的自定义配置，如下表所示：
类型作用阐明feign.Logger.Level修改日志级别包含四种不同的级别：NONE、BASIC、HEADERS、FULLfeign.codec.Decoder响应结果的解析器http远程调用的结果做解析，例如解析json字符串为java对象feign.codec.Encoder哀求参数编码将哀求参数编码，便于通过http哀求发送feign. Contract支持的注解格式默认是SpringMVC的注解feign. Retryer失败重试机制哀求失败的重试机制，默认是没有，不外会利用Ribbon的重试一样平常情况下，默认值就能满足我们利用，如果要自定义时，只需要创建自定义的@Bean覆盖默认Bean即可。
下面以日志为例来演示如何自定义配置。
配置文件方式

基于配置文件修改feign的日志级别可以针对单个服务：

1. feign:  
2.   client:
3.     config:
4.       userservice: # 针对某个微服务的配置
5.         loggerLevel: FULL #  日志级别

复制代码

也可以针对所有服务：

1. feign:  
2.   client:
3.     config:
4.       default: # 这里用default就是全局配置，如果是写服务名称，则是针对某个微服务的配置
5.         loggerLevel: FULL #  日志级别

复制代码

而日志的级别分为四种：

• NONE：不记载任何日志信息，这是默认值。
  
• BASIC：仅记载哀求的方法，URL以及响应状态码和执行时间
  
• HEADERS：在BASIC的基础上，额外记载了哀求和响应的头信息
  
• FULL：记载所有哀求和响应的明细，包括头信息、哀求体、元数据。
  

Java代码方式

也可以基于Java代码来修改日志级别，先声明一个类，然后声明一个Logger.Level的对象：

1. public class DefaultFeignConfiguration  {
2.     @Bean
3.     public Logger.Level feignLogLevel(){
4.         return Logger.Level.BASIC; // 日志级别为BASIC
5.     }
6. }

复制代码

如果要全局见效，将其放到启动类的@EnableFeignClients这个注解中：

1. @EnableFeignClients(defaultConfiguration = DefaultFeignConfiguration .class)

复制代码

如果是局部见效，则把它放到对应的@FeignClient这个注解中：

1. @FeignClient(value = "userservice", configuration = DefaultFeignConfiguration .class)

复制代码

Feign利用优化

Feign底层发起http哀求，依靠于其它的框架。其底层客户端实现包括：

• URLConnection：默认实现，不支持连接池
  
• Apache HttpClient ：支持连接池
  
• OKHttp：支持连接池
  

因此提高Feign的性能主要手段就是利用连接池代替默认的URLConnection。
这里我们用Apache的HttpClient来演示。
引入依靠

在order-service的pom文件中引入Apache的HttpClient依靠：

1. <dependency>
2.     <groupId>io.github.openfeign</groupId>
3.     <artifactId>feign-httpclient</artifactId>
4. </dependency>

复制代码

配置连接池

在order-service的application.yml中添加配置：

1. feign:
2.   client:
3.     config:
4.       default: # default全局的配置
5.         loggerLevel: BASIC # 日志级别，BASIC就是基本的请求和响应信息
6.   httpclient:
7.     enabled: true # 开启feign对HttpClient的支持
8.     max-connections: 200 # 最大的连接数
9.     max-connections-per-route: 50 # 每个路径的最大连接数

复制代码

接下来，在FeignClientFactoryBean中的loadBalance方法中打断点：

Debug方式启动order-service服务，可以看到这里的client，底层就是Apache HttpClient：

总结，Feign的优化：

• 日志级别尽量用basic
  
• 利用HttpClient或OKHttp代替URLConnection
  
  
  • 引入feign-httpClient依靠
    
  • 配置文件开启httpClient功能，设置连接池参数
    
  
  

最佳实践

所谓最佳实践，就是利用过程中总结的经验，最好的一种利用方式。
Feign的客户端与服务提供者的controller代码非常相似：
feign客户端：

UserController：

有没有一种办法简化这种重复的代码编写呢？
继承方式

一样的代码可以通过继承来共享：

• 定义一个API接口，利用定义方法，并基于SpringMVC注解做声明。
  
• Feign客户端和Controller都集成改接口
  

优点：

• 简朴
  
• 实现了代码共享
  

缺点：

• 服务提供方、服务消耗方紧耦合
  
• 参数列表中的注解映射并不会继承，因此Controller中必须再次声明方法、参数列表、注解
  

抽取方式

将Feign的Client抽取为独立模块，而且把接口有关的POJO、默认的Feign配置都放到这个模块中，提供给所有消耗者利用。
例如，将UserClient、User、Feign的默认配置都抽取到一个feign-api包中，所有微服务引用该依靠包，即可直接利用。

抽取

首先创建一个module，定名为feign-api，
项目布局：

在feign-api中然后引入feign的starter依靠

1. <dependency>
2.     <groupId>org.springframework.cloud</groupId>
3.     <artifactId>spring-cloud-starter-openfeign</artifactId>
4. </dependency>

复制代码

然后，order-service中编写的UserClient、User、DefaultFeignConfiguration都复制到feign-api项目中
在order-service中利用feign-api

首先，删除order-service中的UserClient、User、DefaultFeignConfiguration等类或接口。
在order-service的pom文件中中引入feign-api的依靠：

1. <dependency>
2.     <groupId>cn.seven.demo</groupId>
3.     <artifactId>feign-api</artifactId>
4.     <version>1.0</version>
5. </dependency>

复制代码

修改order-service中的所有与上述三个组件有关的导包部分，改成导入feign-api中的包
重启测试

重启后，发现服务报错了
这是因为UserClient现在在cn.seven.feign.clients包下，
而order-service的@EnableFeignClients注解是在cn.seven.order包下，不在同一个包，无法扫描到UserClient。
解决扫描包问题

方式一：
指定Feign应该扫描的包：

1. @EnableFeignClients(basePackages = "cn.seven.feign.clients")

复制代码

方式二：
指定需要加载的Client接口：

1. @EnableFeignClients(clients = {UserClient.class})

复制代码

Gateway服务网关

Spring Cloud Gateway 项目是基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等响应式编程和事件流技术开发的网关，它旨在为微服务架构提供一种简朴有效的统一的 API 路由管理方式。
为什么需要网关

Gateway网关是我们服务的守门神，所有微服务的统一入口。
网关的核心功能特性：

• 哀求路由
  
• 权限控制
  
• 限流
  

架构图：

• 权限控制：网关作为微服务入口，需要校验用户是是否有哀求资格，如果没有则进行拦截。
  
• 路由和负载均衡：一切哀求都必须先经过gateway，但网关不处理业务，而是根据某种规则，把哀求转发到某个微服务，这个过程叫做路由。当然路由的目标服务有多个时，还需要做负载均衡。
  
• 限流：当哀求流量过高时，在网关中按照下游的微服务能够担当的速率来放行哀求，避免服务压力过大。
  

在SpringCloud中网关的实现包括两种：

• gateway
  
• zuul
  

Zuul是基于Servlet的实现，属于壅闭式编程。而SpringCloudGateway则是基于Spring5中提供的WebFlux，属于响应式编程的实现，具备更好的性能。
gateway快速入门

下面，我们就演示下网关的基本路由功能。基本步骤如下：

• 创建SpringBoot工程gateway，引入网关依靠
  
• 编写启动类
  
• 编写基础配置和路由规则
  
• 启动网关服务进行测试
  

引入依靠

1. <dependency>
2.     <groupId>org.springframework.cloud</groupId>
3.     <artifactId>spring-cloud-starter-gateway</artifactId>
4. </dependency>
6. <dependency>
7.     <groupId>com.alibaba.cloud</groupId>
8.     <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
9. </dependency>

复制代码

编写启动类

1. import org.springframework.boot.SpringApplication;
2. import org.springframework.boot.autoconfigure.SpringBootApplication;
4. @SpringBootApplication
5. public class GatewayApplication {
7.         public static void main(String[] args) {
8.                 SpringApplication.run(GatewayApplication.class, args);
9.         }
10. }

复制代码

编写基础配置和路由规则

创建application.yml文件，内容如下：

1. server:
2.   port: 10010 # 网关端口
3. spring:
4.   application:
5.     name: gateway # 服务名称
6.   cloud:
7.     nacos:
8.       server-addr: localhost:8848 # nacos地址
9.     gateway:
10.       routes: # 网关路由配置
11.         - id: user-service # 路由id，自定义，只要唯一即可
12.           # uri: http://127.0.0.1:8081 # 路由的目标地址 http就是固定地址
13.           uri: lb://userservice # 路由的目标地址 lb就是负载均衡，后面跟服务名称
14.           predicates: # 路由断言，也就是判断请求是否符合路由规则的条件
15.             - Path=/user/** # 这个是按照路径匹配，只要以/user/开头就符合要求

复制代码

我们将符合Path 规则的一切哀求，都署理到 uri参数指定的地址。
本例中，我们将 /user/**开头的哀求，署理到lb://userservice，lb是负载均衡，根据服务名拉取服务列表，实现负载均衡。
重启测试

重启网关，访问http://localhost:10010/user/1时，符合/user/**规则，哀求转发到uri：http://userservice/user/1，得到了结果：

网关路由的流程图

整个访问的流程如下：

总结：
网关搭建步骤：

• 创建项目，引入nacos服务发现和gateway依靠
  
• 配置application.yml，包括服务基本信息、nacos地址、路由
  

路由配置包括：

• 路由id：路由的唯一标示
  
• 路由目标（uri）：路由的目标地址，http代表固定地址，lb代表根据服务名负载均衡
  
• 路由断言（predicates）：判断路由的规则，
  
• 路由过滤器（filters）：对哀求或响应做处理
  

接下来，就重点来学习路由断言和路由过滤器的详细知识
断言工厂

我们在配置文件中写的断言规则只是字符串，这些字符串会被Predicate Factory读取并处理，转变为路由判断的条件
例如Path=/user/**是按照路径匹配，这个规则是由org.springframework.cloud.gateway.handler.predicate.PathRoutePredicateFactory类来处理的，像这样的断言工厂在SpringCloudGateway还有十几个:
名称阐明示例After是某个时间点后的哀求-  After=2037-01-20T17:42:47.789-07:00[America/Denver]Before是某个时间点之前的哀求-  Before=2031-04-13T15:14:47.433+08:00[Asia/Shanghai]Between是某两个时间点之前的哀求-  Between=2037-01-20T17:42:47.789-07:00[America/Denver],  2037-01-21T17:42:47.789-07:00[America/Denver]Cookie哀求必须包含某些cookie- Cookie=chocolate, ch.pHeader哀求必须包含某些header- Header=X-Request-Id, \d+Host哀求必须是访问某个host（域名）-  Host=.somehost.org,.anotherhost.orgMethod哀求方式必须是指定方式- Method=GET,POSTPath哀求路径必须符合指定规则- Path=/red/{segment},/blue/**Query哀求参数必须包含指定参数- Query=name, Jack大概-  Query=nameRemoteAddr哀求者的ip必须是指定范围- RemoteAddr=192.168.1.1/24Weight权重处理我们只需要掌握Path这种路由工程就可以了。
过滤器工厂

GatewayFilter是网关中提供的一种过滤器，可以对进入网关的哀求和微服务返回的响应做处理：

路由过滤器的种类

Spring提供了31种不同的路由过滤器工厂。例如：
名称阐明AddRequestHeader给当前哀求添加一个哀求头RemoveRequestHeader移除哀求中的一个哀求头AddResponseHeader给响应结果中添加一个响应头RemoveResponseHeader从响应结果中移除有一个响应头RequestRateLimiter限制哀求的流量哀求头过滤器

下面我们以AddRequestHeader 为例来讲解。

需求：给所有进入userservice的哀求添加一个哀求头：Truth=seven is freaking awesome!

只需要修改gateway服务的application.yml文件，添加路由过滤即可：

1. spring:
2.   cloud:
3.     gateway:
4.       routes:
5.       - id: user-service
6.         uri: lb://userservice
7.         predicates:
8.         - Path=/user/**
9.         filters: # 过滤器
10.         - AddRequestHeader=Truth, seven is freaking awesome! # 添加请求头

复制代码

当前过滤器写在userservice路由下，因此仅仅对访问userservice的哀求有效。
默认过滤器

如果要对所有的路由都见效，则可以将过滤器工厂写到default下。格式如下：

1. spring:
2.   cloud:
3.     gateway:
4.       routes:
5.       - id: user-service
6.         uri: lb://userservice
7.         predicates:
8.         - Path=/user/**
9.       default-filters: # 默认过滤项
10.       - AddRequestHeader=Truth, seven is freaking awesome!

复制代码

总结

过滤器的作用是什么？

• 对路由的哀求或响应做加工处理，好比添加哀求头
  
• 配置在路由下的过滤器只对当前路由的哀求见效
  

defaultFilters的作用是什么？对所有路由都见效的过滤器
全局过滤器

过滤器，网关提供了31种，但每一种过滤器的作用都是固定的。如果我们希望拦截哀求，做本身的业务逻辑则没办法实现。
全局过滤器作用

全局过滤器的作用也是处理一切进入网关的哀求和微服务响应，与GatewayFilter的作用一样。区别在于GatewayFilter通过配置定义，处理逻辑是固定的；而GlobalFilter的逻辑需要本身写代码实现。
定义方式是实现GlobalFilter接口。

1. public interface GlobalFilter {
2.     /**
3.      *  处理当前请求，有必要的话通过{@link GatewayFilterChain}将请求交给下一个过滤器处理
4.      *
5.      * @param exchange 请求上下文，里面可以获取Request、Response等信息
6.      * @param chain 用来把请求委托给下一个过滤器
7.      * @return {@code Mono<Void>} 返回标示当前过滤器业务结束
8.      */
9.     Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain);
10. }

复制代码

在filter中编写自定义逻辑，可以实现下列功能：

• 登录状态判断
  
• 权限校验
  
• 哀求限流等
  

自定义全局过滤器

需求：定义全局过滤器，拦截哀求，判断哀求的参数是否满足下面条件：

• 参数中是否有authorization，
  
• authorization参数值是否为admin
  

如果同时满足则放行，否则拦截
实现：在gateway中定义一个过滤器：

1. import org.springframework.cloud.gateway.filter.GatewayFilterChain;
2. import org.springframework.cloud.gateway.filter.GlobalFilter;
3. import org.springframework.core.annotation.Order;
4. import org.springframework.http.HttpStatus;
5. import org.springframework.stereotype.Component;
6. import org.springframework.web.server.ServerWebExchange;
7. import reactor.core.publisher.Mono;
9. @Order(-1)
10. @Component
11. public class AuthorizeFilter implements GlobalFilter {
12.     @Override
13.     public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
14.         // 1.获取请求参数
15.         MultiValueMap<String, String> params = exchange.getRequest().getQueryParams();
16.         // 2.获取authorization参数
17.         String auth = params.getFirst("authorization");
18.         // 3.校验
19.         if ("admin".equals(auth)) {
20.             // 放行
21.             return chain.filter(exchange);
22.         }
23.         // 4.拦截
24.         // 4.1.禁止访问，设置状态码
25.         exchange.getResponse().setStatusCode(HttpStatus.FORBIDDEN);
26.         // 4.2.结束处理
27.         return exchange.getResponse().setComplete();
28.     }
29. }

复制代码

过滤器执行顺序

哀求进入网关会碰到三类过滤器：当前路由的过滤器、DefaultFilter、GlobalFilter
哀求路由后，会将当前路由过滤器和DefaultFilter、GlobalFilter，合并到一个过滤器链（集合）中，排序后依次执行每个过滤器：

排序的规则是什么呢？

• 每一个过滤器都必须指定一个int类型的order值，order值越小，优先级越高，执行顺序越靠前。
  
• GlobalFilter通过实现Ordered接口，大概添加@Order注解来指定order值，由我们本身指定
  
• 路由过滤器和defaultFilter的order由Spring指定，默认是按照声明顺序从1递增。
  
• 当过滤器的order值一样时，会按照 defaultFilter > 路由过滤器 > GlobalFilter的顺序执行。
  

详细内容，可以查看源码：
org.springframework.cloud.gateway.route.RouteDefinitionRouteLocator#getFilters()方法是先加载defaultFilters，然后再加载某个route的filters，然后合并。
org.springframework.cloud.gateway.handler.FilteringWebHandler#handle()方法会加载全局过滤器，与前面的过滤器合并后根据order排序，组织过滤器链
跨域问题

什么是跨域问题

跨域：域名不一致就是跨域，主要包括：

• 域名不同： www.taobao.com 和 www.taobao.org 和 www.jd.com 和 miaosha.jd.com
  
• 域名相同，端口不同：localhost:8080和localhost:8081
  

跨域问题：欣赏器禁止哀求的发起者与服务端发生跨域ajax哀求，哀求被欣赏器拦截的问题
解决方案：CORS，这里不再赘述了，不知道的小伙伴可以查看https://www.ruanyifeng.com/blog/2016/04/cors.html
模拟跨域问题

可以在欣赏器控制台看到下面的错误：

从localhost:8090访问localhost:10010，端口不同，显然是跨域的哀求。
解决跨域问题

在gateway服务的application.yml文件中，添加下面的配置：

1. spring:
2.   cloud:
3.     gateway:
4.       # ...
5.       globalcors: # 全局的跨域处理
6.         add-to-simple-url-handler-mapping: true # 解决options请求被拦截问题
7.         corsConfigurations:
8.           '[/**]':
9.             allowedOrigins: # 允许哪些网站的跨域请求
10.               - "http://localhost:8090"
11.             allowedMethods: # 允许的跨域ajax的请求方式
12.               - "GET"
13.               - "POST"
14.               - "DELETE"
15.               - "PUT"
16.               - "OPTIONS"
17.             allowedHeaders: "*" # 允许在请求中携带的头信息
18.             allowCredentials: true # 是否允许携带cookie
19.             maxAge: 360000 # 这次跨域检测的有效期

复制代码

往期保举

• 《SpringBoot》EasyExcel实现百万数据的导入导出
  
• 《SpringBoot》史上最全SpringBoot相干注解介绍
  
• Spring框架IoC核心详解
  
• 万字长文带你窥伺Spring中所有的扩展点
  
• 如何实现一个通用的接口限流、防重、防抖机制
  
• 万字长文带你深入Redis底层数据布局
  
• volatile关键字最全原理分析
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 qidao123.com技术社区-IT企服评测·应用市场 (https://dis.qidao123.com/)

Powered by Discuz! X3.4