讀釋出！設計與部署穩定的分布式系統2版筆記24_互聯層之負載均衡

1. 水準擴充

1.1. 有助于提高系統的整體容量和韌性

1.2. 現階段建構的幾乎所有系統，都使用了能夠水準擴充的執行個體農場

1.3. 引入了對負載均衡的需求

2. 負載均衡

2.1. 在整個執行個體池中分發請求，進而盡可能快地正确響應所有請求

2.2. 負載均衡會建立映射到執行個體池的“虛拟IP位址”

2.3. DNS輪詢視為負載均衡的一種手段

2.4. 負載均衡器是系統服務中不可或缺的組成部分，不能将其僅僅視為網絡基礎設施的一部分

2.5. 建構服務和規劃部署時，需要與負載均衡設計結合起來

2.5.1. 如果系統結構将負載均衡器處理為其他團隊管理的“超出管理範圍的部分”，那麼甚至可以考慮在可控範圍内實施一層軟體負載均衡，完全安裝在網絡硬體負載均衡器後

2.5.2. 軟體負載均衡器在OSI應用層上運作，成本低，易操作

3. 主動負載均衡

3.1. 所有類型的主動負載均衡器，都會監聽一個或多個套接字

3.2. 這些套接字在一個或多個IP位址上，這些IP位址通常稱為“虛拟IP位址”或VIP

3.3. 需要使用的負載均衡算法

3.4. 需要對執行個體進行的健康狀況檢查

3.5. 運用哪種會話黏性進行用戶端會話

3.6. 當執行個體池中沒有可用執行個體時如何處理傳入請求

3.7. 對發出調用的應用程式而言，負載均衡器應是無形的

3.8. 如果用戶端能感覺到負載均衡器，那麼很可能是負載均衡器停機了

3.9. 圖示

4. 反向代理伺服器

4.1. 反向代理伺服器後的服務提供方執行個體，需要生成多個URL，包含虛拟IP位址對應的DNS名字，而不是自身的主機名

4.2. 無論如何都不應該使用執行個體自身的主機名

4.3. 通的正向代理伺服器采用多路複用将傳出的多個調用組合到單個源IP位址上

4.4. 反向代理伺服器正相反，它采用逆多路複用将傳入單個IP位址上的調用分散到多個位址上

4.5. Squid、HAProxy、Apache httpd和nginx等都是很好的反向代理伺服器，能夠起到負載均衡的作用

4.6. 講規矩”的代理伺服器，會将X-Forwarded-For這樣的頭部資訊添加到傳入的HTTP請求中

4.7. 服務可以使用自定義的日志格式記錄

4.8. 在反向代理伺服器上配置緩存，通過緩存響應資訊來減少服務執行個體的負載

4.8.1. 有助于減少内部網絡上的流量

4.9. 由于反向代理伺服器需要處理每個請求，是以它可能很快就不堪重負

4.10. 圖示

5. 硬體負載均衡

5.1. 與反向代理伺服器功能類似的專用網絡裝置

5.2. 和反向代理軟體一樣，這些裝置提供同種類型的攔截和重定向功能

5.3. 相比反向代理軟體，硬體負載均衡器運作時更靠近網絡，是以能夠更好地提供容量和吞吐量

5.3.1. 能滿足的網絡規模更大，但它要求直接通路網絡，還需要特定的工程技能

5.4. 具有應用程式感覺能力，并提供在OSI模型第4層到第7層切換的能力

5.4.1. 可以負載均衡所有面向連接配接的協定，而不僅僅是HTTP或FTP

5.5. 可以将流量從一個站點完全切換到另一個站點

5.5.1. 在災難恢複時特别有用，可以将流量轉移到故障切換站點

5.6. 硬體負載均衡器與GSLB配合使用效果更佳

5.7. 最大的缺點是價格

5.7.1. 低端配置的價格大概是幾萬美元

5.7.2. 高端配置的價格輕易就能達到幾十萬美元

5.8. F5的Big-IP産品

6. 健康狀況檢查

6.1. 負載均衡器不會将流量發送到未通過若幹健康狀況檢查的執行個體

6.2. 是負載均衡器配置的重要組成部分

6.3. 良好的健康狀況檢查可以確定請求能夠執行成功，而不僅僅是服務正在監聽套接字

7. 會話黏性

7.1. 負載均衡器會嘗試将重複的請求引向同一個執行個體，這對應用程式伺服器中的有狀态服務很有幫助

7.1.1. 有助于縮短有狀态服務的響應時間

7.2. 會話黏性需要某種方式來确定如何将“重複請求”分組到一個邏輯會話中

7.3. 黏性會話的缺點是它會阻止負載在機器間均勻分布

8. 按請求類型分隔流量

8.1. 使用基于内容感覺的負載均衡

8.1.1. 有效運用負載均衡器的方法是“基于内容的路由”

8.2. 請求中的某些内容對負載均衡器必須是可識别的