建站
咨詢
售后
建站咨詢
新聞中心
負載均衡是高可用網絡基礎架構的關鍵組件，通常用于將工作負載分布到多個服務器來提高網站、應用、數據庫或其他服務的性能和可靠性，下面為大家簡單介紹一下分布式系統(tǒng)負載均衡。
什么是負載均衡？
記得第一次接觸 Nginx 是在實驗室，那時候在服務器部署網站需要用 Nginx 。Nginx 是一個服務組件，用來反向代理、負載平衡和 HTTP 緩存等。那么這里的 負載均衡 是什么？
負載均衡（LB，Load Balance），是一種技術解決方案。用來在多個資源（一般是服務器）中分配負載，達到最優(yōu)化資源使用，避免過載。
資源，相當于每個服務實例的執(zhí)行操作單元，負載均衡就是將大量的數據處理操作分攤到多個操作單元進行執(zhí)行，用來解決互聯網分布式系統(tǒng)的大流量、高并發(fā)和高可用的問題。那什么是高可用呢？
什么是高可用？
首先了解什么是高可用？
這是 CAP 定理是分布式系統(tǒng)的基礎，也是分布式系統(tǒng)的 3 個指標：
Consistency（一致性）
Availability（可用性）
Partition tolerance（分區(qū)容錯性）
那高可用（High Availability）是什么？高可用，簡稱 HA，是系統(tǒng)一種特征或者指標，通常是指，提供一定性能上的服務運行時間，高于平均正常時間段。反之，消除系統(tǒng)服務不可用的時間。
衡量系統(tǒng)是否滿足高可用，就是當一臺或者多臺服務器宕機的時候，系統(tǒng)整體和服務依然正?？捎?。
舉個例子，一些知名的網站保證 4 個 9 以上的可用性，也就是可用性超過 99.99%。那 0.01% 就是所謂故障時間的百分比。比如電商網站有贊，服務不可用會造成商家損失金錢和用戶。那么在提高可用性基礎上同時，對系統(tǒng)宕機和服務不可用會有補償。
比如下單服務，可以使用帶有負載均衡的多個下單服務實例，代替單一的下單服務實例，即使用冗余的方式來提高可靠性。
總而言之，負載均衡（Load Balance）是分布式系統(tǒng)架構設計中必須考慮的因素之一。一般通過負載均衡，冗余同一個服務實例的方式，解決分布式系統(tǒng)的大流量、高并發(fā)和高可用的問題。負載均衡核心關鍵：在于是否分配均勻。
常見的負載均衡案例
場景1：微服務架構中，網關路由到具體的服務實例 hello：
– 兩個相同的服務實例 hello service ，一個端口 8000 ，另一個端口 8082
– 通過 Kong 的負載均衡 LB 功能，讓請求均勻的分發(fā)到兩個 hello 服務實例
– Kong 的負載均衡策略算法很多：默認 weighted-round-robin 算法，還有 consumer: consumer id 作為 hash 算法輸入值等
場景2：微服務架構中，A 服務調用 B 服務的集群。通過了 Ribbon 客戶端負載均衡組件：
– 負載均衡策略算法并不高級，最簡單的是隨機選擇和輪循
互聯網分布式系統(tǒng)解決方案
常見的互聯網分布式系統(tǒng)架構分為幾層，一般如下：
客戶端層：比如用戶瀏覽器、APP 端
反向代理層：技術選型 Nignx 或者 F5 等
Web 層：前后端分離場景下， Web 端可以用 NodeJS 、 RN 、Vue
業(yè)務服務層：用 Java 、Go，一般互聯網公司，技術方案選型就是 SC 或者 Spring Boot + Dubbo 服務化
數據存儲層：DB 選型 MySQL ，Cache 選型 Redis ，搜索選型 ES 等
一個請求從第 1 層到第 4 層，層層訪問都需要負載均衡。即每個上游調用下游多個業(yè)務方的時候，需要均勻調用。這樣整體系統(tǒng)來看，就比較負載均衡
第 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 有多種均衡方法：
請求輪詢。請求按時間順序，逐一分配到 web 層服務，然后周而復始。如果 web 層服務 down 掉，自動剔除
upstream web-server {
server ip3;
server ip4;
}
ip 哈希。按照 ip 的哈希值，確定路由到對應的 web 層。只要是用戶的 ip 是均勻的，那么請求到 Web 層也是均勻的。
還有個好處就是同一個 ip 的請求會分發(fā)到相同的 web 層服務。這樣每個用戶固定訪問一個 web 層服務，可以解決 session 的問題。
upstream web-server {
ip_hash;
server ip3;
server ip4;
}
weight 權重 、 fair、url_hash 等
第 3 層：Web 層 -> 業(yè)務服務層 的負載均衡
Web 層 -> 業(yè)務服務層 的負載均衡如何實現呢？
比如 Dubbo 是一個服務治理方案，包括服務注冊、服務降級、訪問控制、動態(tài)配置路由規(guī)則、權重調節(jié)、負載均衡。其中一個特性就是智能負載均衡：內置多種負載均衡策略，智能感知下游節(jié)點健康狀況，顯著減少調用延遲，提高系統(tǒng)吞吐量。
為了避免避免單點故障和支持服務的橫向擴容，一個服務通常會部署多個實例，即 Dubbo 集群部署。會將多個服務實例成為一個服務提供方，然后根據配置的隨機負載均衡策略，在20個 Provider 中隨機選擇了一個來調用，假設隨機到了第7個 Provider。LoadBalance 組件從提供者地址列表中，使用均衡策略，選擇選一個提供者進行調用，如果調用失敗，再選另一臺調用。
Dubbo內置了4種負載均衡策略:
RandomLoadBalance:隨機負載均衡。隨機的選擇一個。是Dubbo的默認負載均衡策略。
RoundRobinLoadBalance:輪詢負載均衡。輪詢選擇一個。
LeastActiveLoadBalance:最少活躍調用數，相同活躍數的隨機?；钴S數指調用前后計數差。使慢的 Provider 收到更少請求，因為越慢的 Provider 的調用前后計數差會越大。
ConsistentHashLoadBalance:一致性哈希負載均衡。相同參數的請求總是落在同一臺機器上。
同樣，因為業(yè)務的需要，也可以實現自己的負載均衡策略
第 4 層：業(yè)務服務層 -> 數據存儲層 的負載均衡
數據存儲層的負載均衡，一般通過 DBProxy 實現。比如 MySQL 分庫分表。
當單庫或者單表訪問太大，數據量太大的情況下，需要進行垂直拆分和水平拆分兩個維度。比如水平切分規(guī)則：
Range 、 時間
hash 取模，訂單根據店鋪ID 等
但伴隨著這塊的負載會出現下面的問題，需要解決：
分布式事務
跨庫 join 等
現狀分庫分表的產品方案很多：當當 sharding-jdbc、阿里的 Cobar 等
小結
對外看來，負載均衡是一個系統(tǒng)或軟件的整體。對內看來，層層上下游調用。只要存在調用，就需要考慮負載均衡這個因素。所以負載均衡（Load Balance）是分布式系統(tǒng)架構設計中必須考慮的因素之一?？紤]主要是如何讓下游接收到的請求是均勻分布的：
第 1 層：客戶端層 -> 反向代理層 的負載均衡。通過 DNS 輪詢
第 2 層：反向代理層 -> Web 層 的負載均衡。通過 Nginx 的負載均衡模塊
第 3 層：Web 層 -> 業(yè)務服務層 的負載均衡。通過服務治理框架的負載均衡模塊
第 4 層：業(yè)務服務層 -> 數據存儲層 的負載均衡。通過數據的水平分布，數據均勻了，理論上請求也會均勻。比如通過買家ID分片類似
分享題目：簡單介紹一下分布式系統(tǒng)負載均衡
網站地址：http://www.5511xx.com/article/cosiodi.html
