在過去的一年中，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談到他們計畫如何平滑地發布這個新負載均衡系統，並預計在近期開源該專案。
Nginx負載均衡 upstream 引數設定
nginx的upstream目前支援的5種方式的分配 1 輪詢 預設 每個請求按時間順序逐一分配到不同的後端伺服器，如果後端伺服器down掉，能自動剔除。upstream backserver 2 指定權重 指定輪詢機率，weight和訪問比率成正比，用於後端伺服器效能不均的情況。upstream ...
GitHub將開源內部負載均衡軟體
github 負載均衡系統最初是為了處理 git 的數十億日常連線而開發的。github 將發布開源版的 github 負載均衡軟體 glb 這是內部開發的負載均衡系統。開發 glb 的初衷是滿足 github 的這一要求 每天處理數十億的 http 連線 git 連線和 ssh 連線。而如今，這家...
GitHub將開源內部負載均衡軟體
github 負載均衡系統最初是為了處理 git 的數十億日常連線而開發的。github 將發布開源版的 github 負載均衡軟體 glb 這是內部開發的負載均衡系統。開發 glb 的初衷是滿足 github 的這一要求 每天處理數十億的 http 連線 git 連線和 ssh 連線。而如今，這家...