Article / 文章中心

说说 Spring Cloud 的底层架构原理

发布时间:2022-02-11 点击数:299

分布式体系面试系列02-Spring Cloud 的底层架构原理,前面咱们讲了 SpringCloud 的中心架构,了解了有要构建一套分布式体系咱们需求哪些组件。今天以 SpringCloud 为例,讲解一下它的中心组件的原理。

前面咱们讲了一个以Spring Cloud 技术栈完成的分布式体系,至少得包含 Eureka、Ribbon、Feign、Zuul 这么几个组件,你还能记住他们各自是干嘛的么。记不清了没关系,回去看一下这篇文章就好。

Eureka

首先,咱们得说说服务注册中心 Eureka 了,它应该是SpringCloud 技术栈中最中心的东西。

服务注册与发现怎样完成的

服务注册与发现是 Eureka 中最中心的东西。

比方现在咱们有一个服务顾客 服务A,和两个节点的服务供给者,服务B。服务A 和服务B 在启动的时分都会向注册中心进行服务注册。

服务A 也会守时从服务注册中心守时去拉取服务注册表信息到本地来,这个进程叫服务发现,默许是30S 一次,当然了能够自己去装备。

如下图:

32.jpg

实际上当服务在拉取服务注册表的时分,其实客户端不是直接从 Eureka 中的 服务注册表中获取数据的。

Eureka 做了二级缓存,榜首级叫做 ReadOnly 缓存,二级叫做 ReadWrite 缓存。

客户端会直接从ReadOnly 缓存中读取注册表信息。

当服务在进行注册的时分,先往服务注册表中写入注册信息,服务注册表更新了,立马会同步一份数据到 ReadWrite 缓存中去。

那什么时分 ReadWrite 缓存中的数据会到 ReadOnly 缓存中去?

此刻有一个守时使命会守时去检查 ReadWrite 是否跟  ReadOnly 不一致,不一致就把数据同步到 ReadOnly 中去。

这个守时使命也默许是 30S。也能够自己装备。

33.jpg

我们能够考虑一下,这么做的好处是什么,为什么要这么去做二级缓存?

这么做的好处在于,优化并发读写的冲突。

假如服务进行注册的时分,一起有服务来读去注册表信息,就会存在频繁的读写加锁的操作,写的时分就不能读,导致功用下降,所以咱们需求避免许多的读写都去操作一个表。

那么有了这两层,其实大部分的读操作都会走 ReadOnly 缓存。只需求守时把 ReadWrite 缓存中的数据写入到 ReadOnly 就好了。

心跳与毛病检测

服务注册中心还有一个很重要的功用便是 心跳与毛病检查。心跳跟毛病检测其实便是为了知道注册上来的这些服务是不是还活着的。

Eureka 还会开启一个守时使命守时去检查心跳,默许也是30秒,也能够自己设置。

当呈现机器毛病没有在约好的时间距离内上报自己的状态,那么Eureka 就会把这台机器除掉注册表,一起更新到 ReadWrite 缓存中去。如图:

34.jpg

可是把数据从ReadWrite 缓存同步到 ReadOnly 缓存是有时间距离的。当服务顾客A 也只要等候下一次恳求更新的时分才会把自己列表里面的服务给更新掉。

所以有时分会呈现你注册上去的服务经过及时秒才被服务顾客发现,或许服务的某个节点呈现毛病,没有及时除掉掉。这儿便是同步机制的时间差问题。

以上便是 Eureka 的中心运转原理了。

Feign & Ribbon

Feign,它其实便是对一个接口打了一个注解,它会针对这个注解标注的接口生成动态署理目标,然后针对你的 feign 的动态署理署理目标去调用他方法的时分,此刻会在底层生成,http 协议格局的恳求如:/order/create?productId=1

Feign底层的运用的HTTP 通讯框架 HttpClient ,先会运用 Ribbon 从本地的 Eureka 注册表的缓存里面取出要调用服务的机器列表出来,然后根据负载均衡算法,挑选一台机器出来,然后针对挑选出来的机器发送 Http 恳求过去。

Zuul

Zuul 装备恳求路径与服务的对应关系,你的恳求到网关,他就直接查找到匹配的服务,然后就直接把恳求转发给那个服务的某台机器, Ribbon 从 Eureka 本地缓存列表里面获取一台机器,然后经过负载均衡算法挑选一台,把恳求直接用 http 通讯框架发送到指定的机器上面去。

Hystrix

在微服务的架构中,会存在许多的服务调用,假如一个服务呈现毛病,就很容易导致整个调用链产生毛病,产生服务雪崩的情况。

例如,当一个服务呈现毛病,或许超时的问题,可是服务调用方不知道,一直在发送恳求过去,那么等候的恳求越来越多,形成使命积压,终究导致服务崩溃,瘫痪。

Hystrix 的呈现便是为了处理这种问题。它供给了服务降级、服务熔断、线程和信号阻隔、恳求缓存、恳求合并以及服务监控等强壮功用。

Hystrix运用舱壁形式完成线程池的阻隔,它会为每一个依靠服务创建一个独立的线程池,这样就算某个依靠服务呈现推迟过高的情况,也只是对该依靠服务的调用产生影响,而不会拖慢其他的依靠服务。