一個支援高網路吞吐量、基於機器效能評分的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 Balanc