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