摘要

隨著京東業務的高速增長，作為應用入口的負載均衡，大流量大併發帶來的挑戰越來越嚴峻。本文主要介紹了京東商城設計和實踐的一套高可靠，高效能的負載均衡器，我們命名為SKYLB。是一個使用intel DPDK報文轉發庫，實現執行在通用X86伺服器上自研的分散式負載均衡服務。配合網路路由器的OSPF或者BGP協議，組成承擔京東資料中心核心四層負載均衡的叢集。最大限度的發揮普通X86伺服器硬體資源的效能，實現一套適合於京東商城業務的低成本，分散式，高效能，可擴充套件的智慧負載均衡系統。

介紹

京東商城目前是國內最大的電商企業。京東的機房內部的流量爆炸式快速的增長。早在2016年初京東商城已經將所有的業務系統全部遷移到容器平臺JDOS，線上百萬+容器例項穩定執行。大流量的負載均衡的分配顯得至關重要，也是京東商城新一代軟體定義資料中心的關鍵基礎服務設施之一。

負載均衡器一般介於網路上的路由器與後端伺服器之間，負責將每個資料包通過一定的服務匹配，將其轉發到後端伺服器節點。充分考慮到京東商城資料中心全容器及全三層BGP組網的模型。以及基於DPDK的幾乎達到網絡卡限速的效能，我們在設計負載均衡時，僅考慮實現了FULLNAT模式，即出向和入向的流量均通過負載均衡器，基本資料流程圖如下圖1所示：

圖1 負載均衡流程圖

一般根據業務及流量的規模的不同階段來選擇使用不同的負載均衡，通常我們在負載均衡的選擇上大致有以下兩個方向：1)硬體負載均衡，如F5。CitrixNetscaler等；2)軟體負載均衡，如基於LVS，Haproxy，Nginx等開源軟體來實現的負載均衡。對於上述兩種負載均衡的選擇，各有優缺點，如下：

1） 硬體負載均衡

可擴充套件性受限，無法跟上業務流量增長的需求。以及如618、雙十一大促等瞬間流量高峰。

雖然可以成對部署避免單點故障，但是一般只能提供1+1冗餘。

缺乏網際網路快速迭代的靈活性，升級成本昂貴。

一般只能根據網路的情況來設定負載均衡，無關乎實際系統和硬體的情況。

成本較高。

2） 基於開源軟體的負載均衡

可以根據實際系統和應用的狀態來合理的負載，迭代、擴容和部署相對方便。

單臺負載均衡效能相對較差，需要用叢集來支撐負載均衡的整體效能。

價效比較低。

我們的目標：

1. 設計實現一套高可靠、高效能、易維護及價效比高的L4負載均衡系統,。
2. 基於通用X86_64伺服器框架，以及支援DPDK網絡卡硬體，易開發和移植。
3. 方便部署、刪除和維護，整合到京東軟體定義資料中心（JDOS2.0）系統，作為京東下一代軟體定義資料中心的基礎元件。
4. 負載均衡下的伺服器基於系統應用負載流量均攤，負載均衡器提供N+1 冗餘，藉助OSPF/BGP控制負載均衡器的流量負載。
5. 基於系統應用級別的探活，自動故障檢測及流量快速恢復。

本文主要介紹了SKYLB一種基於DPDK平臺實現的快速可靠的軟體網路負載均衡系統。不僅可以快速的橫向擴充套件，還可以最大限度的提升負載均衡單個NIC的處理轉發速度，來實現L4的負載均衡。藉助DPDK的優勢，如便利的多核程式設計框架、巨頁記憶體管理、無鎖佇列、無中斷poll-mode 網絡卡驅動、CPU親和性等等來實現快速的網絡卡收發及處理報文，後續考慮TCP/IP 使用者態協議實現和優化，進而實現L7負載均衡。

系統概覽

工作場景

SKYLB部署在京東容器叢集JDOS的前端，對於一個應用叢集，釋出一個或多個VIP到SKYLB服務上，當客戶端需要訪問應用節資源URL，首先通過域名訪問JD智慧分散式DNS服務（SKYDNS詳見https://github.com/ipdcode/skydns）, SkyDns會智慧返回當前最近且狀態正常且負載正常的VIP服務的IP,客戶端就會向VIP去請求連線。

SKYLB節點上運行了一個路由釋出服務agent，我們使用該agent與開啟OSPF/BGP的路由器做路由互動，當SKYLB的上層路由器接收到請求VIP的資料包時，路由器通過（OSPF/BGP）的等價多路徑轉發協議選擇一個可以使用的釋出該VIP的SKYLB節點，將報文轉發給一個SKYLB節點。通過這種策略來實現VIP的釋出和橫向容量負載能力擴充套件。

當報文通過上述步驟到達SKYLB負載均衡後，通過常用的負載均衡策略(round robin，一致性hash ，最小連線數)，將資料包送到相應的後端容器服務。

系統架構

JingdongDatacenter Operating System(JDOS) 是基於JDOS提供物理機/虛擬機器/容器的統一管理系統、配備靈活的網路互連、可靠的分散式共享儲存，實現軟體定義資料中心的計算資源統一管理和叢集管理。通過使用JDOS，可以直接迅速得到任意需要的計算、儲存、網路、安全等方面的資源和能力。SKYLB作為整個JDOS系統的一個重要組成部分，負責提供叢集的L4負載均衡能力，通過restful API等介面與JDOS系統互動。使用者可以通過統一排程管理平臺便捷的建立、刪除、遷移負載均衡系統。同時多個應用服務進行流量分發的負載均衡服務，從而擴充套件應用系統對外的服務能力，並且通過消除單點故障提高應用系統的可用性。

系統的基本架構如下圖2所示，每一個叢集配備一組可容災的負載均衡控制中心,主要通過restful api介面負責與JDOS排程中心互動，接收vip的配置請求。同時我們在每一個SKYLB的節點上執行一個代理程序，該代理程序通過gRPC與控制中心連線。接收控制中心下達的建立及刪除vip,後端server endpoint服務等一系列指令，通過load balancer 提供的命令列執行相應的指令。接收load balancer 關於流量及報文的監控資訊，對於流量及監控進行告警，並且通知控制中心和排程中心進行擴容等操作。

代理程序同時還負責後端服務 server endpoint基於服務可用性的健康檢查，及時根據後端服務的狀態通過命令列進行新增和刪除的操作。

圖2 系統架構圖

優勢

1）擴充套件性

支援動態新增和刪除後端服務的容器，實現無縫的伸縮；在伸，縮過程中，對相關呼叫和訪問者無影響。

2）高可用性

提供多活負載均衡，有多個VIP，它們對應一個域名，自研DNS服務SKYDNS會根據請求的客戶端IP智慧解析可用的VIP，返回給使用者，從而實現更高的可用性；即使一個VIP不可用，也不會影響業務系統對外提供服務。同時藉助OSPF/BGP等協議實現負載均衡的橫向擴充

3）服務能力自動可調

SKYLB根據VIP實際接收流量的負載需要調整負載均衡的服務能力，比如流量、連線數的控制等指標。

功能特點

1）協議支援

負載均衡支援包含TCP、UDP協議的四層負載均衡，配備健全的鏈路跟蹤機制，以及多種排程策略，使用者可以根據服務的需要建立合適自己的負載均衡。

2）高可用性

支援容器的健康檢查，除傳統的IP+Port，並加入對URL檢查，保證應用可用性： 健康檢查頻率可自定義；一旦探測到異常，則不會將流量再分配到這些異常例項，保證應用可用性。

3）叢集部署，多層次容錯機制： 負載均衡採用叢集部署，支援熱升級，機器故障和叢集維護對使用者完全透明，結合DNS使用還可支援全域性負載均衡。

4）靈活性

支援多種流量排程演算法，使得流量分配更均勻： 負載均衡支援加權輪詢和最小連線數這兩種排程演算法，可根據自身需求選擇相應的演算法來分配使用者訪問流量，並支援設定後端容器權重，使得流量排程更均勻，提升負載均衡能力。

支援會話保持，滿足使用者個性化需求： 負載均衡通過IP地址實現會話保持，可將一定時間內來自同一使用者的訪問請求，轉發到同一個後端容器上進行處理，從而實現使用者訪問的連續性。

5）易用性

提供多種管理途徑，輕鬆操縱負載均衡： 使用者可通過控制檯輕鬆實現負載均衡器的配置、釋放等功能。後續會開放標準的API或SDK提供給使用者，從而自己開發對負載均衡的控制管理。

系統設計及技術實現

負載均衡模式選擇

常用的負載均衡模式有DR，NAT，TUNNEL，FULLNAT。每種模式都有自己的優勢和使用場景，業內對每種模式的分析比較文件很多，不再介紹。由於JDOS容器網路需要VLAN隔離，而FULLNAT剛好支援LB和RS跨VLAN通訊，結合我們自身容器叢集的需求，我們在實現SKYLB時主要考慮支援FULLNAT模式。圖3是SKYLB的FULLNAT負載均衡模式中資料包的流向圖。SKYLB位於客戶端和後端服務之間，對於客戶端的請求報文，將目的地址替換成後端服務的地址，源地址替換成SKYLB的本地地址，對於後端服務的響應報文，將目的地址替換成客戶端地址，源地址替換成SKYLB的VIP地址。

圖3 FULLNAT模式下SKYLB的資料包流向圖

藉助DPDK實現高速轉發

Data Plane DevelopmentKit（DPDK）：是執行在Linux 使用者態，實現X86通用平臺網路報文快速處理的庫和驅動的集合，如下圖4所示，其主要特點：

•  多核程式設計框架及CPU親和性

每個NUMA節點有單獨的CPU和本地記憶體

CPU訪問本地記憶體速度比訪問遠端記憶體快，避免CPU訪問遠端記憶體

注意網絡卡掛載的NUMA節點巨頁記憶體管理

•  巨頁(HugePage)

普通記憶體頁面大小4KB，巨頁記憶體頁面大小2MB/1GB

減少頁表項數目，降低TLB miss

使用大頁面比使用4K的頁面效能提高10%~15%

零拷貝，報文資料及轉發記憶體零拷貝。

•  無鎖佇列

使用無鎖佇列，入隊出隊無需阻塞等待鎖資源

•  poll-mode網絡卡驅動

DPDK網絡卡驅動完全拋棄中斷模式，基於輪詢方式收包

圖4 DPDK相關模組

包處理架構實現

圖5是SKYLB基於RTC資料包處理模型實現的架構。SKYLB選擇一個核作為控制核，執行命令配置，與核心交換，ARP表維護等任務。其他的核作為工作核，每個工作核輪詢網絡卡的一個RX佇列，執行資料包處理任務。SKYLB利用網絡卡的RSS功能實現客戶端請求報文的分流，利用網絡卡FDIR功能實現後端服務響應報文的分流。SKYLB對報文分流目的是要保證客戶端的請求報文和其對應的服務端響應報文到達同一個工作核上。在這個目的達成的前提下，SKYLB的業務實現會簡單和高效很多。每個工作核維護一張session表，同於儲存客戶端和後端服務的連線資訊。SKYLB不需要考慮對session表加鎖，因為每個工作核的session表都是獨立的。

圖5 SKYLB的RTC包處理模型框架圖

我們設計SKYLB每個工作核獨佔至少一個LIP，並將LIP資訊寫入網絡卡配置。圖6是網絡卡對IP報文分流的流程圖。圖中dst_ip即SKYLB為每個工作核分配的LIP。網絡卡對後端服務響應報文的目的地址LIP匹配成功，將報文送到繫結的RX佇列，沒有匹配的報文則可以認為是客戶端的請求報文，按RSS流程分配RX佇列。

圖6 網絡卡對IP報文分流過程圖

SKYLB在啟動過程中還會為每個物理口建立一個KNI介面，控制核負責輪詢KNI介面。該介面主要用於外部程式quagga向路由器釋出VIP資訊，Agent檢查後端服務健康狀態。

SKYLB目前支援的負載均衡排程演算法有一致性hash，round robin和最小連線數演算法。

Session五元組，SKYLB採用五元組來實現會話的管理功能，如下圖7 所示：

圖7 SKYLB 五元組管理Session

負載均衡冗餘設計

SKYLB使用BGP或者OSPF的模式組成叢集，通過上述協議將資料包雜湊到叢集中各個節點上，保證單臺SKYLB故障或者恢復後能動態的將機器新增及刪除。其冗餘實現設計如下圖6所示：

圖8 SKYLB的冗餘設計

效能優化實踐

良好的流程設計是效能提升的關鍵，這方面的流程涉及和業務相關，缺乏共性，因此不做詳細闡述。主要介紹SKYLB效能優化過程中使用的其他優化方法。

恰當地使用rte_prefetch0()，可以減少cache-miss次數，避免當前函式成為效能熱點。效能調優工具perf可以幫助我們分析應該在哪處程式碼使用預取。例如我們使用perf發現報文處理函式中有一個處程式碼是效能熱點，該程式碼用於讀取新報文的型別欄位並判斷，分析認為很可能是cache-misses造成的。在進入報文處理函式前使用rte_prefetch0()，有效避免該函式成為熱點。

恰當地使用likely()和unlikely()，可以減少分支預測失敗的次數。我們在SKYLB程式碼的一處分支語句中使用unlikely()優化，效能提升明顯。分支預測優化點可以藉助perf分析確定，也可以根據自己對程式碼執行流程的理解確定。

儘量減少鎖的使用。SKYLB中配置資訊不經常變化，我們沒有單獨為每個可能爭用的資源加鎖，而是隻用一把DPDK提供的讀寫鎖，每個讀執行緒在加讀鎖後，處理一批報文，然後釋放讀鎖。既簡化流程，又減少了操作讀寫鎖的開銷(DPDK讀寫鎖的開銷並不是很大)。

效能資料

測試環境：

CPU：Intel(R) Xeon(R) CPU E5-2640 v3

NIC：intel 82599ES 10-GigabitSFI/SFP+ Network Connection

測試配置：

負載均衡模式：FULLNAT

排程演算法：一致性hash

配置：CPU佔用8核 記憶體佔用4G

效能測試資料：

1）UDP發包，測試轉發效能，我們使用了SKYDNS作為後端服務，客戶端採用UDP請求DNS

表1 SKYLB基於UDP的DNS效能測試資料

2）NGINX作為後端服務，壓測HTTP效能。配置：CPU佔用8核 記憶體佔用4G

表2 SKYLB HTTP效能測試資料

圖9 SKYLB HTTP 效能測試指標圖

圖9 SKYLBhttp 效能測試指標圖

總結

本文主要介紹了SKYLB，一種的基於intel DPDK平臺開發的負載均衡器。其接近網絡卡線速處理及轉發能力，靈活的部署，多樣的監控以及可靠的穩定性。基本上覆蓋所有4層負載均衡的業務處理需求，配合叢集管理以及排程，作為京東資料中心作業系統（JDOS）的一個重要的組成部分，在京東資料中心發揮至關重要的作用。