SpringCloud概念篇
1、SpringCloud的简介
SpringCloud是Spring旗下的项目之一,因为Spring最擅长的就是集成,就是将世界上最好的框架整合到自己的项目中,所以SpringCloud也是一样,它将现在非常流行的一些技术整合到了一起,实现了以下的功能:配置管理、服务发现、智能路由、负载均衡、熔断器、总线控制等等,其中主要涉及的组件包括:
- Eureka:注册中心——实现服务注册与服务发现的功能
- Ribbon:负载均衡器——实现负载均衡的功能
- Hystrix:熔断器——实现熔断器的功能
- Feign:伪装器——实现简化服务间调用的功能
- Gateway:服务网关——实现智能路由的功能
- Config:配置中心——实现配置管理的功能
- Bus:服务总线——实现总线控制的功能
2、SpringCloud的版本
SpringCloud的版本命名比较特殊,不是通常的按数字编排的命名方式,而是使用一些英文单词组合而成的版本名。而每一个版本的SpringCloud都对应着相应的SpringBoot的版本,它们之间的对应关系如下:
Cloud Version | Boot Version |
---|---|
Hoxton | 2.2.x |
Greenwish | 2.1.x |
Finchley | 2.0.x |
Edgware | 1.5.x |
Dalston | 1.5.x |
3、SpringCloud中组件的介绍
3.1、Eureka
Eureka是SpringCloud框架中负责管理、记录服务提供者的信息,当服务调度者需要调度服务时,无需服务调度者自己去寻找服务提供者,而是将需要调度服务的请求发给Eureka注册中心,由Eureka注册中心来确定服务是哪一个,同时,服务提供者与Eureka注册中心之间通过“心跳”机制来确认连接是否有效,当一个服务提供者出现服务中断的情况,那么Eureka注册中心就会将该服务提供者从服务列表中剔除。由此通过Eureka注册中心便实现了服务的自动注册、发现和监控服务状态的功能。
以下是Eureka注册中心的工作原理图: Eureka注册中心的工作步骤大概如下:
- 服务提供者将服务注册到Eureka注册中心
- Eureka注册中心记录服务,形成服务列表
- 服务调用者向Eureka注册中心拉取服务列表
- 通过负载匀衡算法选择出调用服务的地址,然后调用服务
- 服务提供者定期向Eureka注册中心发送心跳
- Eureka注册中心检查服务提供者是否能够继续提供服务,不能提供服务将被Eureka注册中心剔除。
3.2、Ribbon
在一个大型的项目中,服务提供者肯定是不只有一个,而是会有多个功能相同但地址不同的服务提供者形成集群,在服务调用者拉取服务时应该选择哪一个服务进行调取呢,那么在选择服务的过程中就会运用到一种算法:负载均衡算法。
还记得在上述的Eureka工作原理时也提到了负载均衡算法,那么Eureka注册中心如何实现负载均衡算法的,这便是Ribbon组件在发挥作用了。
Ribbon组件是集成在Eureka注册中心上进行负载均衡算法的一款高效的组件,因此Ribbon也被称为负载均衡器。Ribbon的主要功能便是为我们提供负载均衡算法的,比如:轮训、随机等等,当然Ribbon组件也是能支持我们自己自定义负载均衡算法的。
3.3、Hystrix
Hystrix是Netflix一个开源的延迟和容错库,作用是:进行远程服务的隔离访问,防止出现服务大量阻塞,形成雪崩效应。
雪崩效应就是在微服务的项目中,一次访问需要涉及到多个服务之间的相互调用才可以完成一次操作,如果在服务调用之间出现某一个服务突然无法正常运转,那么执行这一次请求的线程便会阻塞在出现问题的服务处,等待该服务重新运行起来返回结果,因此该线程便无法正常执行完并释放资源,一旦访问的次数过多,那么就会有大量的线程阻塞,而当阻塞的线程数超出了服务器的承受数量,那么就会导致服务器资源耗尽,无法在进行其他服务,这便是所谓的雪崩效应。
而使用Hystrix组件后便可以很好的避免雪崩效应的出现,Hystrix解决雪崩的方式包括两个方面:
- 线程隔离机制
- 服务降级机制 线程隔离机制就是:Hystrix为每一个依赖服务分配一个小线程池,用户的请求将不能直接访问服务,而是通过线程池空闲线程来进行访问服务的操作,当线程池满了以后与该服务有关联的请求将会被拒绝,且访问线程池的访问是异步的,由此加快失效服务的判定时间,当线程池已满之后,就会执行Hystrix的另一个机制:服务降级机制。
服务降级机制就是:当线程池已满或者是请求超时之时,即用户的请求出现故障的情况下,线程不会出现阻塞情况,不会无休止的等待导致系统奔溃,而是会在用户的界面显示一个执行结果,比如:友好的出错提示。在该机制下,用户虽然得不到正确的请求结果,但不会对服务器造成不可挽回的雪崩效应。
在Hystrix中还有一个比较重要的机制就是:服务熔断机制。当一个服务被多次请求访问且都无法正常执行服务,因而发生多次服务降级的结果时,服务器就会可以开启服务熔断机制,在该机制下,服务器会打开一个叫熔断器的结构,让访问服务器中的所有服务都会发生服务降级的情况,当过了一段时间后,服务器请求状况没有再出现故障时,那些正常的服务便会自动重连,然后系统关闭熔断器,当服务器的请求状况出现没有好转的情况,那断路器将会一直打开,直到请求状况发生好转才会关闭。
Hystrix的熔断机制原理图: 从图中可以看出熔断机制有三种状态:
- Closed——熔断器关闭状态,该状态下所有请求都正常访问
- Open——熔断器开启状态,所有请求的服务都会被降级,达到熔断器开启的条件为:当失败请求的比例达到50%,且请求次数最少不低于20次。
- Half Open——熔断器半开状态,这个状态不是永久的,在熔断器打开后会开始计算休眠的时间(默认是5s),当休眠超时后熔断器就会进入半开状态,此时服务器会让部分请求访问服务,如果请求状态良好,熔断器就会进入关闭状态,如果请求状态还是出现问题,那么熔断器又会进入开启状态,进行服务的熔断,且再次计算休眠时间。
3.4、Feign
Feign可以把Rest的请求进行隐藏,伪装成类似SpringMVC的Controller一样。你不用再自己拼接url,拼接参数等等操作,一切都交给Feign去做,正是该组件的引入大大简化了项目中服务间进行相互访问的操作。具体的操作如下:
- 定义一个接口,在该接口中需要配置访问的服务的地址和一个调用该访问地址的方法,之后Feign组件会通过动态代理,帮我们生成实现类。在进行配置中会使用到两个注解,如下所示:
@FeignClient(“服务名”) 和 @GetMapper(“具体请求地址”) 之后通过Feign组件处理后就会变为:http://服务名/具体请求地址
3.5、Gateway
Gateway组件是SpringCloud中进行网关服务的组件,该组件是基于Filter链提供网关的基本功能:安全、监控和限流等等,为微服务框架提供了简单、有效且统一的API路由管理方式。
在Gateway组件中最核心的部分便是一系列的过滤器,通过这些过滤器可以将客户端的请求发送给对应的微服务,因此Gateway组件最核心的功能就是:过滤和路由。
在Gateway中过滤靠的是过滤器的使用,而在Gateway中有两种过滤器:一种是Gateway Filter,另一种是Global Filter。前者主要是用于局部过滤,而后者可以用于全局过滤。
在Gateway中,如果需要进行路由功能,必须配置路由相关的信息,而路由信息包含了:一个路由的ID号、一个进行服务操作的请求URL、一组断言工厂、一组过滤器组。如果路由断言为真,说明请求的URL与配置的路由一致。
在Gateway中还有一个很重要的配置:跨域配置。在项目中,网关是项目中微服务的统一入口,那么在进行调用时必然会出现跨域问题。比如说在前后端分离的项目中,前端服务器的地址肯定是和服务器网关的地址是不一样的,那么从前端发起的网关请求就会出现跨域请求的问题,想要解决跨域请求,那么便可以在Gateway服务中配置跨域相关的配置。
3.6、Config
在分布式系统中,会有很多的服务,而每个服务上都会有自己的配置文件,这些配置文件在系统中是分散在服务中的,管理起来不方便,为了方便对配置文件进行管理,在SpringCloud便引入了config配置中心组件,它支持将配置文件放在服务本地,也支持放在远程仓库中,如:GitHub、Gitee。
加入配置中心的结构图如下:
3.7、Bus
使用配置中心进行配置文件的管理会出现一个很麻烦的情况,那就是当在服务启动之后,你更改了远程仓库的配置文件,服务器是无法在不重启的情况下进行配置更新的,而且重启服务在大型项目中是不切实际的,那么该如何在不重启服务的情况下,让项目中的服务中的配置文件可以自动更新成修改后的配置文件,那就需要用到SpringCloud中的另一个组件:Bus组件。
Spring Cloud Bus是用轻量的消息代理将分布式的每个服务节点连接起来,可以用于广播配置文件的更改或者服务的监控管理。也就是消息总线可以为微服务做监控,也可以实现应用程序之间相互通信。 Spring Cloud Bus可选的消息代理有RabbitMQ和Kafka。
实现的操作就是向配置中心发起以下的post请求:
http://host:port/actuator/bus-refresh 在请求其中 host:port 表示的是你自己配置中心的地址,而后面地址写法的是固定的,不可更改
发送了该请求后,配置中心将会了解到你进行了远程仓库配置文件的更改,那么配置中心就会向RabbitMQ或者是Kafka发送一个更新配置的消息,之后便是通过RabbitMQ或Kafka广播出去,让每个服务自动进行更新配置的操作。
添加了Bus组件之后的结构图如下
4、SpringCloud项目的完整架构
以下是SpringCloud项目中的完整架构图