[[172852]]

GitHub 負載均衡系統最初是為了處理 Git 的數十億日常連接而開發的。GitHub 將發布開源版的 GitHub 負載均衡軟件(GLB)，這是內部開發的負載均衡系統。

開發 GLB 的初衷是滿足 GitHub 的這一要求：每天處理數十億的 HTTP 連接、Git 連接和 SSH 連接。而如今，這家公司將通過開源來發布 GLB 的組件，到時會透露設計方面的細節。

GitHub 的高級基礎設施工程師喬·威廉斯(Joe Williams)和 GitHub 的基礎設施工程經理西奧·朱利恩(Theo Julienne)在一篇共同撰寫的公告中說：“在過去，我們的負載均衡層一向是比較復雜的組件之一。傳統上，我們縱向擴展這個部分，運行一小批運行 haproxy 的超大型機器，并使用非常特定的硬件配置，以便實現專門的 10G 鏈路故障切換機制。”

但是這個負載均衡平臺遇到瓶頸后，該公司開始著手開發自己的解決方案。這個新平臺要滿足某些目標，包括橫向擴展、高可用性、支持連接清空 (connection draining)，并且能應對分布式拒絕服務(DDoS)攻擊。“為了實現這些目標，我們需要重新考慮 IP 地址與主機之間的關系、我們的負載均衡層包括的各個層，以及連接是如何路由、控制和終結的。

[[172853]]

GitHub 在設計負載均衡平臺時，為流量引導器(traffic director)這層竭力改進常見模式。該公司最后選用了一種支持多個查詢的聚集哈希(rendezvous hashing)。每個代理主機存儲起來，并被分配一個狀態，然后處理連接清空。固定大小的轉發表生成后，使用聚集哈希的排序組件，每一行都填滿了代理服 務器的地址。表和代理主機狀態被發送到引導器服務器，并保持同步。

TCP 數據包一發送到引導器，源端 IP 就經過哈希處理，生成指向轉發表的一致性索引。數據包在注定發送到代理服務器內部 IP 的另一個 IP 數據包里面加以封裝，并通過網絡發送出去。代理服務器收到經過封裝的數據包后，拆開數據包，在本地處理原始數據包。出站數據包使用服務器直接返回 (Direct Server Return)模式，那樣發送到客戶端的數據包就直接發送到客戶端、繞過引導器這一層。

這兩位工程師說：“我們著手設計一種新的引導器層，它具有無狀態性，讓引導器和代理節點都可以從容地退出輪轉，在任何可能的情況下，對用戶沒有 干擾。一些用戶生活在互聯網連接不盡如人意的國家，所以合理大小的代碼庫的長時間運行副本不會在合理時間的計劃維護期間出現故障，對我們來說很重要。”