TCP長連接負載均衡在大型銀行渠道中的應(yīng)用

勞 偉

(中國農(nóng)業(yè)銀行股份有限公司 軟件開發(fā)中心，北京 100073)

0 引言

銀行渠道系統(tǒng)既要作為服務(wù)端接收ATM、POS等本行外圍設(shè)備以及銀聯(lián)、國際銀行卡組織等行外系統(tǒng)的交易請求，也要作為客戶端將交易請求轉(zhuǎn)發(fā)至本行后臺系統(tǒng)以及銀聯(lián)、VISA、Mastercard、美國運通、大萊、JCB等銀行卡組織。銀行渠道系統(tǒng)不僅需要7×24小時不間斷運行，還需要具備在春節(jié)、國慶等交易高峰期平穩(wěn)運行的能力。

銀行渠道系統(tǒng)與關(guān)聯(lián)系統(tǒng)之間通常基于TCP協(xié)議進行消息交互。TCP作為一個面向連接的協(xié)議，傳輸數(shù)據(jù)之前，需要在客戶端與服務(wù)端之間建立連接，數(shù)據(jù)傳輸停止后，需要終止連接以釋放資源。建立連接需要三次握手，斷開TCP連接需要四次揮手[1]。

銀行渠道系統(tǒng)為支撐核心業(yè)務(wù)，普遍采用集群部署方式實現(xiàn)高可用、高可靠和可擴展。建立連接屬計算密集型操作，頻繁交互場景下不適合采用短連接通信方式，故銀聯(lián)、VISA、Mastercard等銀行卡組織均要求成員機構(gòu)采用長連接入網(wǎng)方式[2-4]，因此銀行渠道系統(tǒng)面臨著如何實現(xiàn)長連接負載均衡的問題。

客戶端和服務(wù)端完成一次消息交互后即斷開TCP連接的方式為TCP短連接。建立TCP連接后進行多次消息交互，直至客戶端或服務(wù)端退出時終止連接的方式為TCP長連接。采用傳統(tǒng)負載均衡模式時，每條客戶端長連接僅能接入服務(wù)集群中的1個節(jié)點，各節(jié)點的負載并不均衡，無法動態(tài)調(diào)整節(jié)點數(shù)量。

為應(yīng)對上述問題，本文提出了基于F5公司的OneConnect、MBLB技術(shù)實現(xiàn)的TCP長連接負載均衡方案，方案已經(jīng)過大型銀行渠道系統(tǒng)的長期實踐檢驗，取得了優(yōu)化連接、節(jié)約資源的預(yù)期效果。

1 傳統(tǒng)負載均衡模式現(xiàn)狀分析

經(jīng)過多年發(fā)展，傳統(tǒng)負載均衡模式產(chǎn)生了若干類型，主要類型有：

(1)基于DNS輪詢的負載均衡

DNS為同一域名配置多個IP地址，客戶端查詢域名時獲取其中的一個IP地址以實現(xiàn)負載均衡[5]。DNS負載均衡常用于Web集群服務(wù)。

(2)基于代理服務(wù)器的負載均衡

通過代理服務(wù)器將請求分發(fā)至多臺服務(wù)器以實現(xiàn)負載均衡。Linux下可用LVS實現(xiàn)代理服務(wù)器[6]。

(3)基于NAT的負載均衡

網(wǎng)絡(luò)地址轉(zhuǎn)換(Network Address Translation，NAT)是一種將外部IP映射為多個內(nèi)部IP的技術(shù)。Linux內(nèi)核已包含NAT負載均衡功能，通過客戶端動態(tài)連接一個內(nèi)部IP的方式實現(xiàn)負載均衡[7]。

本質(zhì)上傳統(tǒng)負載均衡模式是從服務(wù)端集群中選擇1個服務(wù)節(jié)點進行連接，如圖1所示。

圖1 傳統(tǒng)負載均衡模式示意圖

因此傳統(tǒng)負載均衡模式適用于TCP短連接的場景，在TCP長連接場景下達不到負載均衡的效果。

2 頻繁交互場景下TCP短連接存在的問題

頻繁交互的應(yīng)用場景下采用TCP短連接的通信方式，存在TIME_WAIT狀態(tài)套接字過多、CPU及內(nèi)存資源消耗過高、吞吐率偏低等諸多問題。

2.1 TIME_WAIT狀態(tài)套接字過多

頻繁建立、拆除TCP短連接，系統(tǒng)內(nèi)核中將不可避免地出現(xiàn)大量處于TIME_WAIT狀態(tài)的套接字。

TIME_WAIT狀態(tài)又稱為2MSL等待狀態(tài)。TCP協(xié)議規(guī)定主動關(guān)閉連接一方的套接字在發(fā)送最后一個ACK后進入TIME_WAIT，等待2倍報文段最長存活時間(Maximum Segment Lifetime， MSL)之后，轉(zhuǎn)入CLOSED狀態(tài)，內(nèi)核釋放CLOSED狀態(tài)的套接字資源。

MSL是TCP報文段在網(wǎng)絡(luò)上的最長存活時間，超過MSL的報文段將被網(wǎng)絡(luò)設(shè)備自動丟棄。RFC 1122建議將MSL設(shè)為2 min，Berkeley TCP的MSL為30 s。

RFC 1185描述了TCP協(xié)議設(shè)置TIME_WAIT的兩個理由：

(1)可靠終止TCP連接的兩個方向(全雙工關(guān)閉);

(2)等待網(wǎng)絡(luò)設(shè)備丟棄已關(guān)閉連接的重復(fù)報文段。

簡而言之，主動關(guān)閉連接一方保存關(guān)閉連接的傳輸控制塊(Transmission Control Block,TCB)至2倍MSL，是為了防止主動關(guān)閉連接一方新建連接四元組信息(源地址、源端口、目的地址、目的端口)與仍在網(wǎng)絡(luò)中傳輸?shù)呐f連接重復(fù)報文段出現(xiàn)重復(fù)。

主動關(guān)閉TCP連接的狀態(tài)轉(zhuǎn)換過程如圖2所示。

圖2 主動關(guān)閉TCP連接的過程

內(nèi)核為新建連接創(chuàng)建TCB以保存TCP連接四元組等重要信息，并通過TCB列表管理連接。接收TCP報文時，內(nèi)核檢索TCB列表將分解的應(yīng)用報文交給對應(yīng)的套接字。

系統(tǒng)能夠保存的TCB數(shù)量不僅取決于內(nèi)核內(nèi)存的大小，而且取決于系統(tǒng)中的TCP連接狀態(tài)。當系統(tǒng)存在大量TIME_WAIT狀態(tài)的TCP連接時，內(nèi)核維護TCB列表的開銷將會增長，甚至會因資源消耗過多出現(xiàn)系統(tǒng)服務(wù)中斷的情況。

目前國內(nèi)幾家大型商業(yè)銀行渠道系統(tǒng)的日交易量均為千萬級別，支撐的核心業(yè)務(wù)交易峰值已過萬級TPS。從投資效益角度看，渠道系統(tǒng)的配置不會很高，在資源有限的條件下，采用短連接意味著渠道系統(tǒng)的內(nèi)核中要保存大量處于TIME_WAIT的TCB。

以中國農(nóng)業(yè)銀行卡受理中心系統(tǒng)為例，該系統(tǒng)處理能力為3 000 TPS，基于Linux集群部署，MSL為30 s。如果采用TCP短連接，理論上則需保存18萬個TCB，按50個節(jié)點計算，各節(jié)點需保存3 600個TCB。有研究者在傳輸速率640 Mb/s的Myrinet局域網(wǎng)環(huán)境下進行了測試，結(jié)果顯示1臺安裝了SunOS 4.1.3系統(tǒng)的SPARCStation 20/71工作站最多支持每秒60個TCP短連接[8]。

2.2 減少TIME_WAIT狀態(tài)的風險

為避免TIME_WAIT過多消耗系統(tǒng)資源，網(wǎng)絡(luò)上出現(xiàn)了各種修改內(nèi)核參數(shù)減少TIME_WAIT的措施。如縮小Windows注冊項HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters中的TcpTimedWaitDelay數(shù)值，啟用Linux系統(tǒng)內(nèi)核參數(shù)net.ipv4.tcp_tw_reuse、net.ipv4.tcp_tw_recycle。

在NAT環(huán)境下使用上述方法將會導(dǎo)致網(wǎng)絡(luò)通信出現(xiàn)異常。

采用上述方法時需要NAT設(shè)備轉(zhuǎn)發(fā)TCP包時重寫TCP時間戳、轉(zhuǎn)發(fā)新建TCP連接請求時重新生成TCP初始序列號(Initial Sequence Number,ISN)。當前NAT協(xié)議規(guī)范中并不包含上述功能，在NAT環(huán)境下減少TIME_WAIT的風險很高，原因如下：

RFC 1323規(guī)定TCP時間戳由報文發(fā)送方設(shè)置，主要用于往返時間測量(Round-trip Time Measurement，RTTM)和TCP序列號回繞保護(Protect Against Wrapped Sequences,PAWS)，Linux的TCP時間戳是系統(tǒng)啟動至今經(jīng)歷的毫秒數(shù)量。新建連接時隨機設(shè)置ISN的目的是為了防止攻擊者猜測報文序列號、偽造TCP報文攻擊系統(tǒng)。

RFC 1337 (TIME-WAIT Assassination hazards)公告所列網(wǎng)絡(luò)故障案例的根源均和主動關(guān)閉連接一方提前回收或重用TIME_WAIT狀態(tài)套接字有關(guān)。提前回收或重用TIME_WAIT套接字時，僅支持標準協(xié)議的NAT設(shè)備將自動重用舊連接四元組，并由此導(dǎo)致TCP時間戳或ISN出現(xiàn)亂序，最終引發(fā)連接超時、連接劫持、拒絕服務(wù)等網(wǎng)絡(luò)異常[9]。

3 TCP長連接負載均衡面臨的挑戰(zhàn)

TCP長連接沒有TIME_WAIT的問題，但是設(shè)計長連接負載均衡方案時將面臨健康檢查、并發(fā)連接數(shù)、無狀態(tài)服務(wù)、消息邊界等諸多挑戰(zhàn)。

3.1 健康檢查

健康檢查是指檢查網(wǎng)絡(luò)設(shè)備、服務(wù)系統(tǒng)的運行狀況，及時發(fā)現(xiàn)事件故障、潛在問題和性能瓶頸，為優(yōu)化調(diào)整網(wǎng)絡(luò)設(shè)備、服務(wù)系統(tǒng)提供決策支持[10]。通常采用發(fā)送檢查報文的形式檢測集群節(jié)點的健康狀態(tài)，長連接方式下需要設(shè)計合適的檢查機制，確保健康檢查涵蓋所有的節(jié)點。

3.2 并發(fā)連接數(shù)

采用TCP長連接時，服務(wù)端需要限制同一客戶端的連接個數(shù)，以防止客戶端頻繁建立連接耗盡服務(wù)端的資源。

以銀聯(lián)為例，大型入網(wǎng)機構(gòu)和銀聯(lián)之間的連接數(shù)限制通常為8進8出16條TCP單工長連接，小型入網(wǎng)機構(gòu)的連接數(shù)限制通常為2進2出4條TCP單工長連接。

3.3 無狀態(tài)服務(wù)

一筆銀行交易的處理過程中可能包含多次消息交互，為了實現(xiàn)負載均衡，需要將其中的各個消息分發(fā)至服務(wù)端集群中的不同節(jié)點，因此服務(wù)端系統(tǒng)需要實現(xiàn)無狀態(tài)服務(wù)。相比短連接，長連接方式下實現(xiàn)無狀態(tài)服務(wù)的方法更為復(fù)雜。

3.4 確定消息邊界

負載均衡設(shè)備(或負載均衡軟件)從客戶端長連接收到的數(shù)據(jù)中可能包含多個消息。為了將各個消息分發(fā)至服務(wù)端集群中的不同節(jié)點，各個消息需要有明確的邊界信息，如消息長度(如HTTP報文頭的Content-Length)或消息起始標記。

4 TCP長連接負載架構(gòu)

針對長連接負載均衡面臨的上述挑戰(zhàn)，有研究者設(shè)計了基于軟件實現(xiàn)的TCP長連接負載均衡器，通過非阻塞帶優(yōu)先級的事件調(diào)度模型處理連接建立、健康檢查、負載任務(wù)分派、進程間通信、響應(yīng)接收和報文轉(zhuǎn)發(fā)，通過虛擬IP加雙機主備部署負載均衡器的方式消除單點風險[11]。

相比專業(yè)的負載均衡設(shè)備，負載均衡軟件在算法、帶寬占用、加速比、可靠性、可維護性、可擴展性等方面還存在一定的差距，因此銀行更傾向于選擇相對成熟的專業(yè)設(shè)備實現(xiàn)核心業(yè)務(wù)的負載均衡。

本文提出的TCP長連接負載均衡方案正是基于當前金融行業(yè)廣泛使用的F5公司的負載均衡設(shè)備，方案采用了OneConnect、MBLB等F5提供的技術(shù)。

4.1 OneConnect連接聚合技術(shù)

新建連接屬計算密集型過程，不僅耗費CPU資源，而且還要為連接狀態(tài)和通信緩存區(qū)分配內(nèi)核內(nèi)存，為減少資源消耗，HTTP/1.1已將keep-alives作為默認標準。TCP連接數(shù)越少，不僅意味著應(yīng)用線程/進程數(shù)越少，應(yīng)用線程/進程上下文切換的頻率越低，而且意味著消耗的系統(tǒng)資源越少，系統(tǒng)有效容量越高。

OneConnect為同步處理方式，該方式通過重用服務(wù)端TCP連接、減少連接數(shù)，減輕服務(wù)器負載及帶寬成本。

OneConnect方式默認支持HTTP連接聚合，F(xiàn)5收到服務(wù)端響應(yīng)后，將服務(wù)端連接放入連接重用池；收到客戶端連接請求時，從連接重用池中選出一條可重用的服務(wù)端連接；通過配置iRules規(guī)則(F5可編程網(wǎng)絡(luò)語言，tclsh腳本)實現(xiàn)TCP連接聚合[12]。

F5提供Source Mask配置項以限定服務(wù)端連接重用的客戶端范圍。比如設(shè)為255.255.255.255限定連接重用池中的連接僅供原連接客戶端使用。

如圖3所示，基于OneConnect聚合ATM連接時，F(xiàn)5通過重用服務(wù)端長連接將ATM交易報文轉(zhuǎn)發(fā)至渠道集群中的服務(wù)節(jié)點；服務(wù)節(jié)點通過原連接將應(yīng)答返回給F5之后，不關(guān)閉連接以支持F5重用連接。

圖5 基于MBLB技術(shù)均衡網(wǎng)控器接入POS業(yè)務(wù)的方案

4.2 基于消息進行負載均衡的MBLB技術(shù)

MBLB(Message Based Load Balancing)是F5公司基于消息進行負載均衡的技術(shù)，采用MBLB分發(fā)的消息需要包含長度或起始標記等邊界信息。F5通過配置的iRules規(guī)則識別TCP數(shù)據(jù)流中的消息邊界[13]，從中拆分出相互獨立的消息，將每個消息作為負載均衡的基本單元，依據(jù)配置的策略分發(fā)至各服務(wù)節(jié)點，分發(fā)過程如圖4所示。

圖4 不間斷接收消息場景下MBLB分發(fā)負載過程示意圖

MBLB為非阻塞異步處理方式，采用該方式的客戶端或服務(wù)端可持續(xù)向?qū)Χ税l(fā)送消息，不必等待對端響應(yīng)。

MBLB方式下，F(xiàn)5默認為每條客戶端連接建立一組連通服務(wù)集群所有節(jié)點的長連接，用戶可通過配置限制F5與各服務(wù)節(jié)點之間建立的連接數(shù)量。

MBLB適用于均衡網(wǎng)控器接入的POS業(yè)務(wù)。網(wǎng)控器接入的POS報文包含報文長度及標記POS通信線路的TPDU(Transport Protocol Data Unit)信息。網(wǎng)控器的每塊上聯(lián)卡可與渠道系統(tǒng)建立一條TCP雙工長連接，通過這些連接向渠道系統(tǒng)轉(zhuǎn)發(fā)POS請求、異步接收渠道系統(tǒng)的應(yīng)答，依據(jù)應(yīng)答中的TPDU將應(yīng)答報文返回給對應(yīng)的POS。采用MBLB均衡POS業(yè)務(wù)的方案如圖5所示。

VISA、Mastercard等國際銀行卡組織與入網(wǎng)機構(gòu)之間采用TCP雙工長連接方式發(fā)送聯(lián)機交易請求、異步接收聯(lián)機交易應(yīng)答，交易報文中包含報文長度信息，適于采用MBLB方式進行負載均衡。

銀聯(lián)與入網(wǎng)機構(gòu)之間的聯(lián)機交易報文包含報文長度信息，但是采用收發(fā)分離的TCP單工長連接方式進行通信，因此采用MBLB均衡時需分別設(shè)計發(fā)送端、接收端的iRules規(guī)則。為保證處理過程的連續(xù)性，渠道服務(wù)節(jié)點可在發(fā)給銀聯(lián)的檢索參考號字段中設(shè)置當前節(jié)點標識，由F5根據(jù)配置的iRules規(guī)則解析銀聯(lián)應(yīng)答報文,從銀聯(lián)應(yīng)答的檢索參考號字段中取出節(jié)點標識，依據(jù)節(jié)點標識將應(yīng)答送回對應(yīng)的節(jié)點。

4.3 銀行渠道系統(tǒng)TCP長連接負載均衡整體架構(gòu)

銀行渠道系統(tǒng)負載均衡整體架構(gòu)如圖6所示，其中同步、異步指接收應(yīng)答的方式。

圖6 銀行渠道系統(tǒng)TCP長連接負載均衡整體架構(gòu)

4.4 技術(shù)可行性測試

使用LoadRunner模擬客戶端，80%的請求報文長度為200～300 B，20%的長度為1 200～1 400 B。

在一臺F5 BIG-IP LTM設(shè)備上開啟兩個測試端口，分別配置OneConnect及MBLB iRules規(guī)則。

測試服務(wù)端為一臺64位SuSE11.3虛擬機，CPU配置為AMD 6234 2.4 GB×2、內(nèi)存配置為4 GB。測試服務(wù)程序開3個TCP端口模擬3個節(jié)點，線程池最大容量為10 000。測試服務(wù)程序收到請求報文后隨機等待0～2 s模擬后端系統(tǒng)延遲，然后將請求報文直接返回給客戶端模擬后端系統(tǒng)應(yīng)答。

(1)OneConnect聚合連接技術(shù)測試

LoadRunner模擬50個客戶端，持續(xù)發(fā)壓時間5 min。各客戶端持續(xù)多輪測試，每輪測試建1條連接到F5，發(fā)送1筆請求、收到1筆應(yīng)答后關(guān)閉連接。接收應(yīng)答的超時時間為3 s。測試結(jié)果如表1所示。

表1 OneConnect聚合連接技術(shù)測試

(2)MBLB消息均衡技術(shù)測試

LoadRunner模擬50個客戶端，持續(xù)發(fā)壓時間為5 min。各客戶端建立1條長連接到F5，之后持續(xù)多輪測試，每輪測試連續(xù)發(fā)送4筆請求，接收4筆應(yīng)答。接收應(yīng)答的超時時間為3 s。測試結(jié)果如表2所示。

測試結(jié)果證明OneConnect聚合短連接、MBLB均衡長連接的技術(shù)可行。

表2 MBLB消息均衡技術(shù)測試

5 結(jié)論

本文所述TCP長連接負載均衡方案已于2014年應(yīng)用于中國農(nóng)業(yè)銀行的銀行卡受理中心系統(tǒng)，該系統(tǒng)承載了中國農(nóng)業(yè)銀行的ATM渠道、POS渠道，以及銀聯(lián)、VISA、Mastercard等銀行卡組織的聯(lián)機交易，日均交易量5 000萬筆。自方案實施以來，迄今為止該系統(tǒng)已平穩(wěn)運行了4年，通過了國慶、春節(jié)等多個交易高峰時段的壓力考驗，不僅實現(xiàn)了“無縫”停機運維、按需調(diào)整集群節(jié)點數(shù)量，而且系統(tǒng)運行監(jiān)控及統(tǒng)計分析結(jié)果顯示集群中各節(jié)點的負載相對均勻，各節(jié)點的CPU占用、內(nèi)存消耗、套接字數(shù)量、吞吐率、響應(yīng)時間等運行指標相對平穩(wěn)。因?qū)嵤┬Ч@著，本文所述方案已被F5公司作為金融行業(yè)優(yōu)化TCP連接、節(jié)約系統(tǒng)及網(wǎng)絡(luò)資源的典范。

TCP長連接負載均衡在中國農(nóng)業(yè)銀行渠道系統(tǒng)中的成功應(yīng)用，為大型銀行建設(shè)資源節(jié)約型負載均衡體系提供了借鑒。