一、分散式基礎概念

1、微服務

微服務架構風格,就像是把一個單獨的應用程式開發為一套小服務,每個小服務執行在自己的程式中,並使用輕量級機制通訊,通常是HTTP API。這些服務圍繞業務能力來構建,並通過完全自動化部署機制來獨立部署。這些服務使用不同的程式語言來書寫,以及不同資料儲存技術,並保持最低限度的集中式管理。
簡而言之：拒絕大型單體應用,基於業務邊界進行服務化拆分,各個服務獨立部署執行。

2、叢集&分散式&節點

叢集是個物理形式,分散式是個工作方式。
只要是一堆機器,就可以叫叢集,他們是不是一起協作著幹活,這個誰也不知道;
分散式是指將不同的業務分佈在不同的地方。建立在網路之上的軟體系統。
叢集指的是將幾個伺服器集中在一起,實現同一業務。
分散式中的每一個節點,都可以做叢集。而叢集不一定就是分散式的。
**節點:**叢集中的一個伺服器。

3、遠端呼叫

在分散式系統中,各個服務可能處於不同主機,但是服務之間不可能避免的需要相互呼叫,我們成為遠端呼叫。
SpringCloud中使用HTTP+JSON 的方式完成遠端呼叫。

4、負載均衡

分散式系統中,A服務呼叫B服務,B服務在多臺機器中都存在,A呼叫任意一個伺服器均可完成功能。
為了是每一個伺服器都不要太閒或者太忙,我們可以負載均衡的呼叫每一個伺服器,提升網站健壯性。
常見的負載均衡演算法:
輪詢: 為第一個請求選擇健康池中的第一個後端伺服器,然後按順序往後依次選擇,直到最後一個,然後迴圈。
最小連線: 優先選擇連線數最小,也就是壓力最小的後端伺服器,在會話較長的情況下可以考慮採取這種方式。
雜湊: 根據請求源的IP的雜湊(hash)來選擇要轉發的伺服器。這種方式可以一定程度上保證特定使用者能連線到相同的伺服器。如果你的應用需要處理轉態而要求使用者能連線到和之前相同的伺服器,可以考慮採取這種方式。

5、服務註冊/發現&註冊中心

A服務呼叫B服務,A服務並不知道B服務當前在哪幾臺伺服器有,哪些正常的,哪些服務已經下線。解決這個問題可以引入註冊中心;

如果某些服務下線,我們其他人可以實時的感知到其他服務的狀態,從而避免呼叫不可用的服務

6、配置中心

每一個服務最終都有大量的配置,並且每個服務都可能部署在多臺機器上。我們經常需要變更配置，我們可以讓每個服務在配置中心獲取自己的配置。
配置中心用來集中管理微服務的配置資訊

7、服務熔斷&服務降級

在微服務架構中,微服務之間通過網路進行通訊,存在相互依賴,當其中一個服務不可用時,有可能會造成雪崩效應。要放置這樣的情況，必須要有容錯機制來保護服務。

1)、服務熔斷

設定服務的超時,當被呼叫的服務經常失敗到達某個閾值,我們可以開啟斷路保護機制,後來的請求不再去呼叫這個服務。本地直接返回預設的資料

2)、服務降級

在運維期間,當系統處於高峰期,系統資源緊張,我們可以讓非核心業務降級執行。
降級: 某些服務不處理,或者簡單處理【拋異常、返回null、呼叫Mock資料、呼叫Fallback處理邏輯】。

8、API閘道器

在微服務架構中,API Gateway作為整體架構的重要元件,它抽象了微服務中都需要的公共功能,同時提供了客戶端負載均衡,服務自動熔斷,灰度釋出,統一認證,限流流控,日誌統計等豐富的功能,幫助我們解決很多API管理難題。