GitHub 新負載均衡系統的設計曆程

在過去的一年中，github一直在開發一個新的負載均衡系統——github load balancer（glb）。這個系統想要通過擴充使用普通的硬體來應對每天數十億的連接配接。github工程師joe williams和theo julienne講解了glb的設計曆程。

github根本的設計目标之一是希望能“擴充”ip，即，将單個公網ip的資料流量通過多個等價的連接配接分發到不同的目标機器。這通常是通過等價多路徑路由（ecmp）來實作的，進而擴大帶寬。然而，ecmp在各個ecmp節點發生變化，比如在節點失效或因維護需求而被移除時，表現不是很好。對github來說這是使用ecmp最大的缺陷。

是以，github工程師考慮使用l4/l7分離政策，将負載均衡節點分為兩層，l4和l7，osi層據此來提供各個節點分發請求時需要的資訊。l4使用來源及目标ip位址和tcp端口号進行路由，而l7使用應用層資訊來路由，這通常使用http協定。在l4/l7分離的設計中，l4節點通過ecmp拆分流量到l7節點，我們稱前者為“director”節點，後者為“proxy”節點。williams和julienne解釋到，通常ipvs/lvs被應用于l4節點，而l7節點使用haproxy或類似工具。

l4/l7分離帶來最大的好處是，隻要簡單地将l7節點從服務新連接配接的節點池中移除，并服務到節點上現有連接配接全部結束，就可以在不影響正常運作的情況下移除一個l7節點。但另一方面，在l4節點失效或被移除時會導緻通路中斷。由于git無法進行重試或恢複已斷開的連接配接，解決這個問題對github來說尤為關鍵。

github通過使用rendezvous雜湊演算法解決了這個最終問題，這個算法使director節點間協定應該由哪個proxy節點來處理某個請求。glb結合使用rendezvous雜湊演算法與伺服器直接傳回模式，後者使傳回封包直接從proxy節點傳回給用戶端，進而繞過了原來配置設定請求到proxy的director節點。在glb中，使用rendezvous哈希的基本思想是要将請求轉發表在各個director節點間共享并保持同步。這大體上能保證即使一個director節點失效或被移除，其他director節點可以代替并将現存連接配接配置設定到正确的proxy節點。