github 負載均衡系統最初是為了處理 git 的數十億日常連線而開發的。github 將發布開源版的 github 負載均衡軟體(glb)，這是內部開發的負載均衡系統。
開發 glb 的初衷是滿足 github 的這一要求：每天處理數十億的 http 連線、git 連線和 ssh 連線。而如今，這家公司將通過開源來發布 glb 的元件，到時會透露設計方面的細節。
github 的高階基礎設施工程師喬·威廉斯(joe williams)和 github 的基礎設施工程經理西奧·朱利恩(theo julienne)在一篇共同撰寫的公告中說：「在過去，我們的負載均衡層一向是比較複雜的元件之一。傳統上，我們縱向擴充套件這個部分，執行一小批執行 haproxy 的超大型機器，並使用非常特定的硬體配置，以便實現專門的 10g 鏈路故障切換機制。」
但是這個負載均衡平台遇到瓶頸後，該公司開始著手開發自己的解決方案。這個新平台要滿足某些目標，包括橫向擴充套件、高可用性、支援連線清空 (connection draining)，並且能應對分布式拒絕服務(ddos)攻擊。「為了實現這些目標，我們需要重新考慮 ip 位址與主機之間的關係、我們的負載均衡層包括的各個層，以及連線是如何路由、控制和終結的。
github 在設計負載均衡平台時，為流量引導器(traffic director)這層竭力改進常見模式。該公司最後選用了一種支援多個查詢的聚集雜湊(rendezvous hashing)。每個**主機儲存起來，並被分配乙個狀態，然後處理連線清空。固定大小的**表生成後，使用聚集雜湊的排序元件，每一行都填滿了**服 務器的位址。表和**主機狀態被傳送到引導器伺服器，並保持同步。
tcp 資料報一發送到引導器，源端 ip 就經過雜湊處理，生成指向**表的一致性索引。資料報在注定傳送到**伺服器內部 ip 的另乙個 ip 資料報裡面加以封裝，並通過網路傳送出去。**伺服器收到經過封裝的資料報後，拆開資料報，在本地處理原始資料報。出站資料報使用伺服器直接返回 (direct server return)模式，那樣傳送到客戶端的資料報就直接傳送到客戶端、繞過引導器這一層。
這兩位工程師說：「我們著手設計一種新的引導器層，它具有無狀態性，讓引導器和**節點都可以從容地退出輪轉，在任何可能的情況下，對使用者沒有 干擾。一些使用者生活在網際網路連線不盡如人意的國家，所以合理大小的**庫的長時間執行副本不會在合理時間的計畫維護期間出現故障，對我們來說很重要。」
GitHub將開源內部負載均衡軟體
github 負載均衡系統最初是為了處理 git 的數十億日常連線而開發的。github 將發布開源版的 github 負載均衡軟體 glb 這是內部開發的負載均衡系統。開發 glb 的初衷是滿足 github 的這一要求 每天處理數十億的 http 連線 git 連線和 ssh 連線。而如今，這家...
建立Windows Azure內部負載均衡器
與普通的負載均衡器一樣，windows azure內部負載均衡器也是四層的。內部負載均衡器會被分配乙個內網位址，只能從虛擬網路內部訪問，包括vpn和expressroute。內部負載均衡器通常被用於實現應用層和資料庫層的負載均衡和高可用方案。當然，對於資料庫層的負載均衡和高可用來說，多個資料庫例項之...
《開源運營技術精髓》之負載均衡
6.1 lvs 核心ipvs 6.1.1 安裝ipvs 6.1.2 lvs客戶端 6.1.3 lvs客戶端驗證 6.2 故障隔離 失敗切換框架keepalived 6.2.1 keepalived 體系結構 6.2.2 安裝keepalived 6.2.3 keepalived 安裝驗證 6.2.4...