負載均衡常用手段解析
作者 | Laura Nolan，Murali Suriar
譯者 | Key 先森
包括 CDN（內容交付網路）和雲提供商在內，多站點的大型互聯網系統可以選擇多種方式來均衡進入其網路的流量。在本文中，我們將描述常見的流量均衡設計，包括技術和權衡手段。
如果你是早期的雲計算服務提供商，你可以使用一個單獨的客戶 web 伺服器，為它分配一個 IP 地址，並配置一個 DNS（域名系統）記錄來將它與一個易讀的名字關聯起來，之後通過 BGP（邊界網關協議）來傳播 IP 地址，這是種在網路間交換路由信息的標準方式。
在冗餘的網路路徑上分發流量，在不可用的基礎設施周圍進行路由來提高可用性（會導致不對稱路由等現象），這些從本質上講並不是負載均衡。
簡單的 DNS 負載均衡
隨著客戶服務流量的增長，業務方希望獲得更高的可用性。你添加了另一個具有公網 IP 地址的 web 伺服器，並更新了 DNS 記錄來將用戶引導到這兩個 web 伺服器（希望稍微公平一些）。直到某一個 web 伺服器意外宕機前，這種方法都是可行的。假設你快速檢測到故障，可以通過更新 DNS 配置（手動方式或使用軟體）來停止引用損壞的伺服器。
遺憾的是，由於 DNS 記錄是有緩存的，這些緩存記錄可能會在客戶端或者 DNS 層次結構中的其他名稱伺服器中，在它們過期之前，大約有 50% 的請求仍然可能失敗。DNS 記錄的 TTL（time to live，生存時間）通常為幾分鐘或更長，因此這會對系統的可用性造成重大影響。
更糟糕的是一些客戶端完全忽略了 TTL，所以一些請求將在一段時間內被定向到已經宕機的 web 伺服器上。設置非常短的 DNS TTL 也不是什麼好主意；這意味著 DNS 服務的負載增加，延遲增加，因為客戶端不得不更加頻繁地執行 DNS 查找。如果你的 DNS 服務不可用，那麼使用更短的 TTL 訪問服務將更快地降級，因為緩存服務 IP 地址的客戶端更少。
增加網路負載均衡
為了解決這個問題，你可以添加一對冗餘的 4 層（Layer 4）網路均衡器，並在相同的虛擬 IP（VIP）地址提供服務。它們可以是硬體設備，或者像 HAProxy 這樣的軟體均衡器。這意味著 DNS 記錄僅僅指向虛擬 IP 而不再做負載均衡。
4 層負載均衡器將來自用戶的連接均衡分布在兩個 web 伺服器上
4 層均衡器將來自網際網路的流量均衡地引導至後端伺服器。這通常是基於每個 IP 包的 5 元組的哈希（一個數學函數）完成的：源 IP 地址和目標 IP 地址，以及埠加上協議（如 TCP 或 UDP）。這種方式快速、高效（並且仍然維持了 TCP 的基本屬性），並且不需要均衡器維護每個連接的狀態。
4 層均衡器可以進行健康檢查，並僅僅向那些通過檢查的 web 伺服器發送流量。與 DNS 均衡不同的是，如果一個 web 伺服器崩潰，將流量重定向到另一個 web 伺服器上的延遲很小，儘管現有連接將被重置。
4 層均衡器可以做加權平均，處理不同容量的後端，它為運維人員提供了強大的能力和靈活性，同時在計算能力方面相對便宜。
走向多站點
系統繼續擴張。即使你的數據中心出現故障，你的客戶也希望能繼續保持運轉。你會構建一個新的數據中心，其中包含自己的一組後端服務和另一組 4 層均衡器，它們在與之前一樣的虛擬 IP 上提供服務。DNS 設置不變。這兩個站點的邊緣路由器都在傳播地址信息，包括服務的虛擬 IP。根據終端用戶和系統之間的網路連接情況，以及它們的路由策略配置，發送到虛擬 IP 的請求可以到達任一個站點。這被稱為 anycast（任播）。大多數情況下，這種方法都很有效。如果其中一個站點出現故障，你可以停止通過 BGP 傳播服務虛擬 IP，這樣流量就可以迅速轉移到另一個站點。
使用 anycast（任播）從多個站點提供服務
這個設置有幾個問題。最糟糕的是，你無法控制流量的走向或者限制發送到某個特定站點的流量。通常，決定路由的網路協議和配置應該將用戶路由到最近的站點，不過就網路延遲而言，你並沒有明顯的方法來實現這個目標。
在多站點系統中控制入站請求
為了維持穩定性，你需要控制每個站點的流量，你可以為每個站點分配不同的虛擬 IP，並使用 DNS 的簡單循環或加權 循環 來均衡流量。
從多個站點提供服務：每個站點使用一個主虛擬 IP，二級站點備份，使用地理感知 DNS
現在產生了兩個新的問題。
首先，使用 DNS 均衡意味著你有緩存記錄，這不太適用於那些需要迅速重定向流量的場景。
第二，每當用戶做一次新的 DNS 查詢，虛擬 IP 會將用戶連接到一個隨機的站點，而不一定是離用戶最近的那一個。如果你的服務站點分布廣泛，根據用戶和服務站點之間的網路延遲，各個用戶感知到的系統響應性能會有較大波動。
讓每個站點不斷傳播虛擬 IP，並為所有其他站點（以及任何有問題的站點的虛擬 IP）提供服務，你可以通過這種方式解決第一個問題。一些網路技巧（比如從備份中傳播不那麼特殊的路由信息）可以確保虛擬 IP 對應的主站只要是可用的，那麼它便是首選。這是通過 BGP 完成的，因此在更新 BGP 後的一到兩分鐘內，我們應該會看到流量的移動。
除了讓距離用戶最近的健康站點為其提供服務以外，並沒有一個更加優雅的選擇。很多大型互聯網服務嘗試使用 DNS 來向不同位置的用戶返回不同的結果，並在一定程度上取得了成功。不過這種方法總是有點 複雜和容易出錯，因為網際網路的定址方案並不是按地理位置組織的，地址塊可以改變位置（例如，當公司重新組織其網路時），很多終端用戶仍然可以通過緩存名稱伺服器獲得服務。
增加 7 層負載均衡
隨著時間的推移，你的客戶開始對一些更加高級的特性提出要求。
雖然 4 層負載均衡器可以高效地在多個 web 伺服器之間分配負載，但這種分配是只在源 IP 地址和目標 IP 地址、協議和埠上進行的。4 層均衡器對請求的內容一無所知，所以也無法實現很多高級特性。相對而言，7 層（L7）負載均衡器知道請求的結構和內容，可以做得更多。
在 7 層均衡器中可以實現的一些特性包括緩存、限流、錯誤注入和代價敏感的負載均衡（部分請求需要更多的服務端處理時間）。
它們還可以基於請求的屬性（例如 HTTP cookies）進行均衡、終止 SSL 連接，並幫助抵禦應用層拒絕服務（DoS）攻擊。7 層均衡器成本較高，不易擴容——它們為處理請求做了更多的計算，而且每個活動請求都會消耗一些系統資源。在一個或多個 7 層均衡器池前運行 4 層均衡器可以幫助解決擴展問題。
寫在最後
負載均衡是一個複雜的難題。除了本文描述的策略之外，還有不同的 負載均衡演算法、用於實現負載均衡器的高可用技術、客戶端負載均衡技術以及最近興起的服務網格。
隨著雲計算的發展，核心的負載均衡模式也在不斷演進，大型 web 服務也將繼續改進負載均衡所能提供的控制和靈活性。
英文原文：
https://opensource.com/article/18/10/internet-scale-load-balancing
本文彩蛋
解決技術難題，除了具備過硬的技術理論知識的儲備，你還需要掌握一些好用的開發工具。近年來，微服務有多熱相信不用我贅述。微服務是一種用於開發高度可伸縮軟體系統的架構風格。這種架構可用於開發企業、政府、學校和慈善機構的企業級應用。InfoQ 編輯準備了一份頂級的微服務開源工具清單送給大家，請在公眾號對話框回復關鍵詞：微服務，獲取清單詳細內容。
TAG:InfoQ |