GitHub將開源內(nèi)部負載均衡軟件
GitHub 負載均衡系統(tǒng)最初是為了處理 Git 的數(shù)十億日常連接而開發(fā)的。GitHub 將發(fā)布開源版的 GitHub 負載均衡軟件(GLB)，這是內(nèi)部開發(fā)的負載均衡系統(tǒng)。
開發(fā) GLB 的初衷是滿足 GitHub 的這一要求：每天處理數(shù)十億的 HTTP 連接、Git 連接和 SSH 連接。而如今，這家公司將通過開源來發(fā)布 GLB 的組件，到時會透露設計方面的細節(jié)。
GitHub 的高級基礎設施工程師喬·威廉斯(Joe Williams)和 GitHub 的基礎設施工程經(jīng)理西奧·朱利恩(Theo Julienne)在一篇共同撰寫的公告中說：“在過去，我們的負載均衡層一向是比較復雜的組件之一。傳統(tǒng)上，我們縱向擴展這個部分，運行一小批運行 haproxy 的超大型機器，并使用非常特定的硬件配置，以便實現(xiàn)專門的 10G 鏈路故障切換機制。”
但是這個負載均衡平臺遇到瓶頸后，該公司開始著手開發(fā)自己的解決方案。這個新平臺要滿足某些目標，包括橫向擴展、高可用性、支持連接清空 (connection draining)，并且能應對分布式拒絕服務(DDoS)攻擊。“為了實現(xiàn)這些目標，我們需要重新考慮 IP 地址與主機之間的關系、我們的負載均衡層包括的各個層，以及連接是如何路由、控制和終結(jié)的。
GitHub 在設計負載均衡平臺時，為流量引導器(traffic director)這層竭力改進常見模式。該公司最后選用了一種支持多個查詢的聚集哈希(rendezvous hashing)。每個代理主機存儲起來，并被分配一個狀態(tài)，然后處理連接清空。固定大小的轉(zhuǎn)發(fā)表生成后，使用聚集哈希的排序組件，每一行都填滿了代理服 務器的地址。表和代理主機狀態(tài)被發(fā)送到引導器服務器，并保持同步。
TCP 數(shù)據(jù)包一發(fā)送到引導器，源端 IP 就經(jīng)過哈希處理，生成指向轉(zhuǎn)發(fā)表的一致性索引。數(shù)據(jù)包在注定發(fā)送到代理服務器內(nèi)部 IP 的另一個 IP 數(shù)據(jù)包里面加以封裝，并通過網(wǎng)絡發(fā)送出去。代理服務器收到經(jīng)過封裝的數(shù)據(jù)包后，拆開數(shù)據(jù)包，在本地處理原始數(shù)據(jù)包。出站數(shù)據(jù)包使用服務器直接返回 (Direct Server Return)模式，那樣發(fā)送到客戶端的數(shù)據(jù)包就直接發(fā)送到客戶端、繞過引導器這一層。
這兩位工程師說：“我們著手設計一種新的引導器層，它具有無狀態(tài)性，讓引導器和代理節(jié)點都可以從容地退出輪轉(zhuǎn)，在任何可能的情況下，對用戶沒有 干擾。一些用戶生活在互聯(lián)網(wǎng)連接不盡如人意的國家，所以合理大小的代碼庫的長時間運行副本不會在合理時間的計劃維護期間出現(xiàn)故障，對我們來說很重要。”
