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