一個支持高網絡吞吐量、基於機器性能評分的TCP負載均衡器gobalan

一個支持高網絡吞吐量、基於機器性能評分的TCP負載均衡器gobalan

做者最近用golang實現了一個TCP負載均衡器，靈感來自grpc。幾個主要的特性就是：

• 支持高網絡吞吐量
• 實現了基於機器性能評分來分配worker節點的負載均衡算法
• 儘可能作到薄客戶端，下降客戶端複雜性

項目開源地址

背景

先介紹幾種經常使用的負載均衡機制，如下幾種負載均衡方案介紹來自grpc服務發現&負載均衡

根據負載均衡實現所在的位置不一樣，一般可分爲如下四種解決方案：

集中式LB(Proxy Model)

在服務消費者和服務提供者之間有一個獨立的LB，一般是專門的硬件設備如 F5，或者基於軟件如 LVS，HAproxy等實現。LB上有全部服務的地址映射表，一般由運維配置註冊，當服務消費方調用某個目標服務時，它向LB發起請求，由LB以某種策略，好比輪詢（Round-Robin）作負載均衡後將請求轉發到目標服務。LB通常具有健康檢查能力，能自動摘除不健康的服務實例。 該方案主要問題：

單點問題，全部服務調用流量都通過LB，當服務數量和調用量大的時候，LB容易成爲瓶頸，且一旦LB發生故障影響整個系統；
服務消費方、提供方之間增長了一級，有必定性能開銷。

進程內LB(Balancing-aware Client)

針對第一個方案的不足，此方案將LB的功能集成到服務消費方進程裏，也被稱爲軟負載或者客戶端負載方案。服務提供方啓動時，首先將服務地址註冊到服務註冊表，同時按期報心跳到服務註冊表以代表服務的存活狀態，至關於健康檢查，服務消費方要訪問某個服務時，它經過內置的LB組件向服務註冊表查詢，同時緩存並按期刷新目標服務地址列表，而後以某種負載均衡策略選擇一個目標服務地址，最後向目標服務發起請求。LB和服務發現能力被分散到每個服務消費者的進程內部，同時服務消費方和服務提供方之間是直接調用，沒有額外開銷，性能比較好。該方案主要問題：

開發成本，該方案將服務調用方集成到客戶端的進程裏頭，若是有多種不一樣的語言棧，就要配合開發多種不一樣的客戶端，有必定的研發和維護成本；
另外生產環境中，後續若是要對客戶庫進行升級，勢必要求服務調用方修改代碼並從新發布，升級較複雜。

獨立進程LB(External LB service)

該方案是針對第二種方案的不足而提出的一種折中方案，原理和第二種方案基本相似。
不一樣之處是將LB和服務發現功能從進程內移出來，變成主機上的一個獨立進程。主機上的一個或者多個服務要訪問目標服務時，他們都經過同一主機上的獨立LB進程作服務發現和負載均衡。該方案也是一種分佈式方案沒有單點問題，一個LB進程掛了隻影響該主機上的服務調用方，服務調用方和LB之間是進程內調用性能好，同時該方案還簡化了服務調用方，不須要爲不一樣語言開發客戶庫，LB的升級不須要服務調用方改代碼。
該方案主要問題：部署較複雜，環節多，出錯調試排查問題不方便。

gRPC服務發現及負載均衡設計

gRPC開源組件官方並未直接提供服務註冊與發現的功能實現，但其設計文檔已提供實現的思路，並在不一樣語言的gRPC代碼API中已提供了命名解析和負載均衡接口供擴展。

其基本實現原理：

服務啓動後gRPC客戶端向命名服務器發出名稱解析請求，名稱將解析爲一個或多個IP地址，每一個IP地址標示它是服務器地址仍是負載均衡器地址，以及標示要使用那個客戶端負載均衡策略或服務配置。
客戶端實例化負載均衡策略，若是解析返回的地址是負載均衡器地址，則客戶端將使用grpclb策略，不然客戶端使用服務配置請求的負載均衡策略。
負載均衡策略爲每一個服務器地址建立一個子通道（channel）。
當有rpc請求時，負載均衡策略決定那個子通道即grpc服務器將接收請求，當可用服務器爲空時客戶端的請求將被阻塞。

優缺點分析

能夠看到第一種負載均衡是在server端進行負載均衡(也叫Proxy負載均衡)，第二種和第三種負載均衡方案都是在客戶端進行的負載均衡，這兩類負載均衡各有優缺點

Proxy負載均衡優缺點

優勢

• 隱藏後端服務器。
  反向代理可以隱藏後端服務器，全部瀏覽器都不會與後端服務器直接交互，從而可以確保調度者的控制權，提高集羣的總體性能。
• 故障轉移
  反向代理可以更快速地移除故障結點。當監控程序發現某一後端服務器出現故障時，可以及時通知反向代理服務器，並當即將其刪除。
• 合理分配任務
  但反向代理服務器支持手動設定每臺後端服務器的權重。咱們能夠根據服務器的配置設置不一樣的權重，權重的不一樣會致使被調度者選中的機率的不一樣。

缺點

• 調度者壓力過大
  因爲全部的請求都先由反向代理服務器處理，那麼當請求量超過調度服務器的最大負載時，調度服務器的吞吐率下降會直接下降集羣的總體性能。
• 制約擴展
  當後端服務器也沒法知足巨大的吞吐量時，就須要增長後端服務器的數量，可沒辦法無限量地增長，由於會受到調度服務器的最大吞吐量的制約。

客戶端負載均衡優缺點

優勢

• 客戶端和提供服務的服務器進行直連，沒有了Proxy負載均衡器的瓶頸，而且容易擴展。

缺點

• 客戶端邏輯會變得複雜，它須要追蹤服務端的機器負載和健康度，須要實現負載均衡算法。第二種負載均衡機制還依賴客戶端的實現語言，須要爲不一樣語言實現不一樣的負載均衡版本。
• 客戶端必須是受信任的，由於客戶端可以拿到全部負載均衡節點的信息。

grpc負載均衡優缺點

優勢

grpc負載均衡是上述兩種負載均衡機制的結合體，經過添加一個額外的load balancer server來實現，它基本上避免了兩種負載均衡機制的缺點。

• 負載均衡節點健康度檢查和機器負載經過這個load balancer server來實現,而且複雜的負載均衡算法都由其來實現，避免了客戶端過於複雜的缺點，客戶端只是實現一些簡單的負載均衡算法。
• 服務網絡鏈接依然採用直連，繞過load balancer，解決了網絡吞吐量的問題。

缺點

• 客戶端仍然是須要受信任的

gobalan

爲何要實現一個負載均衡器，由於目前爲止沒有找到知足做者要求的負載均衡器。市面上負載均衡器大可能是proxy負載均衡器，像LVS，Haproxy,上行流量會成爲它們的瓶頸。grpc的負載均衡只是作了設計，並無實現，而且grpc負載均衡設計的初衷是per-call的，設計的目標應該是針對微服務中的API調用，而且感受grpc負載均衡設計還有改進的空間。

gobalan有一下特色：

• gobalan是per-connection的，也就是一次TCP鏈接請求作一次負載均衡。
• gobalan全部負載均衡邏輯均在負載均衡器中實現，包括服務健康檢查，機器負載信息收集，負載均衡算法的實現。
• 客戶端只須要實現服務節點的請求和返回值解析兩個邏輯就能使用gobalan，咱們須要的是超薄客戶端。
• 客戶端和服務節點採用直連，避免了proxy負載均衡的網絡帶寬瓶頸。

整個系統的交互流程是下面這個樣子：

關於gobalan的更加詳細的設計原理和使用方法，參考項目地址

參考

高併發解決方案--負載均衡

grpc服務發現&負載均衡

gRPC Load Balancing