摘要:是的默認負載均衡策略。一致性哈希負載均衡。所以負載均衡是分布式系統(tǒng)架構(gòu)設(shè)計中必須考慮的因素之一??紤]主要是如何讓下游接收到的請求是均勻分布的第層客戶端層反向代理層的負載均衡。通過輪詢第層反向代理層層的負載均衡。
一、 什么是負載均衡?
什么是負載均衡?
記得第一次接觸 Nginx 是在實驗室,那時候在服務(wù)器部署網(wǎng)站需要用 Nginx 。Nginx 是一個服務(wù)組件,用來反向代理、負載平衡和 HTTP 緩存等。那么這里的 負載均衡 是什么?
負載均衡(LB,Load Balance),是一種技術(shù)解決方案。用來在多個資源(一般是服務(wù)器)中分配負載,達到最優(yōu)化資源使用,避免過載。
資源,相當于每個服務(wù)實例的執(zhí)行操作單元,負載均衡就是將大量的數(shù)據(jù)處理操作分攤到多個操作單元進行執(zhí)行,用來解決互聯(lián)網(wǎng)分布式系統(tǒng)的大流量、高并發(fā)和高可用的問題。那什么是高可用呢?
二、什么是高可用?首先了解什么是高可用?
這是 CAP 定理是分布式系統(tǒng)的基礎(chǔ),也是分布式系統(tǒng)的 3 個指標:
Consistency(一致性)
Availability(可用性)
Partition tolerance(分區(qū)容錯性)
那高可用(High Availability)是什么?高可用,簡稱 HA,是系統(tǒng)一種特征或者指標,通常是指,提供一定性能上的服務(wù)運行時間,高于平均正常時間段。反之,消除系統(tǒng)服務(wù)不可用的時間。
衡量系統(tǒng)是否滿足高可用,就是當一臺或者多臺服務(wù)器宕機的時候,系統(tǒng)整體和服務(wù)依然正??捎谩?/p>
舉個例子,一些知名的網(wǎng)站保證 4 個 9 以上的可用性,也就是可用性超過 99.99%。那 0.01% 就是所謂故障時間的百分比。比如電商網(wǎng)站有贊,服務(wù)不可用會造成商家損失金錢和用戶。那么在提高可用性基礎(chǔ)上同時,對系統(tǒng)宕機和服務(wù)不可用會有補償。
比如下單服務(wù),可以使用帶有負載均衡的多個下單服務(wù)實例,代替單一的下單服務(wù)實例,即使用冗余的方式來提高可靠性。
總而言之,負載均衡(Load Balance)是分布式系統(tǒng)架構(gòu)設(shè)計中必須考慮的因素之一。一般通過負載均衡,冗余同一個服務(wù)實例的方式,解決分布式系統(tǒng)的大流量、高并發(fā)和高可用的問題。負載均衡核心關(guān)鍵:在于是否分配均勻。
三、常見的負載均衡案例場景1:微服務(wù)架構(gòu)中,網(wǎng)關(guān)路由到具體的服務(wù)實例 hello:
兩個相同的服務(wù)實例 hello service ,一個端口 8000 ,另一個端口 8082
通過 Kong 的負載均衡 LB 功能,讓請求均勻的分發(fā)到兩個 hello 服務(wù)實例
Kong 的負載均衡策略算法很多:默認 weighted-round-robin 算法,還有 consumer: consumer id 作為 hash 算法輸入值等
場景2:微服務(wù)架構(gòu)中,A 服務(wù)調(diào)用 B 服務(wù)的集群。通過了 Ribbon 客戶端負載均衡組件:
負載均衡策略算法并不高級,最簡單的是隨機選擇和輪循
四、互聯(lián)網(wǎng)分布式系統(tǒng)解決方案常見的互聯(lián)網(wǎng)分布式系統(tǒng)架構(gòu)分為幾層,一般如下:
客戶端層:比如用戶瀏覽器、APP 端
反向代理層:技術(shù)選型 Nignx 或者 F5 等
Web 層:前后端分離場景下, Web 端可以用 NodeJS 、 RN 、Vue
業(yè)務(wù)服務(wù)層:用 Java 、Go,一般互聯(lián)網(wǎng)公司,技術(shù)方案選型就是 SC 或者 Spring Boot + Dubbo 服務(wù)化
數(shù)據(jù)存儲層:DB 選型 MySQL ,Cache 選型 Redis ,搜索選型 ES 等
一個請求從第 1 層到第 4 層,層層訪問都需要負載均衡。即每個上游調(diào)用下游多個業(yè)務(wù)方的時候,需要均勻調(diào)用。這樣整體系統(tǒng)來看,就比較負載均衡
第 1 層:客戶端層 -> 反向代理層 的負載均衡客戶端層 -> 反向代理層的負載均衡如何實現(xiàn)呢?
答案是:DNS 的輪詢。 DNS 可以通過 A (Address,返回域名指向的 IP 地址)設(shè)置多個 IP 地址。比如這里訪問 bysocket.com 的 DNS 配置了 ip1 和 ip2 。為了反向代理層的高可用,至少會有兩條 A 記錄。這樣冗余的兩個 ip 對應(yīng)的 nginx 服務(wù)實例,防止單點故障。
每次請求 bysocket.com 域名的時候,通過 DNS 輪詢,返回對應(yīng)的 ip 地址,每個 ip 對應(yīng)的反向代理層的服務(wù)實例,也就是 nginx 的外網(wǎng)ip。這樣可以做到每一個反向代理層實例得到的請求分配是均衡的。
第 2 層:反向代理層 -> Web 層 的負載均衡反向代理層 -> Web 層 的負載均衡如何實現(xiàn)呢?
是通過反向代理層的負載均衡模塊處理。比如 nginx 有多種均衡方法:
請求輪詢。請求按時間順序,逐一分配到 web 層服務(wù),然后周而復(fù)始。如果 web 層服務(wù) down 掉,自動剔除
upstream web-server { server ip3; server ip4; }
ip 哈希。按照 ip 的哈希值,確定路由到對應(yīng)的 web 層。只要是用戶的 ip 是均勻的,那么請求到 Web 層也是均勻的。
還有個好處就是同一個 ip 的請求會分發(fā)到相同的 web 層服務(wù)。這樣每個用戶固定訪問一個 web 層服務(wù),可以解決 session 的問題。
upstream web-server { ip_hash; server ip3; server ip4; }
weight 權(quán)重 、 fair、url_hash 等
第 3 層:Web 層 -> 業(yè)務(wù)服務(wù)層 的負載均衡Web 層 -> 業(yè)務(wù)服務(wù)層 的負載均衡如何實現(xiàn)呢?
比如 Dubbo 是一個服務(wù)治理方案,包括服務(wù)注冊、服務(wù)降級、訪問控制、動態(tài)配置路由規(guī)則、權(quán)重調(diào)節(jié)、負載均衡。其中一個特性就是智能負載均衡:內(nèi)置多種負載均衡策略,智能感知下游節(jié)點健康狀況,顯著減少調(diào)用延遲,提高系統(tǒng)吞吐量。
為了避免避免單點故障和支持服務(wù)的橫向擴容,一個服務(wù)通常會部署多個實例,即 Dubbo 集群部署。會將多個服務(wù)實例成為一個服務(wù)提供方,然后根據(jù)配置的隨機負載均衡策略,在20個 Provider 中隨機選擇了一個來調(diào)用,假設(shè)隨機到了第7個 Provider。LoadBalance 組件從提供者地址列表中,使用均衡策略,選擇選一個提供者進行調(diào)用,如果調(diào)用失敗,再選另一臺調(diào)用。
Dubbo內(nèi)置了4種負載均衡策略:
RandomLoadBalance:隨機負載均衡。隨機的選擇一個。是Dubbo的默認負載均衡策略。
RoundRobinLoadBalance:輪詢負載均衡。輪詢選擇一個。
LeastActiveLoadBalance:最少活躍調(diào)用數(shù),相同活躍數(shù)的隨機?;钴S數(shù)指調(diào)用前后計數(shù)差。使慢的 Provider 收到更少請求,因為越慢的 Provider 的調(diào)用前后計數(shù)差會越大。
ConsistentHashLoadBalance:一致性哈希負載均衡。相同參數(shù)的請求總是落在同一臺機器上。
同樣,因為業(yè)務(wù)的需要,也可以實現(xiàn)自己的負載均衡策略
第 4 層:業(yè)務(wù)服務(wù)層 -> 數(shù)據(jù)存儲層 的負載均衡數(shù)據(jù)存儲層的負載均衡,一般通過 DBProxy 實現(xiàn)。比如 MySQL 分庫分表。
當單庫或者單表訪問太大,數(shù)據(jù)量太大的情況下,需要進行垂直拆分和水平拆分兩個維度。比如水平切分規(guī)則:
Range 、 時間
hash 取模,訂單根據(jù)店鋪ID 等
但伴隨著這塊的負載會出現(xiàn)下面的問題,需要解決:
分布式事務(wù)
跨庫 join 等
現(xiàn)狀分庫分表的產(chǎn)品方案很多:當當 sharding-jdbc、阿里的 Cobar 等
五、小結(jié)對外看來,負載均衡是一個系統(tǒng)或軟件的整體。對內(nèi)看來,層層上下游調(diào)用。只要存在調(diào)用,就需要考慮負載均衡這個因素。所以負載均衡(Load Balance)是分布式系統(tǒng)架構(gòu)設(shè)計中必須考慮的因素之一??紤]主要是如何讓下游接收到的請求是均勻分布的:
第 1 層:客戶端層 -> 反向代理層 的負載均衡。通過 DNS 輪詢
第 2 層:反向代理層 -> Web 層 的負載均衡。通過 Nginx 的負載均衡模塊
第 3 層:Web 層 -> 業(yè)務(wù)服務(wù)層 的負載均衡。通過服務(wù)治理框架的負載均衡模塊
第 4 層:業(yè)務(wù)服務(wù)層 -> 數(shù)據(jù)存儲層 的負載均衡。通過數(shù)據(jù)的水平分布,數(shù)據(jù)均勻了,理論上請求也會均勻。比如通過買家ID分片類似
原創(chuàng)不易,爭取多畫圖,圖解勝千言(泥瓦匠@bysocket.com)
參考資料:
《關(guān)于負載均衡的一切》https://mp.weixin.qq.com/s/xv...
《Dubbo 的負載均衡》http://dubbo.apache.org/zh-cn...
https://zh.wikipedia.org/wiki...
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://m.hztianpu.com/yun/75440.html
摘要:今天小數(shù)又漂洋過海給大家運來一篇干貨,在今天的文章中,我們將一同了解如何在上規(guī)劃一套成功的微服務(wù)架構(gòu)。通過在基于的微服務(wù)之前安裝反向代理,輸入的請求可被正確分發(fā)至多主機上的任意數(shù)量容器實例當中。規(guī)劃技巧四安裝反向代理及或管理平臺。 今天小數(shù)又漂洋過海給大家運來一篇干貨,在今天的文章中,我們將一同了解如何在Docker上規(guī)劃一套成功的微服務(wù)架構(gòu)。 Docker的人氣仍然持續(xù)升溫,這主要歸...
摘要:另一個用戶請求過來,負載均衡器指派這個請求到服務(wù)器。這樣就平攤了請求這種方式就叫做輪詢策略還有很多種,就看你想怎么實現(xiàn)了,反正這個邏輯的代碼放在負載均衡器上。 前言 只有光頭才能變強。文本已收錄至我的GitHub倉庫,歡迎Star:https://github.com/ZhongFuCheng3y/3y 這本書買了一段時間了,之前在杭州沒帶過去,現(xiàn)在讀完第三章,來做做筆記 showI...
閱讀 4239·2021-09-22 15:34
閱讀 2845·2021-09-22 15:29
閱讀 562·2019-08-29 13:52
閱讀 3410·2019-08-29 11:30
閱讀 2344·2019-08-26 10:40
閱讀 908·2019-08-26 10:19
閱讀 2316·2019-08-23 18:16
閱讀 2395·2019-08-23 17:50