原文地址：http://www.infoq.com/cn/articles/jingdong-network-framework-gateway-dlvs

DLVS誕生之初

在SLB這塊，京東用戶接入系統(tǒng)提供四層負載均衡服務和應用層負載均衡服務，對于公網(wǎng)流量接入部分，和很多公司一樣采用的是四層和應用層負載相結合的架構，利用四層負載來實現(xiàn)應用層的水平擴展。四層負載在JFE 1.0版本中使用開源的LVS實現(xiàn)，考慮單機性能的問題，使用了DR模式和集群部署方式，并將LVS和應用層負載按照服務單元進行部署。這種模式在中等規(guī)模的業(yè)務場景運行良好，隨著業(yè)務的不斷增長，單業(yè)務QPS超過200萬，以及全站HTTPS改造要求SSL在SLB上完成卸載，應用層負載集群規(guī)模將不斷擴大，同時受限機房機架資源等因素，需要實現(xiàn)四，應用層負載解耦。為此我們對四層負載進行了重新的設計和自主研發(fā)，加入了在線上服務保障過程中的業(yè)務訴求，在性能、可用性、運維管理以及安全防護上提升。

業(yè)務增長對性能的需求

在過去的10年，京東的流量峰值從幾十萬到現(xiàn)在的千萬級QPS，給流量分發(fā)的四層負載均衡服務帶來了巨大的挑戰(zhàn)。Linux內(nèi)核實現(xiàn)版本受限于網(wǎng)卡的中斷收包模式以及二三層鎖的開銷，系統(tǒng)經(jīng)過調優(yōu)后的轉發(fā)能力單臺QPS在十萬級別。為了滿足業(yè)務流量的陡增，只能是通過增加集群規(guī)模和通過多集群的方式進行擴容，隨著集群數(shù)量和規(guī)模的不斷增加，給服務保障帶來了具大的挑戰(zhàn)，容量管理以及容災方案設計都變得非常的復雜。

服務質量的精細化

由于支撐的業(yè)務場景越來越豐富，既有長連接（IM）應用場景又有視頻業(yè)務需求，同時業(yè)務對服務穩(wěn)定性的要求越來越高，接入平臺作為基礎設施服務，可用性要求越來越高，要求在不同層面保障服務的穩(wěn)定性，避免單機故障和機房故障對線上服務的影響。

目前常用的集群方案是采用路由來實現(xiàn)，在京東內(nèi)部我們使用的BGP協(xié)議（后面會介紹部署方式），最終要依賴交換機的ECMP來實現(xiàn)，ECMP的缺陷是如果一臺服務器宕機，同一條流的數(shù)據(jù)包可能就會被轉發(fā)到集群其它機器上，如果沒有會話同步，那么該連接數(shù)據(jù)包就會丟棄，最終業(yè)務層超時。這對于一些長連接在線的業(yè)務影響會更加明顯，比如在線的IM業(yè)務以及推送業(yè)務等服務。

運維管理的自動化

隨著業(yè)務流量的陡增，集群規(guī)模越來越大和多集群的出現(xiàn)，同時對于線上大量應用的業(yè)務配置變更，對運維也是很大的挑戰(zhàn)。自動化程度，成為衡量公司技術能力的一項重要指標。

對于接入平臺，承載了公司眾多的業(yè)務，實現(xiàn)快速的業(yè)務變更同時做到每次變更對業(yè)務無損，從平臺角度看這是必須要去解決的問題。

安全防護能力

接入流量作為服務入口，在面對網(wǎng)絡攻擊時，需要具備安全防護的能力，保障平臺服務的穩(wěn)定性，同時做到對業(yè)務透明和精準防護，減少對業(yè)務的影響。傳統(tǒng)方案通常采用單獨的檢測和清洗集群來實現(xiàn)，從技術層面看完全可以把異常流量清洗功能移到四層負載上，并以集群的方式部署，節(jié)省資源的同時減少旁路部署帶來的復雜網(wǎng)絡拓撲。同時四層負載更加接近業(yè)務，更方便用戶根據(jù)特定業(yè)務定制一些安全規(guī)則，真正起到分層防護的能力，保證業(yè)務的安全穩(wěn)定。

方案選擇與功能定義

數(shù)據(jù)包收發(fā)方案選擇

對于高性能的數(shù)據(jù)包處理方案來說，目前主流方案包括了硬件化方案和軟件化方案。

對于硬件化方案，性能上雖然會優(yōu)于軟件化方案，但它昂貴的價格、有限的容量、靈活性和擴展性都不太適合處于中間轉發(fā)位置的四層負載。而且隨著多核服務器的普及，軟件方案也可以達到網(wǎng)卡限速的性能，從價格、容量和靈活性上都遠高于硬件方案，最終我們放棄了硬件方案。

在眾多的軟件化方案中，pfring依然輪詢RX Queue，而不能同時訪問所有的RX Queue。導致單核占用率比較高，不能充分利用多核性能。pfring和netmap對于大葉內(nèi)存和numa等也沒有庫來支持，在實際的應用中(多路處理器和網(wǎng)卡)，必然會影響性能。

綜合來看，dpdk能充分發(fā)揮多核處理的的優(yōu)勢，來提供更好的轉發(fā)性能外。同時dpdk提供了便于快速開發(fā)的庫（內(nèi)存池、網(wǎng)卡信息獲取、無鎖隊列、hash等）。最重要的是dpdk由Intel發(fā)起并支撐，加之社區(qū)活躍程度高，我們最終選擇了dpdk作為數(shù)據(jù)包收發(fā)方案。

功能定義

• 支持集群部署
• 支持配置集中管理
• 支持會話保持
• 支持tcp、udp的四層負載均衡
• 支持DR和FULLNAT模式
• 支持rr、wrr、源ip hash等負載均衡算法
• 支持主動健康檢查
• 支持透傳客戶機IP
• 支持會話同步
• 支持syn flood, ack flood等四層攻擊防護
• 支持畸形報文過濾、黑白名單

系統(tǒng)實現(xiàn)

DLVS核心架構

結合各個功能的實現(xiàn)方式，下圖是四層負載的DLVS的核心架構（后續(xù)章節(jié)會展開講解）。

DLVS包括數(shù)據(jù)平面和控制平面，控制平面主要負責配置、監(jiān)控和日志的管理。數(shù)據(jù)平面主要是基于dpdk實現(xiàn)的數(shù)據(jù)包處理和轉發(fā)。控制平面和數(shù)據(jù)平面的通信主要通過kni接口和unix 域套接字接口。

控制平面的quagga用于和交換機建立BGP連接，發(fā)布路由和DLVS保活監(jiān)控；keepalived用于vip、real server等業(yè)務的配置和real server的健康檢查；管理agent用于提供對外配置接口和日志上報接口。

數(shù)據(jù)平面雖然是單進程，但我們在內(nèi)部采用了多線程機制，并將管理和業(yè)務流量分離，以避免大的業(yè)務流量對管理流量產(chǎn)生影響。即把線程分為管理線程和業(yè)務線程，它們之間通過隊列進行通信。管理線程負責處理經(jīng)過內(nèi)核的報文、進程間通信的報文等，同時將配置下發(fā)給各個業(yè)務線程，既每個業(yè)務線程都擁有一份配置。業(yè)務線程有多個線程，包括負載均衡業(yè)務的處理、安全防護和會話管理等。

接下來我們從業(yè)務角度、性能角度、高可靠性角度和安全防護角度來說明四層負載DLVS的具體實現(xiàn)。

負載均衡業(yè)務的實現(xiàn)

結合京東商城和京東云的業(yè)務需求，對于四層負載我們支持了TCP和UDP兩種協(xié)議，支持fullnat和dr兩種模式，并支持了rr、wrr和源ip哈希選擇real server等基本功能，具體的實現(xiàn)我們不再詳細解讀，大家參考kernel版lvs的實現(xiàn)即可，原理方法基本一致。在這里我們只結合真實業(yè)務場景中遇到的問題來提醒大家在實現(xiàn)過程中特別需要注意的幾點。

rr算法選取real server

在實際使用過程中，每臺DLVS選取real server都是從頭開始輪詢的。在實際應用場景中，我們發(fā)現(xiàn)集群新增DLVS時，real server的流量嚴重不平衡，都集中在了配置的比較靠前的幾臺real server上。我們通過隨機哈希real server的位置，再進行rr選取，從而解決了這個問題。wrr的選取解決方案類似。

業(yè)務配置的加載

開源的lvs是kernel的module，在dpdk上來實現(xiàn)lvs的功能會導致原有的keepalived和ipvsadm無法進行配置和監(jiān)控的管理。我們利用域套接字實現(xiàn)的接口來替換keepalived和ipvsadm的消息下發(fā)接口，從而實現(xiàn)了dpdk版lvs與keepalived和ipvsadm的無縫對接。

業(yè)務的接口我們使用統(tǒng)一的庫DLVS wrapper來實現(xiàn)，交互流程如下圖所示：

Client真實IP獲取

由于業(yè)務的需要，有些服務需要獲取到client的真實IP和端口號。開源的lvs采用的toa（將真實源IP和端口加在tcp option中的方式），需要real server安裝相應的內(nèi)核補丁，這對于在線業(yè)務遷移帶來具大的成本。

我們采用proxy protocol將client的真實IP和端口號進行封裝，然后傳遞給后端的應用，由于采用了應用層的方式，應用層支持proxy protocol即可，無需要修改內(nèi)核代碼，并且升級修改對業(yè)務無損。

proxy protocol交互過程和協(xié)議格式如下圖所示：

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

在收到客戶端發(fā)過來的第一個ACK數(shù)據(jù)包時，插入一個TCP數(shù)據(jù)包，負載是上述proxy protocol內(nèi)容。

高可靠性的實現(xiàn)

管理流量與業(yè)務流量分離

如果管理流量和業(yè)務流量夾雜在一起，在高業(yè)務流量的情況下，對管理流量可能會產(chǎn)生影響，如：bgp引流出錯、配置的丟失、健康檢查報文的丟失等。所以我們需要將業(yè)務流量和管理流量進行分離。我們結合dpdk的fdir技術和對rss hash配置的源碼修改來實現(xiàn)。

由于控制平面基于Linux的進程，所以我們使用了kni口作為管理數(shù)據(jù)流接口，首先我們通過fdir接口，將kni的IP地址下發(fā)給網(wǎng)卡，并綁定到網(wǎng)卡的0號隊列。然后對dpdk的rss hash進行了修改，保證業(yè)務報文（非kni ip）在rss hash隊列時，從1～N中選擇。邏輯流程如下圖所示：

會話同步

為了保障一些服務的長鏈接在部分四層負載服務節(jié)點出現(xiàn)異常后，同集群其他節(jié)點能夠處理已建立的TCP連接，需要對會話進行跨機器存儲，來保證四層負載設備出現(xiàn)異常時，流量被牽引到其他四層負載節(jié)點上，數(shù)據(jù)包能夠繼續(xù)正確轉發(fā)。

對于京東一個在線業(yè)務來說，在線活躍連接在大促期間會非常大，為此，DLVS會話同步方案設計出發(fā)點是需要支持億級用戶在線，并可以根據(jù)業(yè)務增長在單集群內(nèi)水平擴展。對于會話保持的實施方案，我們先對現(xiàn)有方案進行了調研，然后結合現(xiàn)有方案的不足進行重新設計。

現(xiàn)有方案：

方案一，每臺四層負載都采用主備的方式。具體邏輯架構如圖所示：

從邏輯架構圖上，可以明確看到這種方案的優(yōu)缺點。優(yōu)點是實現(xiàn)簡單、擴展性好。缺點是正常工作時，一半的服務器閑置，造成資源浪費。

方案二，對四層負載進行分組，組內(nèi)成員通過組播進行會話同步，邏輯架構如圖所示：

與方案一相比，該方案可以充分利用四層負載服務器，不會造成資源的浪費。但是，它的缺點也很明顯，由于四層負載集群被分組。分組內(nèi)的四層負載通過組播的方式相互同步會話。這就會導致組的大小受限于單臺四層負載的容量和帶寬，集群組無法靈活地擴展。

DLVS會話同步方案：

為了盡量減少資源浪費的問題，我們對四層負載進行了分類，master DLVS和backup DLVS。master DLVS用于承載正常業(yè)務流量，backup DLVS用于承載出現(xiàn)異常的master DLVS的流量。考慮到業(yè)務整體突發(fā)異常性的概率， backup DLVS數(shù)量遠小于master DLVS的數(shù)量，而且對backup DLVS的容量和帶寬進行了擴容。

為了解決橫向擴展的問題，我們首先采取了外部cache存儲全局會話，其次將分組對業(yè)務（vip）透明，通過虛擬的分組來進行cache和backup DLVS的劃分，從而使得橫向擴展不會受限于單臺四層負載的容量和帶寬。使得四層負載在支持會話同步的情況下，實現(xiàn)對億級在線用戶流量的負載服務穩(wěn)定。

結合解決資源浪費和擴展性的問題，給出整體的系統(tǒng)架構圖：

為了更加方便大家了解會話同步相關的數(shù)據(jù)流程，我們結合幾個場景講解數(shù)據(jù)流的走向。

1. 分組對業(yè)務透明

通過將backup DLVS和cache進行分組，實現(xiàn)了業(yè)務master DLVS的分組的透明。使得DLVS的集群可以橫向擴展，用于支撐億級在線用戶業(yè)務。

2. 正常DLVS的數(shù)據(jù)流

3. 宕機DLVS的數(shù)據(jù)流

4. 重啟DLVS的數(shù)據(jù)流

重啟過程中的數(shù)據(jù)流和宕機的數(shù)據(jù)流基本一致，參考宕機數(shù)據(jù)流。

重啟后的數(shù)據(jù)流，首先恢復的master DLVS依據(jù)device id與cache進行會話批量同步，同步完后發(fā)送恢復通告給backup DLVS，然后master DLVS進行業(yè)務流量的轉發(fā)。

5. 新增DLVS的數(shù)據(jù)流

新增master DLVS時，首先根據(jù)device id與cache進行會話同步，然后發(fā)送設備新增通告，最后轉發(fā)業(yè)務流量。由于一致性hash的原因，會有一部分原有會話流量發(fā)送到新增DLVS上，DLVS將流量轉發(fā)給backup DLVS，backup進行會話查詢，根據(jù)device id進行二層轉發(fā)給原DLVS，保證會話的一致性。

安全防護的實現(xiàn)

作為流量的入口，需要提供基礎的流量防護功能。傳統(tǒng)的方式是在流量出入口部署流量檢測和清洗設備。檢測是被一般是旁路部署，通過引流的方式將異常流量引流到清洗設備進行清洗，然后進行流量回注。采用旁路部署的方式，主要是為了防止因為清洗異常流量的性能消耗（清洗設備對報文進行了深度的分析）而影響到正常流量。但旁路部署同樣帶來了一些問題，比如：清洗設備對報文進行了深度的解析分析（七層報文解析分析），使其自己成為流量的瓶頸；流量的多次轉發(fā)造成一定的延遲；未被牽引的流量不能進行安全防護；對實際業(yè)務用戶無感知等

四層負載作為流量的入口，由于我們采用的高性能實現(xiàn)方案，大大提升了四層負載的性能，所以我們希望四層負載能夠替代傳統(tǒng)的流量檢測和清洗設備功能。來減少延遲、對全部業(yè)務進行四層防護，并結合業(yè)務進行定制化防護等。同時不需要在部署流量監(jiān)測和清洗設備，節(jié)省大量的資源。

流量清洗設備防護內(nèi)容一般包括畸形報文防護、黑白名單支持、dns防護、四層ddos防護、cc防護等。考慮到報文解析和深度分析帶來的性能消耗，結合四層負載所承載的功能，我們已經(jīng)將報文解析到了傳輸層（TCP、UDP等），將cc的防護放到了四層負載后端的七層負載上來進行。把畸形報文防護、黑白名單、dns防護和四層ddos防護放到DLVS上來實現(xiàn)（這也符合網(wǎng)絡分層防護的思想）。最終流量接入的防護架構如下。

在通過四七層負載來提供分層防護替換流量檢測和清洗設備后，使得整個流量接入的網(wǎng)絡拓撲變得簡單易操作。

結合具體的實現(xiàn)我們來詳細解讀四層防護在DLVS上的實現(xiàn)

一鍵開啟關閉

對于安全防護，我們采取了一鍵開啟或關閉。在安全防護能力比較健全的用戶環(huán)境中，可以直接關閉安全防護功能，以便進一步提升四層負載的性能。

同時，我們也支持了基于vip的安全防護開關，可以根據(jù)特殊的業(yè)務，開啟安全防護功能，使得安全防護更加靈活。

多樣性防護

開源lvs在安全防護上，只支持了synproxy（用于對tcp syn flood的偽造源IP進行校驗）。我們在支持synproxy的基礎上，增加了多種防護機制。

畸形報文防護：對于數(shù)據(jù)報文解析過程中，對非法的報文（IP分片攻擊、TCP標志位攻擊、smurf攻擊和land攻擊等）格式進行過濾。

黑白名單：結合大數(shù)據(jù)學習分析和威脅情報的信息，直接對五元組報文進行過濾或放行。對于臨時的業(yè)務封禁非常便捷。

DNS防護：對于DNS的flood攻擊、DNS緩存投毒攻擊、DNS異常報文攻擊等的防護。

四層DDOS防護：對udp flood、icmp flood、tcp flags flood等進行防護。

結合一鍵開關和多樣性防護，我們安全防護內(nèi)部的數(shù)據(jù)包流程邏輯如下圖所示：

增加了安全防護后，必然會對四層負載的性能造成一定的影響，不過我們經(jīng)過優(yōu)化處理后，單機的TCP新建也達到了1M、并發(fā)達到了8M+，足以滿足線上業(yè)務需求。

常用防護手段

結合業(yè)務使用場景的實現(xiàn)。我們對主要的TCP攻擊防護、UDP攻擊防護和DNS攻擊防護進行概要的介紹。

• TCP防護的常用手段：synproxy、首包丟棄、tcp flags檢查、sequence檢查、基于閾值的分析、限速等
• UDP防護的常用手段：基于閾值的分析、UDP報文隨機指針內(nèi)容統(tǒng)計、負荷指紋學習和識別、限速等。
• DNS防護的常用手段：基于閾值的分析、首包丟棄、構造request回驗、校驗query id和域名等

高性能的實現(xiàn)

dpdk的使用

底層的框架我們采用的是Intel提供的dpdk技術。dpdk的特性(用戶態(tài)驅動、網(wǎng)卡驅動采取poll mode、支持burst收發(fā)、支持大頁內(nèi)存、numa、無鎖隊列、CPU親和性、內(nèi)存池等)我們這里不再重復，詳情參考官網(wǎng)www.dpdk.org。我們采用了run-to-completion的方式，主要是考慮到減少線程之間通過隊列傳遞報文造成的性能損耗。dpdk主要模塊分解(摘自網(wǎng)絡)如下圖所示：

配置無鎖實現(xiàn)

四層負載配置的管理不同于通用網(wǎng)絡設備，由于后端的real server可能會經(jīng)常的變化。所以四層負載下發(fā)配置的頻率也會比較高。傳統(tǒng)的實現(xiàn)方式，對于配置的下發(fā)，都是要進行加鎖處理的。這勢必會影響其它流量的性能。

為了避免這種影響，我們通過配置per core化即master core利用core間隊列，為每個業(yè)務core都下發(fā)一份配置，各個業(yè)務core順序執(zhí)行讀取配置和處理業(yè)務，實現(xiàn)了配置下發(fā)的無鎖。

會話無鎖實現(xiàn)

四層負載的新建和并發(fā)能力，直接和會話的創(chuàng)建和查找是否加鎖有直接關系。如果一個會話只有一個core來處理，即可實現(xiàn)無鎖，但是多核處理器下如何保證上下行流量都能落到同一個core呢？

我們再下發(fā)配置時，將local ip進行了per core綁定，即下行流量通過rss hash到達某個core綁定的隊列時，在選擇local ip時，也就只會選擇已經(jīng)綁定該core的local ip。同時我們利用fdir技術，將該local ip與該core 綁定的網(wǎng)卡隊列綁定。這樣便實現(xiàn)了上下行流量都落在同一個業(yè)務處理core。邏輯流程如下所示：

性能數(shù)據(jù)

數(shù)據(jù)基于X86服務器并配置Intel X520網(wǎng)卡，分別以大小數(shù)據(jù)包為例，對轉發(fā)過程中的bps、cps及cpu使用率進行了統(tǒng)計。

CPU型號

資源大小

bps

CPS（每秒TCP新建連接數(shù)）

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是京東商城用戶接入系統(tǒng)一部分，為全站業(yè)務提供四層負載均衡服務，目前接入業(yè)務除了有短連接服務，還有像IM，消息推送等長連接業(yè)務場景。 DLVS作為底層服務，承載全站業(yè)務流量，除了在實現(xiàn)上要保障高可用，同時在線上部署架構層面，我們要規(guī)避依賴的基礎設施故障（比如機房，機架） 層面對服務的影響，為此我們和網(wǎng)絡團隊一起協(xié)作，設計了一套全新部署架構，實現(xiàn)了部署在多機房里的DLVS集群互備，依賴京東商城內(nèi)網(wǎng)傳輸網(wǎng)絡，通過動態(tài)路由（IBGP）將流量導入到DLVS集群，依賴BGP的強大流量調度功能，可以快速地將不同VIP的流量在集群間調度，在依賴底層的基礎設施出現(xiàn)故障時，系統(tǒng)自動將流量切換到其它機房備份集群，整個過程對服務幾乎無影響，示意圖如下：

DLVS和交換機建立BGP連接，集群的機器發(fā)布同樣的路由，不同集群之間通過BGP的community選項進行區(qū)分，通過匹配不同的community字段在把路由重分布時設置不同的cost，來控制路由。在所有集群的BGP失效時，所有流量落到其中一個默認的集群

京東云IP高防應用場景

京東云高防產(chǎn)品針對網(wǎng)站類業(yè)務提供網(wǎng)站高防服務，非網(wǎng)站類業(yè)務提供IP高防服務。

在高防業(yè)務場景中，流量首先到我們的DLVS，經(jīng)過清洗模塊完成流量清洗后，通過FULLNAT模式將流量導入到用戶源站或者我們的WAF集群。在高防IP中部署邏輯圖如下：

總結

基于Intel dpdk實現(xiàn)的高性能四層負載DLVS，無論是京東商城接入體系和京東云高防產(chǎn)品中作為所有業(yè)務流量的入口，在平臺可用性和支撐業(yè)務發(fā)展都發(fā)揮了重要的作用。與開源實現(xiàn)相比，支持會話同步以及層網(wǎng)絡防護等特性，為業(yè)務提供了更精細化的服務質量保障，成為同類產(chǎn)品中的佼佼者。現(xiàn)已整合為企業(yè)接入系統(tǒng)解決方案的核心部件，對外提供解決方案支持，幫助公司快速建立一套領先的流量接入體系，并可在此基礎上進行二次開發(fā)，根據(jù)公司業(yè)務特點進行定制化，為業(yè)務保駕護航。

轉載于:https://www.cnblogs.com/davidwang456/articles/8440581.html

《新程序員》：云原生和全面數(shù)字化實踐50位技術專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的京东网络接入体系解密之高性能四层网关DLVS的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。