★ 微服務系列18篇

1 背景

在互聯網高可用架構設計中，應該避免將所有的控制權都集中到一個中心服務，即便這個中心服務是多副本模式。
對某個中心服務（組件）的過渡強依賴，那等同于把命脈掌握在依賴方手里，依賴方的任何問題都可能成為你不穩定的因素。
而弱化強依賴，實現可降級交互，是一種設計理念和架構模式，目的是將系統的控制權分散到各個節點，避免出現單點故障或中心化控制的問題。
這一點，我們稱之為『去中心化』。

具體來說，去中心化架構中的每個節點都具有自主性，可以獨立地處理和存儲數據，并且節點之間通過特定的協議或機制進行通信和協作。這種架構可以提高系統的可用性和可擴展性，降低對單個節點的依賴性，增強系統的可靠性和容錯能力。

2 經典去中心化架構設計

我們去分析業內的很多經典的軟件設計，都可以看到他們為了實現降低對中心服務（組件）的依賴，做了很多方案優化。

2.1 微服務注冊中心

如上圖所示：
1、Provider 服務提供者：服務向注冊中心注冊服務信息，即 服務 -> 服務實例 數據模型， 同時定時向注冊中心匯報健康檢查，如果一定時間內（一般90s）沒有進行心跳匯報，則會被注冊中心剔除。
所以這邊注意，注冊中心感知到應用下線并進行剔除這個過程可能比較長。
2、Consumer 服務消費者：服務向注冊中心獲取所需服務對應的服務實例信息。這邊需要注意，在Spring Cloud生態中，一般通過實時訂閱或者定時拉取方式從注冊中心中獲取所需的服務實例信息。
3、Remote Call 遠程調用：Consumer從注冊中心獲取的Provider的實例信息，通過 Load Balance的策略，確定一個實際的實例，發起遠程調用。

去中心化分析：很明顯，我們的注冊和訂閱都依賴注冊中心（Eureka、ZK、Etcd或者其他...），如果這個注冊中心掛了，我們連對服務的訪問路由地址都無法匹配，請求都沒辦法發出去。
所以現在一般Client端會緩存依賴服務的地址列表到本地，即便注冊中心掛了，在短時間內也會正常運行，只是新增或者更新的服務實例無法獲取到。

2.2 分布式存儲系統

分布式存儲系統是實現去中心化的一種重要實現方式。通過將數據分散存儲在多個節點上，而不是集中存儲在中心服務器上，分布式存儲系統可以避免單點故障和中心化控制的問題，提高系統的可用性和可擴展性。

在分布式存儲系統中，每個節點都有自己的存儲設備和計算能力，可以獨立地存儲和檢索數據。節點之間通過特定的協議或機制進行通信和協作，共同維護系統的數據和功能。這種架構可以降低對單個節點的依賴性，增強系統的可靠性和容錯能力。

如圖，B Region 如果掛了，流量會調度到A Region中，如果A、B均掛了，則會啟動Backups Region，當然，數據可能會有一些延遲，但依然能保證系統正常提供服務。

3 常用的架構設計方案

業內有一些優秀的設計經驗，用于規避中心故障導致的服務雪崩。

3.1 多副本模式+重試

比如你的中心服務有20個副本（實例），其中一個副本（實例）出故障，導致執行返回5xx，那么第二次請求的時候大概會有 19/20 的成功概率。
負載均衡模式默認是RR，所以實例越多，實際上重試成功的概率會越高。

3.2 多副本模式+異常隔離

如果依賴的中心服務存在多副本，那么即使存在不健康副本（實例），只要是被自動驅逐之后，服務依舊是健康的。
但是驅逐需要保障剩余的副本能夠支撐峰值流量的沖擊。

3.3 強大的主備模式

標準兩地三中心建設（同城主、同城備、異地備），避免單機房故障，甚至區域自然災害導致系統無法提供正常服務。

3.4 極限兜底：如緩存保證依賴可降級

類似微服務注冊中心的做法，用一層緩存做兜底，一般來說數據庫跟緩存同時出故障的概率不高。
筆者的團隊就有一個案例：依賴的Etcd服務，用于路由分發的配置信息存儲，失聯了4小時，靠著緩存保證了大部分流量的正常運行。

4 總結

在互聯網高可用架構建設中，去中心化設計，可以降低對單個節點的依賴性，增強系統的可靠性和容錯能力。

總結

以上是生活随笔為你收集整理的高可用架构，去中心化有多重要？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。