原文地址：http://www.infoq.com/cn/articles/jingdong-network-framework-gateway-dlvs
DLVS誕生之初
在SLB這塊，京東用戶接入系統提供四層負載均衡服務和應用層負載均衡服務，對於公網流量接入部分，和很多公司一樣采用的是四層和應用層負載相結合的架構，利用四層負載來實現應用層的水平擴展。四層負載在JFE 1.0版本中使用開源的LVS實現，考慮單機性能的問題，使用了DR模式和集群部署方式，並將LVS和應用層負載按照服務單元進行部署。這種模式在中等規模的業務場景運行良好，隨着業務的不斷增長，單業務QPS超過200萬，以及全站HTTPS改造要求SSL在SLB上完成卸載，應用層負載集群規模將不斷擴大，同時受限機房機架資源等因素，需要實現四，應用層負載解耦。為此我們對四層負載進行了重新的設計和自主研發，加入了在線上服務保障過程中的業務訴求，在性能、可用性、運維管理以及安全防護上提升。
業務增長對性能的需求
在過去的10年，京東的流量峰值從幾十萬到現在的千萬級QPS，給流量分發的四層負載均衡服務帶來了巨大的挑戰。Linux內核實現版本受限於網卡的中斷收包模式以及二三層鎖的開銷，系統經過調優后的轉發能力單台QPS在十萬級別。為了滿足業務流量的陡增，只能是通過增加集群規模和通過多集群的方式進行擴容，隨着集群數量和規模的不斷增加，給服務保障帶來了具大的挑戰，容量管理以及容災方案設計都變得非常的復雜。
服務質量的精細化
由於支撐的業務場景越來越豐富，既有長連接（IM）應用場景又有視頻業務需求，同時業務對服務穩定性的要求越來越高，接入平台作為基礎設施服務，可用性要求越來越高，要求在不同層面保障服務的穩定性，避免單機故障和機房故障對線上服務的影響。
目前常用的集群方案是采用路由來實現，在京東內部我們使用的BGP協議（后面會介紹部署方式），最終要依賴交換機的ECMP來實現，ECMP的缺陷是如果一台服務器宕機，同一條流的數據包可能就會被轉發到集群其它機器上，如果沒有會話同步，那么該連接數據包就會丟棄，最終業務層超時。這對於一些長連接在線的業務影響會更加明顯，比如在線的IM業務以及推送業務等服務。
運維管理的自動化
隨着業務流量的陡增，集群規模越來越大和多集群的出現，同時對於線上大量應用的業務配置變更，對運維也是很大的挑戰。自動化程度，成為衡量公司技術能力的一項重要指標。
對於接入平台，承載了公司眾多的業務，實現快速的業務變更同時做到每次變更對業務無損，從平台角度看這是必須要去解決的問題。
安全防護能力
接入流量作為服務入口，在面對網絡攻擊時，需要具備安全防護的能力，保障平台服務的穩定性，同時做到對業務透明和精准防護，減少對業務的影響。傳統方案通常采用單獨的檢測和清洗集群來實現，從技術層面看完全可以把異常流量清洗功能移到四層負載上，並以集群的方式部署，節省資源的同時減少旁路部署帶來的復雜網絡拓撲。同時四層負載更加接近業務，更方便用戶根據特定業務定制一些安全規則，真正起到分層防護的能力，保證業務的安全穩定。
方案選擇與功能定義
數據包收發方案選擇
對於高性能的數據包處理方案來說，目前主流方案包括了硬件化方案和軟件化方案。
對於硬件化方案，性能上雖然會優於軟件化方案，但它昂貴的價格、有限的容量、靈活性和擴展性都不太適合處於中間轉發位置的四層負載。而且隨着多核服務器的普及，軟件方案也可以達到網卡限速的性能，從價格、容量和靈活性上都遠高於硬件方案，最終我們放棄了硬件方案。
在眾多的軟件化方案中，pfring依然輪詢RX Queue，而不能同時訪問所有的RX Queue。導致單核占用率比較高，不能充分利用多核性能。pfring和netmap對於大葉內存和numa等也沒有庫來支持，在實際的應用中(多路處理器和網卡)，必然會影響性能。
綜合來看，dpdk能充分發揮多核處理的的優勢，來提供更好的轉發性能外。同時dpdk提供了便於快速開發的庫（內存池、網卡信息獲取、無鎖隊列、hash等）。最重要的是dpdk由Intel發起並支撐，加之社區活躍程度高，我們最終選擇了dpdk作為數據包收發方案。
功能定義
- 支持集群部署
- 支持配置集中管理
- 支持會話保持
- 支持tcp、udp的四層負載均衡
- 支持DR和FULLNAT模式
- 支持rr、wrr、源ip hash等負載均衡算法
- 支持主動健康檢查
- 支持透傳客戶機IP
- 支持會話同步
- 支持syn flood, ack flood等四層攻擊防護
- 支持畸形報文過濾、黑白名單
系統實現
DLVS核心架構
結合各個功能的實現方式，下圖是四層負載的DLVS的核心架構（后續章節會展開講解）。
DLVS包括數據平面和控制平面，控制平面主要負責配置、監控和日志的管理。數據平面主要是基於dpdk實現的數據包處理和轉發。控制平面和數據平面的通信主要通過kni接口和unix 域套接字接口。
控制平面的quagga用於和交換機建立BGP連接，發布路由和DLVS保活監控；keepalived用於vip、real server等業務的配置和real server的健康檢查；管理agent用於提供對外配置接口和日志上報接口。
數據平面雖然是單進程，但我們在內部采用了多線程機制，並將管理和業務流量分離，以避免大的業務流量對管理流量產生影響。即把線程分為管理線程和業務線程，它們之間通過隊列進行通信。管理線程負責處理經過內核的報文、進程間通信的報文等，同時將配置下發給各個業務線程，既每個業務線程都擁有一份配置。業務線程有多個線程，包括負載均衡業務的處理、安全防護和會話管理等。
接下來我們從業務角度、性能角度、高可靠性角度和安全防護角度來說明四層負載DLVS的具體實現。
負載均衡業務的實現
結合京東商城和京東雲的業務需求，對於四層負載我們支持了TCP和UDP兩種協議，支持fullnat和dr兩種模式，並支持了rr、wrr和源ip哈希選擇real server等基本功能，具體的實現我們不再詳細解讀，大家參考kernel版lvs的實現即可，原理方法基本一致。在這里我們只結合真實業務場景中遇到的問題來提醒大家在實現過程中特別需要注意的幾點。
rr算法選取real server
在實際使用過程中，每台DLVS選取real server都是從頭開始輪詢的。在實際應用場景中，我們發現集群新增DLVS時，real server的流量嚴重不平衡，都集中在了配置的比較靠前的幾台real server上。我們通過隨機哈希real server的位置，再進行rr選取，從而解決了這個問題。wrr的選取解決方案類似。
業務配置的加載
開源的lvs是kernel的module，在dpdk上來實現lvs的功能會導致原有的keepalived和ipvsadm無法進行配置和監控的管理。我們利用域套接字實現的接口來替換keepalived和ipvsadm的消息下發接口，從而實現了dpdk版lvs與keepalived和ipvsadm的無縫對接。
業務的接口我們使用統一的庫DLVS wrapper來實現，交互流程如下圖所示：
Client真實IP獲取
由於業務的需要，有些服務需要獲取到client的真實IP和端口號。開源的lvs采用的toa（將真實源IP和端口加在tcp option中的方式），需要real server安裝相應的內核補丁，這對於在線業務遷移帶來具大的成本。
我們采用proxy protocol將client的真實IP和端口號進行封裝，然后傳遞給后端的應用，由於采用了應用層的方式，應用層支持proxy protocol即可，無需要修改內核代碼，並且升級修改對業務無損。
proxy protocol交互過程和協議格式如下圖所示：
proxy protocol format：PROXY_STRING + single space + INET_PROTOCOL + single space + CLIENT_IP + single space + PROXY_IP + single space + CLIENT_PORT + single space + PROXY_PORT + "\r\n"
Example：PROXY TCP4 198.51.100.22 203.0.113.7 35646 80\r\n
在收到客戶端發過來的第一個ACK數據包時，插入一個TCP數據包，負載是上述proxy protocol內容。
高可靠性的實現
管理流量與業務流量分離
如果管理流量和業務流量夾雜在一起，在高業務流量的情況下，對管理流量可能會產生影響，如：bgp引流出錯、配置的丟失、健康檢查報文的丟失等。所以我們需要將業務流量和管理流量進行分離。我們結合dpdk的fdir技術和對rss hash配置的源碼修改來實現。
由於控制平面基於Linux的進程，所以我們使用了kni口作為管理數據流接口，首先我們通過fdir接口，將kni的IP地址下發給網卡，並綁定到網卡的0號隊列。然后對dpdk的rss hash進行了修改，保證業務報文（非kni ip）在rss hash隊列時，從1～N中選擇。邏輯流程如下圖所示：
會話同步
為了保障一些服務的長鏈接在部分四層負載服務節點出現異常后，同集群其他節點能夠處理已建立的TCP連接，需要對會話進行跨機器存儲，來保證四層負載設備出現異常時，流量被牽引到其他四層負載節點上，數據包能夠繼續正確轉發。
對於京東一個在線業務來說，在線活躍連接在大促期間會非常大，為此，DLVS會話同步方案設計出發點是需要支持億級用戶在線，並可以根據業務增長在單集群內水平擴展。對於會話保持的實施方案，我們先對現有方案進行了調研，然后結合現有方案的不足進行重新設計。
現有方案：
方案一，每台四層負載都采用主備的方式。具體邏輯架構如圖所示：
從邏輯架構圖上，可以明確看到這種方案的優缺點。優點是實現簡單、擴展性好。缺點是正常工作時，一半的服務器閑置，造成資源浪費。
方案二，對四層負載進行分組，組內成員通過組播進行會話同步，邏輯架構如圖所示：
與方案一相比，該方案可以充分利用四層負載服務器，不會造成資源的浪費。但是，它的缺點也很明顯，由於四層負載集群被分組。分組內的四層負載通過組播的方式相互同步會話。這就會導致組的大小受限於單台四層負載的容量和帶寬，集群組無法靈活地擴展。
DLVS會話同步方案：
為了盡量減少資源浪費的問題，我們對四層負載進行了分類，master DLVS和backup DLVS。master DLVS用於承載正常業務流量，backup DLVS用於承載出現異常的master DLVS的流量。考慮到業務整體突發異常性的概率， backup DLVS數量遠小於master DLVS的數量，而且對backup DLVS的容量和帶寬進行了擴容。
為了解決橫向擴展的問題，我們首先采取了外部cache存儲全局會話，其次將分組對業務（vip）透明，通過虛擬的分組來進行cache和backup DLVS的划分，從而使得橫向擴展不會受限於單台四層負載的容量和帶寬。使得四層負載在支持會話同步的情況下，實現對億級在線用戶流量的負載服務穩定。
結合解決資源浪費和擴展性的問題，給出整體的系統架構圖：
為了更加方便大家了解會話同步相關的數據流程，我們結合幾個場景講解數據流的走向。
1. 分組對業務透明
通過將backup DLVS和cache進行分組，實現了業務master DLVS的分組的透明。使得DLVS的集群可以橫向擴展，用於支撐億級在線用戶業務。
2. 正常DLVS的數據流
3. 宕機DLVS的數據流
4. 重啟DLVS的數據流
重啟過程中的數據流和宕機的數據流基本一致，參考宕機數據流。
重啟后的數據流，首先恢復的master DLVS依據device id與cache進行會話批量同步，同步完后發送恢復通告給backup DLVS，然后master DLVS進行業務流量的轉發。
5. 新增DLVS的數據流
新增master DLVS時，首先根據device id與cache進行會話同步，然后發送設備新增通告，最后轉發業務流量。由於一致性hash的原因，會有一部分原有會話流量發送到新增DLVS上，DLVS將流量轉發給backup DLVS，backup進行會話查詢，根據device id進行二層轉發給原DLVS，保證會話的一致性。
安全防護的實現
作為流量的入口，需要提供基礎的流量防護功能。傳統的方式是在流量出入口部署流量檢測和清洗設備。檢測是被一般是旁路部署，通過引流的方式將異常流量引流到清洗設備進行清洗，然后進行流量回注。采用旁路部署的方式，主要是為了防止因為清洗異常流量的性能消耗（清洗設備對報文進行了深度的分析）而影響到正常流量。但旁路部署同樣帶來了一些問題，比如：清洗設備對報文進行了深度的解析分析（七層報文解析分析），使其自己成為流量的瓶頸；流量的多次轉發造成一定的延遲；未被牽引的流量不能進行安全防護；對實際業務用戶無感知等
四層負載作為流量的入口，由於我們采用的高性能實現方案，大大提升了四層負載的性能，所以我們希望四層負載能夠替代傳統的流量檢測和清洗設備功能。來減少延遲、對全部業務進行四層防護，並結合業務進行定制化防護等。同時不需要在部署流量監測和清洗設備，節省大量的資源。
流量清洗設備防護內容一般包括畸形報文防護、黑白名單支持、dns防護、四層ddos防護、cc防護等。考慮到報文解析和深度分析帶來的性能消耗，結合四層負載所承載的功能，我們已經將報文解析到了傳輸層（TCP、UDP等），將cc的防護放到了四層負載后端的七層負載上來進行。把畸形報文防護、黑白名單、dns防護和四層ddos防護放到DLVS上來實現（這也符合網絡分層防護的思想）。最終流量接入的防護架構如下。
在通過四七層負載來提供分層防護替換流量檢測和清洗設備后，使得整個流量接入的網絡拓撲變得簡單易操作。
結合具體的實現我們來詳細解讀四層防護在DLVS上的實現
一鍵開啟關閉
對於安全防護，我們采取了一鍵開啟或關閉。在安全防護能力比較健全的用戶環境中，可以直接關閉安全防護功能，以便進一步提升四層負載的性能。
同時，我們也支持了基於vip的安全防護開關，可以根據特殊的業務，開啟安全防護功能，使得安全防護更加靈活。
多樣性防護
開源lvs在安全防護上，只支持了synproxy（用於對tcp syn flood的偽造源IP進行校驗）。我們在支持synproxy的基礎上，增加了多種防護機制。
畸形報文防護：對於數據報文解析過程中，對非法的報文（IP分片攻擊、TCP標志位攻擊、smurf攻擊和land攻擊等）格式進行過濾。
黑白名單：結合大數據學習分析和威脅情報的信息，直接對五元組報文進行過濾或放行。對於臨時的業務封禁非常便捷。
DNS防護：對於DNS的flood攻擊、DNS緩存投毒攻擊、DNS異常報文攻擊等的防護。
四層DDOS防護：對udp flood、icmp flood、tcp flags flood等進行防護。
結合一鍵開關和多樣性防護，我們安全防護內部的數據包流程邏輯如下圖所示：
增加了安全防護后，必然會對四層負載的性能造成一定的影響，不過我們經過優化處理后，單機的TCP新建也達到了1M、並發達到了8M+，足以滿足線上業務需求。
常用防護手段
結合業務使用場景的實現。我們對主要的TCP攻擊防護、UDP攻擊防護和DNS攻擊防護進行概要的介紹。
- TCP防護的常用手段：synproxy、首包丟棄、tcp flags檢查、sequence檢查、基於閾值的分析、限速等
- UDP防護的常用手段：基於閾值的分析、UDP報文隨機指針內容統計、負荷指紋學習和識別、限速等。
- DNS防護的常用手段：基於閾值的分析、首包丟棄、構造request回驗、校驗query id和域名等
高性能的實現
dpdk的使用
底層的框架我們采用的是Intel提供的dpdk技術。dpdk的特性(用戶態驅動、網卡驅動采取poll mode、支持burst收發、支持大頁內存、numa、無鎖隊列、CPU親和性、內存池等)我們這里不再重復，詳情參考官網www.dpdk.org。我們采用了run-to-completion的方式，主要是考慮到減少線程之間通過隊列傳遞報文造成的性能損耗。dpdk主要模塊分解(摘自網絡)如下圖所示：
配置無鎖實現
四層負載配置的管理不同於通用網絡設備，由於后端的real server可能會經常的變化。所以四層負載下發配置的頻率也會比較高。傳統的實現方式，對於配置的下發，都是要進行加鎖處理的。這勢必會影響其它流量的性能。
為了避免這種影響，我們通過配置per core化即master core利用core間隊列，為每個業務core都下發一份配置，各個業務core順序執行讀取配置和處理業務，實現了配置下發的無鎖。
會話無鎖實現
四層負載的新建和並發能力，直接和會話的創建和查找是否加鎖有直接關系。如果一個會話只有一個core來處理，即可實現無鎖，但是多核處理器下如何保證上下行流量都能落到同一個core呢？
我們再下發配置時，將local ip進行了per core綁定，即下行流量通過rss hash到達某個core綁定的隊列時，在選擇local ip時，也就只會選擇已經綁定該core的local ip。同時我們利用fdir技術，將該local ip與該core 綁定的網卡隊列綁定。這樣便實現了上下行流量都落在同一個業務處理core。邏輯流程如下所示：
性能數據
數據基於X86服務器並配置Intel X520網卡，分別以大小數據包為例，對轉發過程中的bps、cps及cpu使用率進行了統計。
| CPU型號 |
資源大小 |
bps |
CPS（每秒TCP新建連接數） |
CPU(%) |
|---|---|---|---|---|
| Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.10GHz |
2 |
8.5G |
120萬+ |
90 |
| Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.10GHz |
2K |
9.2G |
40萬+ |
40 |
線上應用
京東商城SLB應用場景
DLVS是京東商城用戶接入系統一部分，為全站業務提供四層負載均衡服務，目前接入業務除了有短連接服務，還有像IM，消息推送等長連接業務場景。 DLVS作為底層服務，承載全站業務流量，除了在實現上要保障高可用，同時在線上部署架構層面，我們要規避依賴的基礎設施故障（比如機房，機架） 層面對服務的影響，為此我們和網絡團隊一起協作，設計了一套全新部署架構，實現了部署在多機房里的DLVS集群互備，依賴京東商城內網傳輸網絡，通過動態路由（IBGP）將流量導入到DLVS集群，依賴BGP的強大流量調度功能，可以快速地將不同VIP的流量在集群間調度，在依賴底層的基礎設施出現故障時，系統自動將流量切換到其它機房備份集群，整個過程對服務幾乎無影響，示意圖如下：
DLVS和交換機建立BGP連接，集群的機器發布同樣的路由，不同集群之間通過BGP的community選項進行區分，通過匹配不同的community字段在把路由重分布時設置不同的cost，來控制路由。在所有集群的BGP失效時，所有流量落到其中一個默認的集群
京東雲IP高防應用場景
京東雲高防產品針對網站類業務提供網站高防服務，非網站類業務提供IP高防服務。
在高防業務場景中，流量首先到我們的DLVS，經過清洗模塊完成流量清洗后，通過FULLNAT模式將流量導入到用戶源站或者我們的WAF集群。在高防IP中部署邏輯圖如下：
總結
基於Intel dpdk實現的高性能四層負載DLVS，無論是京東商城接入體系和京東雲高防產品中作為所有業務流量的入口，在平台可用性和支撐業務發展都發揮了重要的作用。與開源實現相比，支持會話同步以及層網絡防護等特性，為業務提供了更精細化的服務質量保障，成為同類產品中的佼佼者。現已整合為企業接入系統解決方案的核心部件，對外提供解決方案支持，幫助公司快速建立一套領先的流量接入體系，並可在此基礎上進行二次開發，根據公司業務特點進行定制化，為業務保駕護航。