分佈式系統的負載均衡 | 架構乾貨

1、 什麼是負載均衡？

什麼是負載均衡？

記得第一次接觸 Nginx 是在實驗室，那時候在服務器部署網站須要用 Nginx 。Nginx 是一個服務組件，用來反向代理、負載平衡和 HTTP 緩存等。那麼這裏的 負載均衡 是什麼？

負載均衡（LB，Load Balance），是一種技術解決方案。用來在多個資源（通常是服務器）中分配負載，達到最優化資源使用，避免過載。

資源，至關於每一個服務實例的執行操做單元，負載均衡就是將大量的數據處理操做分攤到多個操做單元進行執行，用來解決互聯網分佈式系統的大流量、高併發和高可用的問題。那什麼是高可用呢？

2、什麼是高可用？

首先了解什麼是高可用？

這是 CAP 定理是分佈式系統的基礎，也是分佈式系統的 3 個指標：

1. Consistency（一致性）
2. Availability（可用性）
3. Partition tolerance（分區容錯性）

那高可用（High Availability）是什麼？高可用，簡稱 HA，是系統一種特徵或者指標，一般是指，提供必定性能上的服務運行時間，高於平均正常時間段。反之，消除系統服務不可用的時間。

衡量系統是否知足高可用，就是當一臺或者多臺服務器宕機的時候，系統總體和服務依然正常可用。

舉個例子，一些知名的網站保證 4 個 9 以上的可用性，也就是可用性超過 99.99%。那 0.01% 就是所謂故障時間的百分比。好比電商網站有贊，服務不可用會形成商家損失金錢和用戶。那麼在提升可用性基礎上同時，對系統宕機和服務不可用會有補償。

好比下單服務，可使用帶有負載均衡的多個下單服務實例，代替單一的下單服務實例，即便用冗餘的方式來提升可靠性。

總而言之，負載均衡（Load Balance）是分佈式系統架構設計中必須考慮的因素之一。通常經過負載均衡，冗餘同一個服務實例的方式，解決分佈式系統的大流量、高併發和高可用的問題。負載均衡核心關鍵：在因而否分配均勻。

3、常見的負載均衡案例

場景1：微服務架構中，網關路由到具體的服務實例 hello：

• 兩個相同的服務實例 hello service ，一個端口 8000 ，另外一個端口 8082
• 經過 Kong 的負載均衡 LB 功能，讓請求均勻的分發到兩個 hello 服務實例
• Kong 的負載均衡策略算法不少：默認 weighted-round-robin 算法，還有 consumer: consumer id 做爲 hash 算法輸入值等

場景2：微服務架構中，A 服務調用 B 服務的集羣。經過了 Ribbon 客戶端負載均衡組件：

• 負載均衡策略算法並不高級，最簡單的是隨機選擇和輪循

4、互聯網分佈式系統解決方案

常見的互聯網分佈式系統架構分爲幾層，通常以下：

• 客戶端層：好比用戶瀏覽器、APP 端
• 反向代理層：技術選型 Nignx 或者 F5 等
• Web 層：先後端分離場景下， Web 端能夠用 NodeJS 、 RN 、Vue
• 業務服務層：用 Java 、Go，通常互聯網公司，技術方案選型就是 SC 或者 Spring Boot + Dubbo 服務化
• 數據存儲層：DB 選型 MySQL ，Cache 選型 Redis ，搜索選型 ES 等

一個請求從第 1 層到第 4 層，層層訪問都須要負載均衡。即每一個上游調用下游多個業務方的時候，須要均勻調用。這樣總體系統來看，就比較負載均衡

第 1 層：客戶端層 -> 反向代理層 的負載均衡

客戶端層 -> 反向代理層的負載均衡如何實現呢？

答案是：DNS 的輪詢。 DNS 能夠經過 A （Address，返回域名指向的 IP 地址）設置多個 IP 地址。好比這裏訪問 bysocket.com 的 DNS 配置了 ip1 和 ip2 。爲了反向代理層的高可用，至少會有兩條 A 記錄。這樣冗餘的兩個 ip 對應的 nginx 服務實例，防止單點故障。

每次請求 bysocket.com 域名的時候，經過 DNS 輪詢，返回對應的 ip 地址，每一個 ip 對應的反向代理層的服務實例，也就是 nginx 的外網ip。這樣能夠作到每個反向代理層實例獲得的請求分配是均衡的。

第 2 層：反向代理層 -> Web 層 的負載均衡

反向代理層 -> Web 層 的負載均衡如何實現呢？

是經過反向代理層的負載均衡模塊處理。好比 nginx 有多種均衡方法：

1. 請求輪詢。請求按時間順序，逐一分配到 web 層服務，而後周而復始。若是 web 層服務 down 掉，自動剔除

upstream web-server {
    server ip3;
    server ip4;
}

1. ip 哈希。按照 ip 的哈希值，肯定路由到對應的 web 層。只要是用戶的 ip 是均勻的，那麼請求到 Web 層也是均勻的。

還有個好處就是同一個 ip 的請求會分發到相同的 web 層服務。這樣每一個用戶固定訪問一個 web 層服務，能夠解決 session 的問題。

upstream web-server {
    ip_hash;
    server ip3;
    server ip4;
}

1. weight 權重 、 fair、url_hash 等

第 3 層：Web 層 -> 業務服務層 的負載均衡

Web 層 -> 業務服務層 的負載均衡如何實現呢？

好比 Dubbo 是一個服務治理方案，包括服務註冊、服務降級、訪問控制、動態配置路由規則、權重調節、負載均衡。其中一個特性就是智能負載均衡：內置多種負載均衡策略，智能感知下游節點健康情況，顯著減小調用延遲，提升系統吞吐量。

爲了不避免單點故障和支持服務的橫向擴容，一個服務一般會部署多個實例，即 Dubbo 集羣部署。會將多個服務實例成爲一個服務提供方，而後根據配置的隨機負載均衡策略，在20個 Provider 中隨機選擇了一個來調用，假設隨機到了第7個 Provider。LoadBalance 組件從提供者地址列表中，使用均衡策略，選擇選一個提供者進行調用，若是調用失敗，再選另外一臺調用。

Dubbo內置了4種負載均衡策略:

• RandomLoadBalance:隨機負載均衡。隨機的選擇一個。是Dubbo的默認負載均衡策略。
• RoundRobinLoadBalance:輪詢負載均衡。輪詢選擇一個。
• LeastActiveLoadBalance:最少活躍調用數，相同活躍數的隨機。活躍數指調用先後計數差。使慢的 Provider 收到更少請求，由於越慢的 Provider 的調用先後計數差會越大。
• ConsistentHashLoadBalance:一致性哈希負載均衡。相同參數的請求老是落在同一臺機器上。

一樣，由於業務的須要，也能夠實現本身的負載均衡策略

第 4 層：業務服務層 -> 數據存儲層 的負載均衡

數據存儲層的負載均衡，通常經過 DBProxy 實現。好比 MySQL 分庫分表。

當單庫或者單表訪問太大，數據量太大的狀況下，須要進行垂直拆分和水平拆分兩個維度。好比水平切分規則：

• Range 、 時間
• hash 取模，訂單根據店鋪ID 等

但伴隨着這塊的負載會出現下面的問題，須要解決：

• 分佈式事務
• 跨庫 join 等

現狀分庫分表的產品方案不少：噹噹 sharding-jdbc、阿里的 Cobar 等

5、小結

對外看來，負載均衡是一個系統或軟件的總體。對內看來，層層上下游調用。只要存在調用，就須要考慮負載均衡這個因素。因此負載均衡（Load Balance）是分佈式系統架構設計中必須考慮的因素之一。考慮主要是如何讓下游接收到的請求是均勻分佈的：

• 第 1 層：客戶端層 -> 反向代理層 的負載均衡。經過 DNS 輪詢
• 第 2 層：反向代理層 -> Web 層 的負載均衡。經過 Nginx 的負載均衡模塊
• 第 3 層：Web 層 -> 業務服務層 的負載均衡。經過服務治理框架的負載均衡模塊
• 第 4 層：業務服務層 -> 數據存儲層 的負載均衡。經過數據的水平分佈，數據均勻了，理論上請求也會均勻。好比經過買家ID分片相似

原創不易，爭取多畫圖，圖解勝千言（泥瓦匠@bysocket.com）

參考資料：

• 《關於負載均衡的一切》https://mp.weixin.qq.com/s/xv...
• 《Dubbo 的負載均衡》http://dubbo.apache.org/zh-cn...
• https://zh.wikipedia.org/wiki...