每個(gè)負(fù)載均衡器都是反向代理，但并非每個(gè)反向代理都必須是負(fù)載均衡器。

問題： OSI模型是什么樣的？

問題： 負(fù)載均衡器的需求是什么？

答案 → 為了創(chuàng)建一個(gè)容錯(cuò)系統(tǒng)，使得當(dāng)客戶端向負(fù)載均衡器發(fā)出請求時(shí)，它可以與一個(gè)或多個(gè)后端進(jìn)行通信。

問題： 解釋一下第4層負(fù)載均衡器是如何工作的？

答案 → 第4層負(fù)載均衡器的工作原理如下：

(1) 握手 → 第4層負(fù)載均衡器首先與后端服務(wù)器建立TCP連接。

(2) 預(yù)熱 → 負(fù)載均衡器可以與后端建立多個(gè)基于TCP的連接，然后保持這些連接處于活動(dòng)狀態(tài)。這是為了確保每當(dāng)客戶端連接到負(fù)載均衡器時(shí)，它不必每次都經(jīng)歷連接預(yù)熱過程。

(3) 客戶端連接 → 當(dāng)客戶端連接到第4層負(fù)載均衡器時(shí)，該連接將在負(fù)載均衡器級(jí)別具有狀態(tài)，并將映射到后端服務(wù)器的任何一個(gè)連接。因此，第4層負(fù)載均衡器是有狀態(tài)的。

• 第4層負(fù)載均衡器只處理端口和IP地址。
• 數(shù)據(jù)被分段，但它不能簡單地觸摸數(shù)據(jù)或解析數(shù)據(jù)。
• 客戶端發(fā)送到第4層負(fù)載均衡器的所有數(shù)據(jù)段都將最終發(fā)送到某個(gè)服務(wù)器上的一個(gè)專用連接。
• 如果客戶端向第4層負(fù)載均衡器發(fā)送一些數(shù)據(jù)，它不能只將一個(gè)段發(fā)送到一個(gè)服務(wù)器，然后將另一個(gè)段發(fā)送到另一個(gè)服務(wù)器，因?yàn)閿?shù)據(jù)將會(huì)損壞，一切都會(huì)變得糟糕。

問題： 第4層負(fù)載均衡器是否也充當(dāng)NAT層？

答案 → 是的，第4層負(fù)載均衡器充當(dāng)客戶端的NAT層/網(wǎng)關(guān)/路由器。

• 請求 → 在與后端建立全新的TCP連接時(shí)，負(fù)載均衡器更改目標(biāo)IP地址。客戶端完全不知道這個(gè)概念。

• 響應(yīng) → 第4層負(fù)載均衡器知道，從應(yīng)用連接接收到的任何內(nèi)容都必須發(fā)送回帶有原始客戶端的這個(gè)連接。這是負(fù)載均衡器保持的映射表。

問題： 演示從客戶端到后端的基于Http的調(diào)用（Restful API調(diào)用）的例子？

答案 → 想象一下客戶端向負(fù)載均衡器發(fā)送Http調(diào)用。還想象一下，這個(gè)特定的請求被分為2個(gè)段。

步驟 #1) 請求到達(dá)負(fù)載均衡器，然后負(fù)載均衡器選擇將此請求的所有段發(fā)送到某個(gè)后端服務(wù)器。

步驟 #2) 現(xiàn)在，假設(shè)客戶端發(fā)送的是另一個(gè)段（段#3），然后將其寫回同一連接。

• 在這個(gè)第4層負(fù)載均衡器上沒有緩沖。它只是讀取并轉(zhuǎn)發(fā)數(shù)據(jù)段。
• 第4層負(fù)載均衡器不知道HTTP。它只知道和理解TCP。傳遞到這個(gè)第4層負(fù)載均衡器的所有數(shù)據(jù)（無論是基于gRPC的請求還是基于套接字的連接），它都將所有這些數(shù)據(jù)視為數(shù)據(jù)段。
• 但是，根據(jù)客戶端端的MTU和后端服務(wù)器端的MTU，負(fù)載均衡器可能會(huì)執(zhí)行某種優(yōu)化。它可能僅僅接收段并將該段進(jìn)一步細(xì)分為多個(gè)段，反之亦然。TCP始終會(huì)嘗試擠取盡可能多的性能。

步驟 #3) 現(xiàn)在，假設(shè)同一客戶端在同一連接上發(fā)起了另一個(gè)請求，那么該請求也將首先被讀取，然后寫回后端服務(wù)器。

步驟 #4) 現(xiàn)在，假設(shè)有一位不同的客戶端發(fā)起了另一個(gè)請求，然后根據(jù)負(fù)載均衡算法，該請求可能會(huì)轉(zhuǎn)發(fā)到另一個(gè)后端服務(wù)器。

問題： 提供L4負(fù)載均衡器的公司有哪些？

答案 → 像Radware和F5-BigIp等公司提供L4負(fù)載均衡器。

問題： L4負(fù)載均衡器的優(yōu)缺點(diǎn)是什么？

(1) 以下是L4 LB的優(yōu)點(diǎn)：

• 這是一種簡單的負(fù)載均衡策略。它只是不讀取第7層的內(nèi)容。
• 它更安全，因?yàn)樗粡腖7讀取數(shù)據(jù)。
• 它與任何協(xié)議一起工作。它對協(xié)議是不可知的。

(2) 以下是L4 LB的缺點(diǎn)：

• 它不聰明，不能與微服務(wù)一起工作。這是有粘性連接的。每個(gè)連接都沒有負(fù)載均衡。盡管我們可以配置IP和端口組合，但在生產(chǎn)系統(tǒng)中不建議這樣做。
• 如果客戶端發(fā)送POST請求或發(fā)送GET請求或發(fā)送PATCH請求，L4負(fù)載均衡器對此一無所知。它只看到這些請求作為進(jìn)來的數(shù)據(jù)段。
• 它不能支持緩存，因?yàn)樗恢酪彺媸裁矗驗(yàn)樗鼰o法讀取L7層中的數(shù)據(jù)。
• 在L4 LB上，我們無法執(zhí)行任何類似于“阻止某些用戶”、“阻止某些標(biāo)頭”、“阻止某些身份驗(yàn)證方法”的操作。

問題： 解釋第7層負(fù)載均衡器是如何工作的？

答案 → 第7層負(fù)載均衡器的工作原理如下：

(1) 握手 → 第7層負(fù)載均衡器還與后端服務(wù)器建立TCP連接。

(2) 預(yù)熱 → 負(fù)載均衡器可以與后端建立多個(gè)基于TCP的連接，然后保持這些連接處于活動(dòng)狀態(tài)。這是為了確保每當(dāng)客戶端連接到負(fù)載均衡器時(shí)，它不必每次都經(jīng)歷連接預(yù)熱過程。

(3) 客戶端連接 → 當(dāng)客戶端連接到第7層負(fù)載均衡器時(shí)，該連接將成為特定于協(xié)議的。

• 第7層負(fù)載均衡器需要理解發(fā)送到它的任何內(nèi)容。
• 任何邏輯請求都將首先在L7-LB級(jí)別緩沖，理解它（即解密數(shù)據(jù)），解析它，然后決定將請求轉(zhuǎn)發(fā)到后端服務(wù)器的其中一個(gè)。

注意： 如果您希望L7 LB面向外部客戶端，則：

• 您的L7 LB必須具有存儲(chǔ)在其上的證書，因?yàn)榇薒7 LB必須首先證明其身份。
• L7 LB還必須解密數(shù)據(jù)。

問題： L7負(fù)載均衡器如何處理基于HTTP的請求？

步驟 #1) 首先，它接收請求并將其發(fā)送到后端服務(wù)器1。

步驟 #2) 接下來，假設(shè)同一客戶端發(fā)送了另一個(gè)請求，然后L7 LB實(shí)際上也可以將其轉(zhuǎn)發(fā)到其他后端服務(wù)器，因?yàn)長7 LB是無狀態(tài)的。

問題： L7負(fù)載均衡器的優(yōu)缺點(diǎn)是什么？

(1) 以下是L4 LB的優(yōu)點(diǎn)：

• 它提供智能的負(fù)載均衡策略。例如，如果請求是針對端點(diǎn)“/pictures”的，則可以將請求轉(zhuǎn)發(fā)到特定的主機(jī)組，可能是Pictures微服務(wù)。
• 另一個(gè)例子，如果請求是針對端點(diǎn)GET“/comments”的，則可以將請求轉(zhuǎn)發(fā)到特定的主機(jī)組，可能是評(píng)論微服務(wù)。
• 另一個(gè)例子，如果請求是針對端點(diǎn)POST“/comments”的，則它是寫入密集型工作負(fù)載，那么可能轉(zhuǎn)到另一個(gè)主機(jī)組，因?yàn)樗哂袑榇藢懭朊芗凸ぷ髫?fù)載設(shè)計(jì)的特定數(shù)據(jù)庫。
• 因此，L7 LB非常適合微服務(wù)。
• 我們還可以在此L7負(fù)載均衡器上執(zhí)行AuthN和AuthZ。?我們還可以緩存結(jié)果。

(2) 以下是L4 LB的缺點(diǎn)：

• 它很昂貴，因?yàn)樗龈嗟墓ぷ?，比如緩沖數(shù)據(jù)，讀取數(shù)據(jù)，解密數(shù)據(jù)，終止TLS連接。
• 它必須共享TLS證書。
• 它可能效率不高，實(shí)際上可能成為瓶頸，因?yàn)樗诰彌_大量數(shù)據(jù)并解析它。它可能會(huì)減慢速度。
• 它需要理解協(xié)議。