在過去的一年中，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節點。
最后Williams和Julienne談到他們計劃如何平滑地發布這個新負載均衡系統，并預計在近期開源該項目。
查看英文原文：How GitHub Designed its New Load Balancer
京公網安備 11010502049343號