【摘要】隨著京東業務的高速增長，作為應用入口的負載均衡，大流量大併發帶來的挑戰越來越嚴峻。本文主要介紹了京東商城設計和實踐的一套高可靠，高性能的負載均衡器，我們命名為ContainerLB。是一個使用intel DPDK報文轉發庫，實現運行在通用X86服務器上自研的分佈式負載均衡服務。配合網絡路由器的多重等價路由協議（OSPF）或者邊際網關協議（BGP），組成承擔京東數據中心核心四層負載均衡的集群。最大限度的發揮普通X86服務器硬件資源的性能，實現一套適合於京東商城業務的低成本，分佈式，高性能，可擴展的智能負載均衡系統。
介紹
京東商城目前是國內最大的電商企業。京東的機房內部的流量爆炸式快速的增長。早在2016年初京東商城已經將所有的業務系統全部遷移到容器平臺JDOS，線上20萬+容器實例承載著數千個業務應用。大流量的負載均衡的分配顯得至關重要，也是京東商城新一代軟件定義數據中心的關鍵基礎服務設施之一。
負載均衡器一般介於網絡上的路由器與後端服務器之間，負責將每個數據包通過一定的服務匹配，將其轉發到後端服務器節點。充分考慮到京東商城數據中心全容器及全三層BGP組網的模型。以及基於DPDK的幾乎達到網卡限速的性能，我們在設計負載均衡時，僅考慮實現了FULLNAT模式，即出向和入向的流量均通過負載均衡器，基本數據流程圖如下圖1所示：
圖 1 負載均衡流程圖
一般根據業務及流量的規模的不同階段來選擇使用不同的負載均衡，通常我們在負載均衡的選擇上大致有以下兩個方向：1）硬件負載均衡，如F5、Citrix NetScaler等；2）軟件負載均衡，如基於LVS、HAProxy、Nginx等開源軟件來實現的負載均衡。對於上述兩種負載均衡的選擇，各有優缺點，如下：
硬件負載均衡
可擴展性受限，無法跟上業務流量增長的需求。以及如618、雙十一大促等瞬間流量高峰。
雖然可以成對部署避免單點故障，但是一般只能提供1+1冗餘。
缺乏互聯網快速迭代的靈活性，升級成本昂貴。
一般只能根據網絡的情況來設定負載均衡，無關乎實際系統和硬件的情況。
成本較高。
基於開源軟件的負載均衡
可以根據實際系統和應用的狀態來合理的負載，迭代、擴容和部署相對方便。
單臺負載均衡性能相對較差，需要用集群來支撐負載均衡的整體性能。
性價比較低。
我們的目標：
設計實現一套高可靠、高性能、易維護及性價比高的L4負載均衡系統。
基於通用X86_64服務器框架，以及支持DPDK網卡硬件，易開發和移植。
方便部署、刪除和維護，集成到京東軟件定義數據中心（JDOS2.0）系統，作為京東下一代軟件定義數據中心的基礎組件。
負載均衡下的服務器基於系統應用負載流量均攤，負載均衡器提供N+1 冗餘，藉助OSPF/BGP控制負載均衡器的流量負載。
基於系統應用級別的探活，自動故障檢測及流量快速恢復。
本文主要介紹了ContainerLB一種基於DPDK平臺實現的快速可靠的軟件網絡負載均衡系統。不僅可以快速的橫向擴展，還可以最大限度的提升負載均衡單個NIC的處理轉發速度，來實現L4的負載均衡。藉助DPDK的優勢，如便利的多核編程框架、巨頁內存管理、無鎖隊列、無中斷poll-mode 網卡驅動、CPU親和性等等來實現快速的網卡收發及處理報文，後續考慮TCP/IP 用戶態協議實現和優化，進而實現L7負載均衡。
系統概覽
工作場景
ContainerLB部署在京東容器集群JDOS的前端，對於一個應用集群，發佈一個或多個VIP到ContainerLB服務上，當客戶端需要訪問應用節資源URL，首先通過域名訪問JD智能分佈式DNS服務（SKYDNS詳見https://github.com/ipdcode/skydns）, SkyDns會智能返回當前最近且狀態正常且負載正常的VIP服務的IP，客戶端就會向VIP去請求連接。
ContainerLB節點上運行了一個路由發佈服務agent，我們使用該agent與開啟OSPF/BGP的路由器做路由交互，當ContainerLB的上層路由器接收到請求VIP的數據包時，路由器通過（OSPF/BGP）的等價多路徑轉發協議選擇一個可以使用的發佈該VIP的ContainerLB節點，將報文轉發給一個ContainerLB節點。通過這種策略來實現VIP的發佈和橫向容量負載能力擴展。
當報文通過上述步驟到達ContainerLB負載均衡後，通過常用的負載均衡策略（round robin，一致性hash，最小連接數），將數據包送到相應的後端容器服務。
系統架構
Jingdong Datacenter Operating System（JDOS）是基於JDOS提供物理機/虛擬機/容器的統一管理系統、配備靈活的網絡互連、可靠的分佈式共享存儲，實現軟件定義數據中心的計算資源統一管理和集群管理。通過使用JDOS，可以直接迅速得到任意需要的計算、存儲、網絡、安全等方面的資源和能力。ContainerLB作為整個JDOS系統的一個重要組成部分，負責提供集群的L4負載均衡能力，通過RESTful API等接口與JDOS系統交互。用戶可以通過統一調度管理平臺便捷的創建、刪除、遷移負載均衡系統。同時多個應用服務進行流量分發的負載均衡服務，從而擴展應用系統對外的服務能力，並且通過消除單點故障提高應用系統的可用性。
系統的基本架構如下圖2所示，每一個集群配備一組可容災的負載均衡控制中心，主要通過RESTful API接口負責與JDOS調度中心交互，接收VIP的配置請求。同時我們在每一個ContainerLB的節點上運行一個代理進程，該代理進程通過gRPC與控制中心連接。接收控制中心下達的創建及刪除VIP，後端server endpoint服務等一系列指令，通過load balancer提供的命令行執行相應的指令。接收load balancer關於流量及報文的監控信息，對於流量及監控進行告警，並且通知控制中心和調度中心進行擴容等操作。
代理進程同時還負責後端服務server endpoint基於服務可用性的健康檢查，及時根據後端服務的狀態通過命令行進行添加和刪除的操作。
圖 2 系統架構圖
優勢
擴展性，支持動態添加和刪除後端服務的容器，實現無縫的伸縮；在伸，縮過程中，對相關調用和訪問者無影響。
高可用性，提供多活負載均衡，有多個VIP，它們對應一個域名，自研DNS服務SKYDNS會根據請求的客戶端IP智能解析可用的VIP，返回給用戶，從而實現更高的可用性；即使一個VIP不可用，也不會影響業務系統對外提供服務。同時藉助OSPF/BGP等協議實現負載均衡的橫向擴充。
服務能力自動可調，ContainerLB根據VIP實際接收流量的負載需要調整負載均衡的服務能力，比如流量、連接數的控制等指標。
功能特點
協議支持，負載均衡支持包含TCP、UDP協議的四層負載均衡，配備健全的鏈路跟蹤機制，以及多種調度策略，用戶可以根據服務的需要創建合適自己的負載均衡。
高可用性，支持容器的健康檢查，除傳統的IP+Port，並加入對URL檢查，保證應用可用性： 健康檢查頻率可自定義；一旦探測到異常，則不會將流量再分配到這些異常實例，保證應用可用性。
集群部署，多層次容錯機制： 負載均衡採用集群部署，支持熱升級，機器故障和集群維護對用戶完全透明，結合DNS使用還可支持全局負載均衡。
靈活性，支持多種流量調度算法，使得流量分配更均勻： 負載均衡支持加權輪詢和最小連接數這兩種調度算法，可根據自身需求選擇相應的算法來分配用戶訪問流量，並支持設置後端容器權重，使得流量調度更均勻，提升負載均衡能力。
支持會話保持，滿足用戶個性化需求： 負載均衡通過IP地址實現會話保持，可將一定時間內來自同一用戶的訪問請求，轉發到同一個後端容器上進行處理，從而實現用戶訪問的連續性。
易用性，提供多種管理途徑，輕鬆操縱負載均衡： 用戶可通過控制檯輕鬆實現負載均衡器的配置、釋放等功能。後續會開放標準的API或SDK提供給用戶，從而自己開發對負載均衡的控制管理。
系統設計及技術實現
負載均衡模式選擇
常用的負載均衡模式有DR、NAT、TUNNEL、FULLNAT。每種模式都有自己的優勢和使用場景，業內對每種模式的分析比較文檔很多，不再介紹。由於JDOS容器網絡需要VLAN隔離，而FULLNAT剛好支持LB和RS跨VLAN通信，結合我們自身容器集群的需求，我們在實現ContainerLB時主要考慮支持FULLNAT模式。圖3是ContainerLB的FULLNAT負載均衡模式中數據包的流向圖。ContainerLB位於客戶端和後端服務之間，對於客戶端的請求報文，將目的地址替換成後端服務的地址，源地址替換成ContainerLB的本地地址，對於後端服務的響應報文，將目的地址替換成客戶端地址，源地址替換成ContainerLB的VIP地址。
圖 3 FULLNAT模式下CONTAINERLB的數據包流向圖
藉助DPDK實現高速轉發
Data Plane Development Kit（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是ContainerLB基於RTC數據包處理模型實現的架構。ContainerLB選擇一個核作為控制核，執行命令配置，與內核交換，ARP表維護等任務。其他的核作為工作核，每個工作核輪詢網卡的一個RX隊列，執行數據包處理任務。ContainerLB利用網卡的RSS功能實現客戶端請求報文的分流，利用網卡FDIR功能實現後端服務響應報文的分流。ContainerLB對報文分流目的是要保證客戶端的請求報文和其對應的服務端響應報文到達同一個工作核上。在這個目的達成的前提下，ContainerLB的業務實現會簡單和高效很多。每個工作核維護一張session表，同於保存客戶端和後端服務的連接信息。ContainerLB不需要考慮對session表加鎖，因為每個工作核的session表都是獨立的。
圖 5 ContainerLB的RTC包處理模型框架圖
我們設計ContainerLB每個工作核獨佔至少一個LIP，並將LIP信息寫入網卡配置。圖6是網卡對IP報文分流的流程圖。圖中dst_ip即ContainerLB為每個工作核分配的LIP。網卡對後端服務響應報文的目的地址LIP匹配成功，將報文送到綁定的RX隊列，沒有匹配的報文則可以認為是客戶端的請求報文，按RSS流程分配RX隊列。
圖 6 網卡對IP報文分流過程圖
ContainerLB在啟動過程中還會為每個物理口創建一個KNI接口，控制核負責輪詢KNI接口。該接口主要用於外部程序quagga向路由器發佈VIP信息，Agent檢查後端服務健康狀態。
ContainerLB目前支持的負載均衡調度算法有一致性hash，round robin和最小連接數算法。
Session五元組，ContainerLB採用五元組來實現會話的管理功能，如下圖7所示：
圖 7 ContainerLB 五元組管理Session
負載均衡冗餘設計
ContainerLB使用BGP或者OSPF的模式組成集群，通過上述協議將數據包散列到集群中各個節點上，保證單臺ContainerLB故障或者恢復後能動態的將機器添加及刪除。其冗餘實現設計如下圖8所示：
圖 8 ContainerLB的冗餘設計
性能優化實踐
良好的流程設計是性能提升的關鍵，這方面的流程涉及和業務相關，缺乏共性，因此不做詳細闡述。主要介紹ContainerLB性能優化過程中使用的其他優化方法。
恰當地使用rte_prefetch0()，可以減少cache-miss次數，避免當前函數成為性能熱點。性能調優工具perf可以幫助我們分析應該在哪處代碼使用預取。例如我們使用perf發現報文處理函數中有一個處代碼是性能熱點，該代碼用於讀取新報文的類型字段並判斷，分析認為很可能是cache-misses造成的。在進入報文處理函數前使用rte_prefetch0()，有效避免該函數成為熱點。
恰當地使用likely()和unlikely()，可以減少分支預測失敗的次數。我們在ContainerLB代碼的一處分支語句中使用unlikely()優化，性能提升明顯。分支預測優化點可以藉助perf分析確定，也可以根據自己對代碼執行流程的理解確定。
儘量減少鎖的使用。ContainerLB中配置信息不經常變化，我們沒有單獨為每個可能爭用的資源加鎖，而是隻用一把DPDK提供的讀寫鎖，每個讀線程在加讀鎖後，處理一批報文，然後釋放讀鎖。既簡化流程，又減少了操作讀寫鎖的開銷（DPDK讀寫鎖的開銷並不是很大）。
性能數據
測試環境
CPU：Intel(R) Xeon(R) CPU E5-2640 v3
NIC：intel 82599ES 10-Gigabit SFI/SFP+ Network Connection
測試配置
負載均衡模式：FULLNAT
調度算法：一致性hash
配置：CPU佔用8核 內存佔用4G
性能測試數據
1. UDP發包，測試轉發性能，我們使用了SKYDNS作為後端服務，客戶端採用UDP請求DNS。
表 1 ContainerLB基於UDP的DNS性能測試數據
2. NGINX作為後端服務，壓測HTTP性能。
配置：CPU佔用8核 內存佔用4G
表 2 ContainerLB HTTP性能測試數據
圖 9 ContainerLB http 性能測試指標圖
總結
本文主要介紹了ContainerLB，一種的基於Intel DPDK平臺開發的負載均衡器。其接近網卡線速處理及轉發能力，靈活的部署，多樣的監控以及可靠的穩定性。基本上覆蓋所有4層負載均衡的業務處理需求，配合集群管理以及調度，作為京東數據中心操作系統（JDOS）的一個重要的組成部分，在京東數據中心發揮至關重要的作用。