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. 請求中的某些內容對負載均衡器必須是可識別的