分布式體系面試系列02-Spring Cloud 的底層架構(gòu)原理，前面咱們講了 SpringCloud 的中心架構(gòu)，了解了有要構(gòu)建一套分布式體系咱們需求哪些組件。今天以 SpringCloud 為例，講解一下它的中心組件的原理。

前面咱們講了一個(gè)以Spring Cloud 技術(shù)棧完成的分布式體系，至少得包含 Eureka、Ribbon、Feign、Zuul 這么幾個(gè)組件，你還能記住他們各自是干嘛的么。記不清了沒關(guān)系，回去看一下這篇文章就好。

Eureka

首先，咱們得說說服務(wù)注冊(cè)中心 Eureka 了，它應(yīng)該是SpringCloud 技術(shù)棧中最中心的東西。

服務(wù)注冊(cè)與發(fā)現(xiàn)怎樣完成的

服務(wù)注冊(cè)與發(fā)現(xiàn)是 Eureka 中最中心的東西。

比方現(xiàn)在咱們有一個(gè)服務(wù)顧客 服務(wù)A，和兩個(gè)節(jié)點(diǎn)的服務(wù)供給者，服務(wù)B。服務(wù)A 和服務(wù)B 在啟動(dòng)的時(shí)分都會(huì)向注冊(cè)中心進(jìn)行服務(wù)注冊(cè)。

服務(wù)A 也會(huì)守時(shí)從服務(wù)注冊(cè)中心守時(shí)去拉取服務(wù)注冊(cè)表信息到本地來，這個(gè)進(jìn)程叫服務(wù)發(fā)現(xiàn)，默許是30S 一次，當(dāng)然了能夠自己去裝備。

如下圖：

實(shí)際上當(dāng)服務(wù)在拉取服務(wù)注冊(cè)表的時(shí)分，其實(shí)客戶端不是直接從 Eureka 中的 服務(wù)注冊(cè)表中獲取數(shù)據(jù)的。

Eureka 做了二級(jí)緩存，榜首級(jí)叫做 ReadOnly 緩存，二級(jí)叫做 ReadWrite 緩存。

客戶端會(huì)直接從ReadOnly 緩存中讀取注冊(cè)表信息。

當(dāng)服務(wù)在進(jìn)行注冊(cè)的時(shí)分，先往服務(wù)注冊(cè)表中寫入注冊(cè)信息，服務(wù)注冊(cè)表更新了，立馬會(huì)同步一份數(shù)據(jù)到 ReadWrite 緩存中去。

那什么時(shí)分 ReadWrite 緩存中的數(shù)據(jù)會(huì)到 ReadOnly 緩存中去?

此刻有一個(gè)守時(shí)使命會(huì)守時(shí)去檢查 ReadWrite 是否跟  ReadOnly 不一致,不一致就把數(shù)據(jù)同步到 ReadOnly 中去。

這個(gè)守時(shí)使命也默許是 30S。也能夠自己裝備。

我們能夠考慮一下，這么做的好處是什么，為什么要這么去做二級(jí)緩存？

這么做的好處在于，優(yōu)化并發(fā)讀寫的沖突。

假如服務(wù)進(jìn)行注冊(cè)的時(shí)分，一起有服務(wù)來讀去注冊(cè)表信息，就會(huì)存在頻繁的讀寫加鎖的操作，寫的時(shí)分就不能讀，導(dǎo)致功用下降，所以咱們需求避免許多的讀寫都去操作一個(gè)表。

那么有了這兩層，其實(shí)大部分的讀操作都會(huì)走 ReadOnly 緩存。只需求守時(shí)把 ReadWrite 緩存中的數(shù)據(jù)寫入到 ReadOnly 就好了。

心跳與毛病檢測(cè)

服務(wù)注冊(cè)中心還有一個(gè)很重要的功用便是 心跳與毛病檢查。心跳跟毛病檢測(cè)其實(shí)便是為了知道注冊(cè)上來的這些服務(wù)是不是還活著的。

Eureka 還會(huì)開啟一個(gè)守時(shí)使命守時(shí)去檢查心跳，默許也是30秒，也能夠自己設(shè)置。

當(dāng)呈現(xiàn)機(jī)器毛病沒有在約好的時(shí)間距離內(nèi)上報(bào)自己的狀態(tài)，那么Eureka 就會(huì)把這臺(tái)機(jī)器除掉注冊(cè)表，一起更新到 ReadWrite 緩存中去。如圖：

可是把數(shù)據(jù)從ReadWrite 緩存同步到 ReadOnly 緩存是有時(shí)間距離的。當(dāng)服務(wù)顧客A 也只要等候下一次懇求更新的時(shí)分才會(huì)把自己列表里面的服務(wù)給更新掉。

所以有時(shí)分會(huì)呈現(xiàn)你注冊(cè)上去的服務(wù)經(jīng)過及時(shí)秒才被服務(wù)顧客發(fā)現(xiàn)，或許服務(wù)的某個(gè)節(jié)點(diǎn)呈現(xiàn)毛病，沒有及時(shí)除掉掉。這兒便是同步機(jī)制的時(shí)間差問題。

以上便是 Eureka 的中心運(yùn)轉(zhuǎn)原理了。

Feign & Ribbon

Feign，它其實(shí)便是對(duì)一個(gè)接口打了一個(gè)注解，它會(huì)針對(duì)這個(gè)注解標(biāo)注的接口生成動(dòng)態(tài)署理目標(biāo)，然后針對(duì)你的 feign 的動(dòng)態(tài)署理署理目標(biāo)去調(diào)用他方法的時(shí)分，此刻會(huì)在底層生成，http 協(xié)議格局的懇求如：/order/create?productId=1

Feign底層的運(yùn)用的HTTP 通訊框架 HttpClient ,先會(huì)運(yùn)用 Ribbon 從本地的 Eureka 注冊(cè)表的緩存里面取出要調(diào)用服務(wù)的機(jī)器列表出來，然后根據(jù)負(fù)載均衡算法，挑選一臺(tái)機(jī)器出來，然后針對(duì)挑選出來的機(jī)器發(fā)送 Http 懇求過去。

Zuul

Zuul 裝備懇求路徑與服務(wù)的對(duì)應(yīng)關(guān)系,你的懇求到網(wǎng)關(guān),他就直接查找到匹配的服務(wù),然后就直接把懇求轉(zhuǎn)發(fā)給那個(gè)服務(wù)的某臺(tái)機(jī)器, Ribbon 從 Eureka 本地緩存列表里面獲取一臺(tái)機(jī)器,然后經(jīng)過負(fù)載均衡算法挑選一臺(tái),把懇求直接用 http 通訊框架發(fā)送到指定的機(jī)器上面去。

Hystrix

在微服務(wù)的架構(gòu)中，會(huì)存在許多的服務(wù)調(diào)用，假如一個(gè)服務(wù)呈現(xiàn)毛病，就很容易導(dǎo)致整個(gè)調(diào)用鏈產(chǎn)生毛病，產(chǎn)生服務(wù)雪崩的情況。

例如，當(dāng)一個(gè)服務(wù)呈現(xiàn)毛病，或許超時(shí)的問題，可是服務(wù)調(diào)用方不知道，一直在發(fā)送懇求過去，那么等候的懇求越來越多，形成使命積壓，終究導(dǎo)致服務(wù)崩潰，癱瘓。

Hystrix 的呈現(xiàn)便是為了處理這種問題。它供給了服務(wù)降級(jí)、服務(wù)熔斷、線程和信號(hào)阻隔、懇求緩存、懇求合并以及服務(wù)監(jiān)控等強(qiáng)壯功用。

Hystrix運(yùn)用艙壁形式完成線程池的阻隔，它會(huì)為每一個(gè)依靠服務(wù)創(chuàng)建一個(gè)獨(dú)立的線程池，這樣就算某個(gè)依靠服務(wù)呈現(xiàn)推遲過高的情況，也只是對(duì)該依靠服務(wù)的調(diào)用產(chǎn)生影響，而不會(huì)拖慢其他的依靠服務(wù)。