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

lj3052 8年前發布 | 29K 次閱讀 負載均衡 集群/負載均衡 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節點。

 

 

來自：http://www.infoq.com/cn/news/2016/10/github-load-balancer-design

 

 本文由用戶 lj3052 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
 轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！