我在spring boot & spring cloud关系?里曾说到下次讲spring cloud的核心组件。那为什么说到spring cloud就要提到spring cloud的核心组件呢?
spring cloud提供了分布式系统一整套解决方案。相信大家刚接触微服务,刚接触spring cloud的时候,经常会看到这句话吧。那这句话究竟是什么意思?什么叫分布式系统?什么又叫一整套解决方案呢?
什么是分布式系统?
简单来说,一个项目变的越来越大后,越来越难维护。然后就会把一个项目拆成多个项目或者叫服务。这样一个大项目大系统就变成了分布式系统。项目和服务间的差别大概是大小间的差别吧。微服务应该比分布式系统拆分的粒度更小吧。慢慢的,分布式系统和微服务差别不大吧,或者说微服务本来就是属于分布式系统。一个微服务也相当于是一个系统。
什么又叫一整套解决方案?
一整套解决方案是针对一个完整的系统来说的。一个大型的项目拆成多个服务,会涉及很多问题。比如说服务间如何调用?比如说知道服务的地址后,一个服务要自己写一大堆代码,跟其他服务建立网络连接,然后构造一个复杂的请求,接着发送请求过去,最后对返回的响应结果再写一大堆代码来处理吗?那这样,微服务不是复杂度还提高了吗?等等等。所以说一整套解决方案解决的就是多个服务间这一系列的问题。所以说,这也是为什么要提到spring cloud的核心组件,因为核心组件解决的就是这些问题。
假设一个大的项目我把它拆成了这些服务。
那么,问题1: 一个服务想要调其他服务时,不知道ip端口,我该怎么调用呢?而且其他服务这么多,该怎么记呢?
Eureka
Eureka 是微服务架构中的注册中心,专门负责服务的注册与发现。
Eureka Client:负责将这个服务的信息注册到 Eureka Server 中。
Eureka Server:注册中心,里面有一个注册表,保存了各个服务所在的机器和端口号。
当所有服务共用一个Eureka Server时,每个服务对应的Eureka Client会把该服务信息注册到Eureka Server。然后一个服务想要调用其他服务时,该服务的Eureka Client 组件会找 Eureka Server 问一下要调用的服务信息,然后该服务就有其他服务的信息了,就可以进行调用了。
那么问题又来了,难道一个服务要自己写一大堆代码,跟其他服务建立网络连接,然后构造一个复杂的请求,接着发送请求过去,最后对返回的响应结果再写一大堆代码来处理吗?
Feign
前面的问题显然是不用的,因为框架的目的本来就是简化开发,要真那样的话,开发变的那么复杂,又何必要使用框架呢!
那解决方案呢,就是使用spring cloud的另一个组件Feign。直接就是用注解定义一个 Feign Client 接口,然后调用那个接口就可以了。
Feign 的一个关键机制就是使用了动态代理。当对某个接口定义了 @FeignClient 注解,Feign 就会针对这个接口创建一个动态代理。如果要调用那个接口,本质就是会调用 Feign 创建的动态代理(Feign的动态代理会根据你在接口上的 @RequestMapping 等注解,来动态构造出你要请求的服务的地址),这是核心中的核心。针对动态代理的这个地址,发起请求、解析响应。相当于就解决了最开始提及的问题(难道一个服务要自己写一大堆代码,跟其他服务建立网络连接,然后构造一个复杂的请求,接着发送请求过去,最后对返回的响应结果再写一大堆代码来处理吗)。
Ribbon
所以说到这,还有什么问题吗,Feign能调服务,Eureka能找到服务。微服务间主要的调用问题解决全了吗?一个大型的服务,我可以部署到多台服务器上,一个挂了还能用另一个。那微服务呢?当然也是一样的。也可以把一个服务部署到多台机器上。那现在再想想,是不是又出现问题了,一个服务在多台机器上,我用哪个机器上的服务呢?Feign 怎么知道该请求哪台机器呢?
Ribbon 就是专门解决这个问题的。它的作用是负载均衡,会帮你在每次请求时选择一台机器,均匀的把请求分发到各个机器上。它有自己默认的算法,也可以自定义算法。其实Feign里是集成了Ribbon的,用的就是Ribbon默认的随机策略。
Ribbon Feign Eureka 工作
首先 Ribbon 会从 Eureka Client 里获取到对应的服务注册表,也就知道了所有的服务都部署在了哪些机器上,在监听哪些端口号。然后 Ribbon 就可以使用默认的 Round Robin 算法,从中选择一台机器。Feign 就会针对这台机器,构造并发起请求。
Hystrix
前面说到服务会挂。一个工程是由多个服务组合而成,那么服务调用过程中,某个服务出现故障时,会导致整个功能出现问题,那么怎么解决这个问题呢,就需要用到Hystrix组件。
服务熔断
服务调不通时,执行其他方法。
例子:
@HystrixCommand(fallbackMethod = "getDefaultUser")
@GetMapping("getUser")
public String getUser(Integer id) {
String url = "http://user-service/provider/getUser?id=" + id;
return restTemplate.getForObject(url, String.class);
}
public String getDefaultUser(Integer id) {
System.out.println("熔断,默认回调函数");
return "{\"id\":-1,\"name\":\"熔断用户\",\"password\":\"123456\"}";
}
服务降级
服务降级时在客户端实现完成,服务降级出现原因是:服务熔断会导致方法膨胀(与服务相关的方法都要有对应的服务熔断)。
服务降级目的:让客户端在服务端不可用时(把服务关掉,让其他服务用足够的资源)也会获得提示信息而不会挂起耗死服务器。
//表示"user-service"的服务,指定fallback
@FeignClient(value = "user-service", fallback = UserFeginFailBackImpl.class)
public interface UserFeginService {
@RequestMapping(value = "/provider/getUser")
public String getUser(@RequestParam("id") Integer id);
}
Fallback类会执行相应操作,让项目继续运行,不会导致系统耗死。
Zuul
前端调后端系统时,请求统一从 Zuul 网关进入,由 Zuul 网关转发请求给对应的服务(会进行配置)。现在一般都是前后端分离,一般不把真实路径暴露给前端,所以前端请求通过zuul网关转发到对应配置的具体服务就解决了这个问题。
但是如果后端服务多达十几个的时候,每一个都这样配置也挺麻烦的,spring cloud zuul已经帮我们做了默认配置。默认情况下,Zuul会代理所有注册到Eureka Server的微服务,并且Zuul的路由规则如下:http://ZUUL_HOST:ZUUL_PORT/
微服务在Eureka上的serviceId/**
会被转发到serviceId对应的微服务。
有一个网关之后,还有很多好处,比如可以做统一的降级、限流、认证授权、安全。
spring cloud组件协作图
今天写的全部都是理论,具体实现,下次吧。
再分享一个学习网址https://www.kancloud.cn/ur_champaign/springcloud-frame/925768
我觉得挺好的。