分佈式篇:Spring Cloud 架構原理流程

流程

分佈式、微服務

首先明確一個概念,分佈式

例如,有一個電商系統,用戶 > 訂單 > 庫存 > 倉儲 > 積分

這些業務都在在一個服務中的,耦合極其嚴重,每次開發、打包、部署、極其繁瑣

最主要的一個問題的,如果其中某個服務出現了問題,必然會影響其餘服務

分佈式通常按業務拆分成多個子系統

每個業務服務子系統部署在單獨的機器上

一次下單請求調用多個服務協作共同完成

每個服務只處理自己範圍內的業務

業界主流的分佈式解決方案 Dubbo / Spring Cloud

現在把上面的電商系統,拆分成 訂單服務、庫存服務、存儲服務、積分服務

這些服務部署在不同的機器上

Spring Cloud 爲我們提供了分佈式業務場景中的各個解決方案

1、註冊中心Eureka
註冊中心是一個單獨的服務,主要負責服務的註冊與發現
訂單服務、庫存服務、存儲服務、積分服務這些服務在啓動的時候,會向註冊中心提供自己的服務地址
例如 [訂單服務:192.168.52.101:8080],[庫存服務:192.168.52.102:8080]
這個過程稱之爲服務註冊
Eureka的另外一個功能的服務發現
各個服務會通過服務發現,把維護在Eureka註冊中心裏的服務地址拉取到自己本地
服務之間調用的時候,就可以直接從自己本地拿到對方服務的地址

2、Ribbon負載均衡
Ribbon 的核心功能的負載均衡
內部提供了多種負載均衡算法
默認採用輪詢的方式
Ribbon會向Feign提供各個服務器地址進行遠程調用,如果涉及到某個服務是集羣方式,單個應用部署在多個機器上
例如[訂單服務:192.168.52.101:8080],[庫存服務:192.168.52.102:8080 / 192.168.52.103:8080]
例如庫存服務有多個,則會採用輪詢的方式向 Feign 提供 服務地址
3、Feign 遠程調用
服務之間相互調用的時候,會通過 Feign 進行 http 進行調用
Feign通過接口的方法調用Rest服務
遵循了面向接口編程的方式

4、Hystrix 斷路器
這塊是屬於高可用方面的解決方案
單點故障之後的解決方案
涉及到服務降級、服務限流、服務熔斷、近實時監控

5、zuul 路由網關
現在的項目一般都是採用前後端分離的方式
如果沒有網關這塊,那麼前端要維護上百個後端接口,這麼多接口直接對外暴露,極其繁瑣,複雜
zuul 所有的請求都可以通過這個入口,來進行訪問後端服務
zuul 主要涉及到代理、路由、過濾三大功能

在這裏插入圖片描述

原理

註冊中心Eureka

兩個核心功能

服務註冊與發現

心跳與故障

我們服務啓動之後會在Eureka中註冊

在Eureka中有一個註冊表

表中維護了我們的服務地址

其餘服務啓動的時候,會去Eureka中拉取註冊表

拉取的這個間隔可以進行配置

服務註冊與發現

在Eureka中有一個多級緩存的概念( ReadOnly緩存 / ReadWrite緩存 )

內部維護的3塊區域 【ReadOnly緩存】 >> 【ReadWrite緩存】 >> 【註冊表】

目的是爲了優化併發衝突

如果沒有這3塊區域,邊寫邊讀的併發操作,鎖的衝突對系統是有一定的影響的

在服務發現的時候,會去 【ReadOnly緩存】 中拉取 註冊表信息

在服務 註冊 / 修改 的時候,會在【註冊表】中註冊服務信息,會立馬同步到 【ReadWrite緩存】

在 【ReadOnly緩存】 到 【ReadWrite緩存】之間 會有一個線程 定時同步註冊表信息,這個時間也是可以配置的

所以說,我們在新加入一個服務,可能調用的時候,不會立馬感知到

這是因爲 【ReadOnly緩存】 還沒有同步最新的 註冊表

心跳與故障

在服務註冊之後

服務會定時向註冊中心發送心跳( 可以配置時長,例如:30s)

會有一個線程定時去檢查服務的心跳

如果發現某個服務在過去60秒 (這個也是可以配置的) 沒有發送心跳

那麼就認爲這個服務掛了,會從【註冊表】中把這個服務給刪除

刪除之後,會把 【ReadWrite緩存】 給清空

等到下一次 【ReadOnly緩存】 同步 【ReadWrite緩存】的時候,緩存中都是空的

等到服務再去 【ReadOnly緩存】 中獲取 【註冊表】 的時候,發現是空的,然後會繼續往上找

【ReadOnly緩存】 >> 【ReadWrite緩存】 >> 【註冊表】

Feign

如果你基於Spring Cloud對外發佈一個接口,實際上就是支持http協議的,對外發布的就是一個最最普通的Spring MVC的http接口

feign它對一個接口打了一個註解,他一定會針對這個註解標註的接口生成動態代理

然後你針對feign的動態代理去調用他的方法的時候,此時會在底層生成http協議格式的請求,/order/create?productId=1

底層的話,使用HTTP通信的框架組件,HttpClient

先得使用Ribbon去從本地的Eureka註冊表的緩存裏獲取出來對方機器的列表

然後進行負載均衡,選擇一臺機器出來,接着針對那臺機器發送Http請求過去即可

zuul

配置一下不同的請求路徑和服務的對應關係,你的請求到了網關,它直接查找到匹配的服務

然後就直接把請求轉發給那個服務的某臺機器

Ribbon從Eureka本地的緩存列表裏獲取一臺機器,負載均衡,把請求直接用HTTP通信框架發送到指定機器上去

在這裏插入圖片描述

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章