目录
一、系统架构演变
1.1集中式架构
1.2垂直拆分
1.3分布式服务
1.4面向服务架构(SOA)
1.5微服务架构
二、服务调用方式
2.1RPC和HTTP
2.2HTTP客户端工具
三、SpringCloud
3.1简介
3.2SpringCloud整合的组件和版本特征
四、微服务场景模拟
4.1父工程
4.2用户服务工程
4.3服务消费工程
4.4存在的问题
五、Eureka注册中心说明
5.1认识Eureka
5.2原理图
5.3入门案例
5.3.1搭建eurekaServer工程
5.3.2服务注册
5.3.3服务发现
5.4Eureka详解
5.4.1基础架构
5.4.2高可用的EurekaServer
5.4.3Eureka客户端
5.4.4失效剔除和自我保护
六、负载均衡Ribbon
七、熔断器Hystrix
7.1Hystrix简介
7.2雪崩问题
7.3线程隔离和服务降级
7.3.1原理
7.3.2实践
7.3.3默认服务降级处理方法
7.3.4超时设置
7.4服务熔断
7.4.1熔断原理
7.4.2熔断实现
在项目开发中,随着业务越来越多导致功能之间耦合性高,开发效率低,系统运行缓慢难以维护及不稳定等,而微服务架构可以避免或者解决这些问题,而SpringCloud是微服务架构的实现,所以今天我们一起来学习一下SpringCloud。
随着互联网的发展,网站应用的规模不断扩大。需求的激增,带来的是技术上的压力。
系统架构也因此也不断的演进、升级、迭代。从单一应用,到垂直拆分,到分布式服务,到SOA,以及现在火热的微服务架构,还有在Google带领下来势汹涌的Service Mesh。所以我们今天就回顾历史,看一看系统架构演变的历程。
当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本,
当访问量逐渐增大,单一应用无法满足需求,此时为了应对更高的并发和业务需求,我们根据业务功能对系统进行拆分:
当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。
SOA(Service Oriented Architecture)面向服务的架构:它是一种设计方法,其中包含多个服务, 服务之间通过相互依赖最终提供一系列的功能。
一个服务通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用。
SOA结构图如下:
ESB(企业服务总线),简单来说ESB就是一根管道,用来连接各个服务节点。为了集成不同系统,不同协议的服务,ESB 做了消息的转化解释和路由工作,让不同的服务互联互通。
SOA缺点:每个供应商提供的ESB产品有偏差,自身实现较为复杂;应用服务粒度较大,ESB集成整合所有服务和协议、数据转换使得运维、测试部署困难。所有服务都通过一个通路通信,直接降低了通信速度。
微服务架构是使用一套小服务来开发单个应用的方式或途径,
每个服务基于单一业务能力构建,运行在自己的进程中,并使用轻量级机制通信,通常是HTTP API,并能够通过自动化部署机制来独立部署。
这些服务可以使用不同的编程语言实现,以及不同数据存储技术,并保持最低限度的集中式管理。
微服务结构图:
API Gateway网关是一个服务器,是系统的唯一入口。为每个客户端提供一个定制的API。
API网关的核心是所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。如它还可以具有其它职责,如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。
网关提供RESTful/HTTP的方式访问服务。而服务端通过服务注册中心进行服务注册和管理。
微服务架构与SOA都是对系统进行拆分:微服务架构基于SOA思想,可以把微服务当做去除了ESB的SOA。ESB是SOA架构中的中心总线,设计图形应该是星形的,而微服务是去中心化的分布式软件架构。两者比较类似,但其实也有一些差别:
功能 | SOA | 微服务 |
---|---|---|
组件大小 | 大块业务逻辑 |
单独任务或小块业务逻辑 |
耦合 | 通常松耦合 | 松耦合 |
管理 | 着重中央管理 | 着重分散管理 |
目标 | 确保应用能够交互操作 | 易维护、易扩展、更轻量级的交互 |
无论是微服务还是SOA,都面临着服务间的远程调用。
那么服务间的远程调用方式有哪些呢?常见的远程调用方式有以下2种:
现在热门的Rest风格,就可以通过http协议来实现。
区别:RPC的机制是根据语言的API(language API)来定义的,而不是根据基于网络的应用来定义的。如果业务全部采用Java技术栈,那么使用Dubbo作为微服务架构是一个不错的选择。
相反,如果技术栈多样化,而且你更青睐Spring家族,那么SpringCloud搭建微服务是不二之选。在我们的项目中,会选择SpringCloud套件,因此会使用Http方式来实现服务间调用。
既然微服务选择了Http,那么我们就需要考虑自己来实现对请求和响应的处理。不过开源世界已经有很多的http客户端工具,能够帮助我们做这些事情,例如:
不过这些不同的客户端,API各不相同。而Spring也有对http的客户端进行封装,提供了工具类叫RestTemplate。
微服务是一种架构方式,最终肯定需要技术架构去实施。
微服务的实现方式很多,但是最火的莫过于SpringCloud了。其原因主要有以下几点:
Spring Cloud是Spring旗下的项目之一,官网地址:https://spring.io/projects/spring-cloud,Spring最擅长的就是集成,把世界上最好的框架拿过来,集成到自己的项目中。
SpringCloud也是一样,它将现在非常流行的一些技术整合到一起,实现了诸如:配置管理,服务发现,智能路由,负载均衡,熔断器,控制总线,集群状态等功能;协调分布式环境中各个系统,为各类服务提供模板性配置。其主要涉及的组件包括:
以上只是其中一部分,架构图:
Spring Cloud不是一个组件,而是许多组件的集合,常见的组件有:eureka注册中心,Gateway网关,Ribbon负载均衡,Feign服务调用,Hystrix熔断器。在有需要的时候项目添加对于的启动器依赖即可。
它的版本命名比较特殊,是以A到Z的为首字母的一些单词(其实是伦敦地铁站的名字)组成。
首先,我们需要模拟一个服务调用的场景。方便后面学习微服务架构,
假设我们现在有这样一个需求:查询数据库中的用户数据并输出到浏览器,我们一共创建三个工程,父工程springcloudDemo、用户服务工程user-service和服务消费工程consumer-demo
第一步我们创建父工程springcloudDemo,微服务中需要同时创建多个项目,先创建一个父工程,然后后续的工程都以这个工程为父,实现maven的聚合。在实际开发中,每个微服务可独立一个工程。
创建好了之后我们修改父工程的pom.xml文件(提取码:q6g4),对后续要用到的依赖的版本进行了管理。
我们创建一个用户服务工程userService,作为springcloudDemo父工程的子工程,该工程需要提供根据id查询数据库中的用户功能,用户通过访问url来输出用户的数据,
其实现步骤为:
第一步我们在userService工程的pom.xml中添加启动器依赖,
org.springframework.boot
spring-boot-starter-web
tk.mybatis
mapper-spring-boot-starter
mysql
mysql-connector-java
第二步我们创建启动引导类和配置文件,首先我们创建启动引导类,
@SpringBootApplication
@MapperScan("com.laotang.user.mapper")//指定mapper扫描的包路径
public class UserApplication {
public static void main(String[] args) {
SpringApplication.run(UserApplication.class, args);
}
}
然后是生成application.yml配置文件,
#配置数据源连接参数
spring:
datasource:
driver-class-name: com.mysql.jdbc.Driver
url: jdbc:mysql://localhost:3306/mydb1
username: root
password: 3837
# mybatis配置
mybatis:
# 实体类别名包路径
type-aliases-package: com.laotang.user.pojo
#修改端口号,避免和其他工程冲突
server:
port: 9091
这里我们还是用之前定义的User实体类以及数据库中的user表进行实验。dao层已经弄好了,接下来是mapper接口的定义,
import com.laotang.user.pojo.User;
import tk.mybatis.mapper.common.Mapper;
public interface UserMapper extends Mapper {
}
然后是service业务层的代码编写,
@Service
public class UserService {
@Autowired
private UserMapper userMapper;
public User findById(Long id){
return userMapper.selectByPrimaryKey(id);//利用通用mapper的查询主键方法来查询user
}
}
接着是controller层,处理url和对应方法的执行,
@RestController//相当于@ResponseBody + @Controller
@RequestMapping("/user")
public class UserController {
@Autowired
private UserService userService;
@GetMapping("/{id}")
public User findById(@PathVariable Long id){
return userService.findById(id);
}
}
都写好之后我们启动main方法,访问http://localhost:9091/user/4,
接下来我们创建服务消费工程consumerDemo,编写测试类使用RestTemplate访问userService工程的路径,根据id查询用户,
换句话说,就是可以访问http://localhost:8080/consumer/4时,使用RestTemplate获取http://localhost:9091/user/4的数据。
实现步骤如下:
首先第一步我们还是在consumerDemo工程中添加启动器依赖,
org.springframework.boot
spring-boot-starter-web
然后我们创建该工程的启动引导类,
@SpringBootApplication
public class ConsumerApplication {
public static void main(String[] args) {
SpringApplication.run(ConsumerApplication.class, args);
}
@Bean
public RestTemplate restTemplate(){
return new RestTemplate();
}
}
接着编写controller的ConsumerController,使用RestTemplate访问服务获取数据,
@RestController
@RequestMapping("/consumer")
public class ConsumerController {
@Autowired
private RestTemplate restTemplate;
@GetMapping("/{id}")
public User findById(@PathVariable Long id){
String url="http://localhost:9091/user/"+id;//指定要访问的url
return restTemplate.getForObject(url, User.class);//访问url得到数据并返回
}
}
然后我们就可以启动引导类的main方法了,(注意启动前需要先启动userService的引导类main方法),输入我们要访问的地址http://localhost:8080/consumer/4,
我们成功在该工程中访问到了另一个工程的方法。
简单回顾一下,刚才我们写了两个工程:
userService:对外提供了查询用户的接口
consumerDemo:通过RestTemplate访问http://locahost:9091/user/{id} 接口,查询用户数据
上述实验中主要有以下几个问题:
其实上面说的问题,概括一下就是分布式服务必然要面临的问题:
以上的这些问题,都将在SpringCloud中得到答案。
首先我们来解决第一个问题,服务的管理。
在刚才的案例中,userService对外提供服务,需要对外暴露自己的地址。
而consumer-demo(调用者)需要记录服务提供者的地址。将来地址出现变更时需要及时更新。
这在服务较少的时候并不觉得有什么,但是在现在日益复杂的互联网环境,一个项目可能会拆分出十几,甚至几十个微服务。此时如果还人为管理地址,不仅开发困难,将来测试、发布上线都会非常麻烦,这与DevOps的思想是背道而驰的。(DevOps的思想是系统可以通过一组过程、方法或系统,去提高应用发布和运维的效率,降低管理成本)
例如在网约车出现以前,人们出门叫车只能叫出租车。
一些私家车想做出租却没有资格,被称为黑车。而很多人想要约车,但是无奈出租车太少,不方便。私家车很多却不敢拦,而且满大街的车,谁知道哪个才是愿意载人的。一个想要,一个愿意给,就是缺少引子,缺乏管理啊。
此时滴滴这样的网约车平台出现了,所有想载客的私家车全部到滴滴注册,记录你的车型(服务类型),身份信息(联系方式)。这样提供服务的私家车,在滴滴那里都能找到,一目了然。此时要叫车的人,只需要打开APP,输入你的目的地,选择车型(服务类型),滴滴自动安排一个符合需求的车到你面前为你服务。
Eureka就好比是滴滴,负责管理、记录服务提供者的信息。
服务调用者无需自己寻找服务,而是把自己的需求告诉Eureka,然后Eureka会把符合你需求的服务告诉你。
同时,服务提供方与Eureka之间通过“心跳” 机制进行监控,当某个服务提供方出现问题,Eureka自然会把它从服务列表中剔除。这就实现了服务的自动注册、发现、状态监控。
Eureka的基本架构图如下:
Eureka是服务注册中心,只做服务注册,自身并不提供服务也不消费服务。那么首先我们就需要搭建服务注册中心,即搭建一个eurekaServer的工程。
我们可以利用SpringBoot的方式搭建web工程使用Eureka进行学习,实现步骤如下:
首先我们创建eurekaServer工程,然后在pom.xml中添加eureka的启动器依赖,
org.springframework.cloud
spring-cloud-starter-netflix-eureka-server
然后我们编写启动引导类,注意要添加eureka的服务注解,
@EnableEurekaServer//生命当前应用是Eureka服务
@SpringBootApplication//指定当前类为SpringBoot项目启动引导类
public class EurekaServerApplication {
public static void main(String[] args) {
SpringApplication.run(EurekaServerApplication.class, args);
}
}
然后我们对配置项进行修改,配置端口以及eureka的一些配置,
server:
port: 10086
#设置当前应用的名称
spring:
application:
name: eurekaServer
eureka:
client:
service-url:
#eureka提供的服务地址(供其他服务进行访问),如果是集群的话,需要指定其他集群eureka地址
defaultZone: http://127.0.0.1:10086/eureka
#不注册自己到服务中
register-with-eureka: false
#不拉取服务
fetch-registry: false
配置好了之后我们直接启动引导类,输入http://localhost:10086/,看到如下界面就算配置成功了,
我们把eurekaServer服务注册中心搭建好了,下一步就是在实现服务然后在注册中心进行注册,我们直接将userService模块的服务注册到eureka中,并在consumerDemo模块通过服务名称调用。
首先我们要把userService模块的服务注册到eureka中,这里就要用到服务注册。
服务注册,就是在服务上添加Eureka的客户端依赖,客户端代码会自动把服务注册到EurekaServer中,其主要步骤如下:
第一步我们在userService模块的pom.xml中添加eureka依赖,
org.springframework.cloud
spring-cloud-starter-netflix-eureka-server
然后修改启动引导类,添加开启eureka客户端发现的注解,
@SpringBootApplication
@MapperScan("com.laotang.user.mapper")//指定mapper扫描的包路径
@EnableDiscoveryClient//开启eureka客户端发现功能
public class UserApplication {
public static void main(String[] args) {
SpringApplication.run(UserApplication.class, args);
}
}
接着修改配置文件,设置eureka服务地址,然后给该服务起一个名,
spring:
application:
name: userService
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
配置好了之后我们启动userService服务的启动类(前提先启动eureka注册中心服务类),我们再访问eureka注册中心就可以看到刚刚注册的服务了,application的名字就是我们配置的,
注册完了userService模块的服务,我们想在consumerDemo模块中调用服务,需要服务发现。
服务发现,也要在服务上添加Eureka的客户端依赖,这样就可以使用工具类根据服务名称获取对应的服务地址列表,其主要步骤如下:
第一步还是在consumerDemo模块中添加eureka的依赖,
org.springframework.cloud
spring-cloud-starter-netflix-eureka-server
然后修改启动引导类,同样需要添加eureka的注解,
@EnableDiscoveryClient//开启eureka客户端发现功能
然后是修改配置文件,设置eureka的服务地址,
#设置应用名字
spring:
application:
name: consumerDemo
#设置eureka服务地址
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
最后我们还需要修改处理器类ConsumerController,使用工具类DiscoveryClient根据服务名称获取对应服务地址列表,
@RestController
@RequestMapping("/consumer")
public class ConsumerController {
@Autowired
private RestTemplate restTemplate;
@Autowired
private DiscoveryClient discoveryClient;
@GetMapping("/{id}")
public User findById(@PathVariable Long id) {
List serviceInstances = discoveryClient.getInstances("userService");//通过应用名获取eureka中注册的userService实例
ServiceInstance userService = serviceInstances.get(0);//获取一个实例
String url = "http://" + userService.getHost() + ":" + userService.getPort() + "/user/" + id;//动态获取服务地址
return restTemplate.getForObject(url, User.class);//访问url得到数据并返回
}
}
然后我们启动consumerDemo的启动类,输入url可以看到查询到了id=1的用户信息,
Eureka架构中的三个核心角色:
EurekaServer即服务的注册中心,在刚才的案例中,我们只有一个EurekaServer,
但是EurekaServer是一个web应用,可以启动多个实例(配置不同端口避免启动冲突),所以EurekaServer也可以是一个集群,形成高可用的Eureka中心。
多个Eureka Server之间也会互相注册为服务,当服务提供者注册到EurekaServer集群中的某个节点时,该节点会把服务的信息同步给集群中的每个节点,从而实现数据同步。
因此无论客户端访问到EurekaServer集群中的哪个节点,都可以获取到完整的服务列表信息。
而作为客户端,需要把信息注册到每个Eureka中:
例如如果有三个Eureka,则每一个EurekaServer都需要注册到其它几个Eureka服务中,例如:有三个分别为10086、10087、10088,则:
我们现在来试一下,假设要搭建两台EurekaServer的集群,端口分别为10086和10087,那么首先我们要修改一下eurekaServer工程的配置文件,
server:
port: ${port:10086}
#设置当前应用的名称
spring:
application:
name: eurekaServer
eureka:
client:
service-url:
#eureka提供的服务地址(供其他服务进行访问),如果是集群的话,需要指定其他集群eureka地址
defaultZone: ${defaultZone:http://127.0.0.1:10086/eureka}
#做eureka集群时,需要注册自己到服务中,让别的eureka发现自己
register-with-eureka: true
#从eureka集群拉取服务
fetch-registry: true
然后对eurekaServer的启动项进行配置,
这里我们点开Environment,配置VM options启动参数,
配置好10086的eureka服务后,我们复制生成端口号为10087的eureka服务,
复制后我们修改一下名字,同样对VM options启动参数进行配置,
选择应用之后,我们先启动10086端口的eureka服务,然后我们再启动10087端口的eureka服务,
这样我们的高可用Eureka中心就搭建好了,接下来我们将userService服务启动,注册到10086端口的eureka中心,但是我们可以看到,由于eurekaServer是集群,所以当服务注册到某一个eureka上时,也会注册到集群的其他eurekaServer上,
此时可以看到两个eurekaServer上面都有userService服务,
同时我们还可以在注册服务时就指定多个注册地址,这样当一个注册中心不可用时保证可以正常注册到eureka服务中心上,
eureka:
client:
service-url:
#指定服务注册时eureka的多个注册地址
defaultZone: http://127.0.0.1:10086/eureka,http://127.0.0.1:10087/eureka
服务提供者要向EurekaServer注册服务,并且完成服务续约等工作。服务消费者则向EurekaServer拉取服务,获得想要的服务。
1、服务注册
服务提供者在启动时,会检测配置属性中的: eureka.client.register-with-erueka=true 参数是否正确,事实上默认就是true。如果值确实为true,则会向EurekaServer发起一个Rest请求,并携带自己的元数据信息,EurekaServer会把这些信息保存到一个双层Map结构中。
默认注册时使用的是主机名或者localhost,如果想用ip进行注册,可以在userService 中添加配置如下:
eureka:
instance:
ip-address: 127.0.0.1 # 指定ip地址
prefer-ip-address: true # 更倾向于使用ip,而不是host名
2、服务续约
在注册服务完成以后,服务提供者会维持一个心跳(定时向EurekaServer发起Rest请求),告诉EurekaServer该服务还处于有效状态,这个我们称为服务的续约(renew)。
有两个重要参数可以修改服务续约的行为,可以在 user-service 中添加如下配置项:
eureka:
instance:
lease-expiration-duration-in-seconds: 90 # 若到了该续约的时间未续约,会继续等待90s才失效
lease-renewal-interval-in-seconds: 30 # 每次服务续约的间隔时间
也就是说,默认情况下每隔30秒服务会向注册中心发送一次心跳,证明自己还活着。如果超过90秒没有发送心跳,EurekaServer就会认为该服务宕机,会定时(eureka.server.eviction-interval-timer-in-ms设定的时间)从服务列表中移除,这两个值在生产环境不要修改,默认即可。
3、获取服务列表
当服务消费者启动时,会检测eureka.client.fetch-registry=true 参数的值,
如果为true,则会从EurekaServer服务的列表拉取只读备份,然后缓存在本地。并且每隔30秒会重新拉取并更新数据。可以在consumer-demo项目中通过下面的参数来修改:
eureka:
client:
registry-fetch-interval-seconds: 30
下面的配置都是在Eureka Server服务端进行的。
1、服务下线
当服务进行正常关闭操作时,它会触发一个服务下线的REST请求给Eureka Server,告诉服务注册中心:“我要下线了”。服务中心接受到请求之后,将该服务置为下线状态。
2、失效剔除
有时我们的服务可能由于内存溢出或网络故障等原因使得服务不能正常的工作,而服务注册中心并未收到“服务下线”的请求。
相对于服务提供者的“服务续约”操作,服务注册中心在启动时会创建一个定时任务,默认每隔一段时间(默认为60秒)将当前清单中超时(默认为90秒)没有续约的服务剔除,这个操作被称为失效剔除。
可以通过eureka.server.eviction-interval-timer-in-ms 参数对其进行修改,单位是毫秒,
3、自我保护
我们关停一个服务,很可能会在Eureka面板看到一条警告:
这是触发了Eureka的自我保护机制。
当服务未按时进行心跳续约时,Eureka会统计服务实例最近15分钟心跳续约的比例是否低于了85%。
在实际生产环境下,因为网络延迟等原因,心跳失败实例的比例很有可能超标,但是此时就把服务剔除列表并不妥当,因为服务可能没有宕机。Eureka在这段时间内不会剔除任何服务实例,直到网络恢复正常。
在实际工作中这很有效,保证了大多数服务依然可用,不过也有可能获取到失败的服务实例,因此服务调用者必须做好服务的失败容错。
可以通过下面的配置来关停自我保护:
eureka:
server:
enable-self-preservation: false # 关闭自我保护模式(缺省为打开)
在刚才的案例中,我们启动了一个userService服务,然后通过DiscoveryClient来获取服务实例信息,然后获取ip和端口来访问服务,
但是实际环境中,往往会开启很多个userService的集群。此时获取的服务列表中就会有多个,消费者到底该访问哪一个呢?一般这种情况下就需要写负载均衡算法,在多个实例列表中进行选择。
负载均衡是一个算法,可以通过该算法实现从地址列表中获取一个地址进行服务调用。
而在Eureka中已经集成了负载均衡组件:Ribbon,简单修改代码即可使用复杂均衡。
Ribbon是Netflix 发布的负载均衡器,它有助于控制HTTP和TCP客户端的行为。
为Ribbon配置服务提供者地址列表后,Ribbon就可基于某种负载均衡算法,自动地帮助服务消费者去请求。
Ribbon默认为我们提供了很多的负载均衡算法,例如轮询、随机等。当然,我们也可为Ribbon实现自定义的负载均衡算法。
接下来,我们就来使用Ribbon实现负载均衡,主要步骤如下:
首先第一步要测试负载均衡,就先要有多个服务实例,这里我们配置启动两个userService 实例,一个端口号为9091,另一个端口号为9092。我们先修改userService的配置文件,
#如果有提供端口,则使用提供的端口,否则使用默认的9091端口
server:
port: ${port:9091}
然后修改UserApplication的配置项,
修改好了之后再复制一个,修改端口号为9092,
全部修改好了之后点击应用,分别启动这两个服务实例(先启动eurekaServer),可以看到已经注册到eurekaServer中心了。
接下来我们就开始使用Ribbon进行负载均衡,因为Eureka中已经集成了Ribbon,所以我们无需引入新的依赖。我们直接修改consumerDemo消费工程启动类的RestTemplate实例化方法,在RestTemplate的配置方法上添加@LoadBalanced 注解:
@Bean
@LoadBalanced//添加负载均衡注解
public RestTemplate restTemplate(){
return new RestTemplate();
}
然后修改ConsumerController的方法,
@GetMapping("/{id}")
public User findById(@PathVariable Long id) {
String url = "http://userService/user/" + id;//使用服务名进行访问
return restTemplate.getForObject(url, User.class);//访问url得到数据并返回
}
启动consumerDemo消费者工程, 访问url查询用户信息,
看到这里大家是不是觉得有点奇怪,为什么只用service名称就可以访问了,之前不是一直用的ip和端口号吗,
String url = "http://userService/user/" + id
显然是有组件根据service名称,获取到了服务实例的ip和端口。
因为consumerDemo使用的是RestTemplate,spring的负载均衡自动配置类 LoadBalancerAutoConfiguration.LoadBalancerInterceptorConfig 会自动配置负载均衡拦截器(在spring-cloud-commons-**.jar包中的spring.factories中定义的自动配置类)
它就是LoadBalancerInterceptor ,这个类会在对RestTemplate的请求进行拦截,然后从Eureka根据服务id获取服务列表,随后利用负载均衡算法得到真实的服务地址信息,替换服务id。
并且Ribbon使用的默认负载均衡算法是轮循,即第一次先访问9091的服务,第二次就访问9092的服务,第三次9091,第四次9092,以此循环。
SpringBoot也帮提供了修改负载均衡规则的配置入口在consumerDemo的配置文件中添加如下,就变成随机的了:
userService:
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
格式是: {服务名称}.ribbon.NFLoadBalancerRuleClassName
Hystrix 在英文里面的意思是 豪猪,它的logo是一头豪猪,它在微服务系统中是一款提供保护机制的组件,和eureka一样也是由netflix公司开发。
Hystrix是开源的一个延迟和容错库,用于隔离访问远程服务、第三方库,防止出现级联失败。
微服务中,服务间调用关系错综复杂,一个请求,可能需要调用多个微服务接口才能实现,会形成非常复杂的调用链路:
如图,一次业务请求,需要调用A、P、H、I四个服务,这四个服务又可能调用其它服务。如果此时,服务 I 出现异常:
微服务 I 发生异常,请求阻塞,用户请求就不会得到响应,则tomcat的这个线程不会释放,于是越来越多的用户请求到来,越来越多的线程会阻塞:
服务器支持的线程和并发数有限,请求一直阻塞,会导致服务器资源耗尽,从而导致所有其它服务都不可用,形成雪崩效应。
这就好比,一个汽车生产线,生产不同的汽车,需要使用不同的零件。
如果某个零件因为种种原因无法使用,那么就会造成整台车无法装配,陷入等待零件的状态,直到零件到位,才能继续组装。
此时如果有很多个车型都需要这个零件,那么整个工厂都将陷入等待的状态,导致所有生产都陷入瘫痪。一个零件的波及范围不断扩大。
Hystrix解决雪崩问题的手段主要是服务降级,包括:
线程隔离示意图:
服务降级:优先保证核心服务,而非核心服务不可用或弱可用。
用户的请求故障时,不会被阻塞,更不会无休止的等待或者看到系统崩溃,至少可以看到一个执行结果(例如返回友好的提示信息) 。
服务降级虽然会导致请求失败,但是不会导致阻塞,而且最多会影响这个依赖服务对应的线程池中的资源,对其它服务没有响应。
触发Hystrix服务降级的情况:
首先第一步我们在consumerDemo消费者工程的pom.xml文件中添加hystrix的依赖,
org.springframework.cloud
spring-cloud-starter-netflix-hystrix
接着我们在启动类上添加注解@EnableCircuitBreaker 开启熔断,
@SpringBootApplication
@EnableDiscoveryClient//开启eureka客户端发现功能
@EnableCircuitBreaker//开启熔断
public class ConsumerApplication {
//...
}
可以看到,我们类上的注解越来越多,在微服务中,经常会引入上面的三个注解,于是Spring就提供了一个组合注解:@SpringCloudApplication
@SpringCloudApplication//上述三个的组合注解
public class ConsumerApplication {
//...
}
第二步我们编写降级的逻辑,当目标服务的调用出现故障,我们希望快速失败,给用户一个友好提示。因此需要提前编写好失败时的降级处理逻辑,要使用HystrixCommand来完成。
这里我们修改ConsumerController处理器的处理方法,加上注解@HystrixCommand,
@HystrixCommand(fallbackMethod = ""):用来声明一个降级逻辑的方法
要注意,因为熔断的降级逻辑方法必须跟正常逻辑方法保证:相同的参数列表和返回值声明。
由于之前我们方法的返回值是User对象,所以如果要保持一致,降级逻辑方法也要返回User对象,但是失败逻辑中返回User对象没有太大意义,一般会返回友好提示。
所以把findById的方法改造为返回String,反正也是Json数据。这样失败逻辑中返回一个错误说明,会比较方便。
@RestController
@RequestMapping("/consumer")
@Slf4j
public class ConsumerController {
@Autowired
private RestTemplate restTemplate;
@Autowired
private DiscoveryClient discoveryClient;
@GetMapping("/{id}")
@HystrixCommand(fallbackMethod = "findByIdFallback")//指定降级逻辑的方法
public String findById(@PathVariable Long id) {
String url = "http://userService/user/" + id;//利用负载均衡获取服务
return restTemplate.getForObject(url, String.class);//访问url得到数据并返回
}
public String findByIdFallback(Long id){
log.error("查询用户信息失败。id:{}", id);
return "服务忙,请稍后访问!";
}
}
第三步我们进行测试,我们重新启动一下consumerDemo的启动类,当userService正常提供服务时,访问和以前一直,当userService服务宕机时,会发现页面返回了降级处理的信息,
这里我们把fallback写在了某个业务方法上,如果要降级的方法很多,就要写很多的降级处理方法。
为了解决这个问题,我们可以把Fallback配置加在类上,实现默认fallback(没有指定降级处理的方法,如果访问失败时会执行默认的fallback方法)。
这里我们对ConsumerController类进行修改,使用@HystrixCommand 注解开启服务降级,但是不给findById()方法指定降级处理方法,写一个默认的方法,
@RestController
@RequestMapping("/consumer")
@Slf4j
@DefaultProperties(defaultFallback = "defaultFallback")//指定默认的降级处理方法
public class ConsumerController {
@Autowired
private RestTemplate restTemplate;
@Autowired
private DiscoveryClient discoveryClient;
@GetMapping("/{id}")
@HystrixCommand//开启熔断服务降级
public String findById(@PathVariable Long id) {
String url = "http://userService/user/" + id;//动态获取服务地址
return restTemplate.getForObject(url, String.class);//访问url得到数据并返回
}
public String defaultFallback(){
return "默认提示:服务忙!";
}
}
@DefaultProperties(defaultFallback = "defaultFallBack"):在类上指明统一的失败降级方法,该类中所有方法返回类型要与处理失败的方法的返回类型一致。
运行启动类,访问url可以看到默认的提示,
在之前的案例中,请求在超过1秒后都会返回错误信息,
这是因为Hystrix的默认超时时长为1,我们可以修改consumerDemo的配置文件进行设置,
hystrix:
command:
default:
execution:
isolation:
thread:
#设置默认超时时间为2000ms,即2s
timeoutInMilliseconds: 2000
然后我们重新启动consumerDemo工程,可以看到超时时间超过2s后才执行的降级处理,
在服务熔断中,使用的熔断器,也叫断路器,其英文单词为:Circuit Breaker。
熔断机制与家里使用的电路熔断原理类似;当如果电路发生短路的时候能立刻熔断电路,避免发生灾难。在分布式系统中应用服务熔断后;服务调用方可以自己进行判断哪些服务反应慢或存在大量超时,可以针对这些服务进行主动熔断,防止整个系统被拖垮。
Hystrix的服务熔断机制,可以实现弹性容错;当服务请求情况好转之后,可以自动重连。通过断路的方式,将后续请求直接拒绝,一段时间(默认5秒)之后允许部分请求通过,如果调用成功则回到断路器关闭状态,否则继续打开,拒绝请求的服务。
Hystrix的熔断状态机模型:
为了能够精确控制请求的成功或失败,在consumerDemo 的处理器业务方法中加入一段逻辑:
@GetMapping("{id}")
@HystrixCommand
public String queryById(@PathVariable("id") Long id){
if(id == 1){
throw new RuntimeException("服务忙");
}
String url = "http://userService/user/" + id;
return restTemplate.getForObject(url, String.class);
}
这样的话如果查询id为1的用户信息,一定失败,其它情况都成功。
当我们疯狂访问id为1的请求时(超过20次),就会触发熔断。断路器会打开,一切请求都会被降级处理。
此时(熔断发生5s内)你访问id为2的请求,会发现返回的也是失败,而且失败时间很短,只有20毫秒左右。由于默认的熔断触发要求较高,休眠时间窗较短,为了测试方便,我们可以通过配置修改熔断策略:
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMilliseconds: 2000 #设置默认超时时间为2000ms,即2s
circuitBreaker:
requestVolumeThreshold: 10 # 熔断触发最小请求次数,默认值是20
sleepWindowInMilliseconds: 10000 # 熔断后休眠时长,默认值5秒
errorThresholdPercentage: 50 # 触发熔断错误比例阈值,默认值50%
我们重启consumerDemo服务,然后疯狂查询id=1的用户,触发服务熔断机制,然后此时访问id=2的用户,会发现还是无法访问,
过了10s之后就可以再次访问到id=2的用户了。