文 / 光大銀行金融科技部 張智峰 鄭皓廣 謝書華

【資料圖】

為滿足業(yè)務(wù)系統(tǒng)日益增長的可靠性與性能需求，銀行IT系統(tǒng)正朝著分布式架構(gòu)轉(zhuǎn)型。在轉(zhuǎn)型過程中，我們面臨著分布式系統(tǒng)云化部署、自主研發(fā)軟硬件適配等諸多挑戰(zhàn)。本文以光大銀行一次大型業(yè)務(wù)系統(tǒng)性能調(diào)優(yōu)為例，分享分布式系統(tǒng)調(diào)優(yōu)過程中的一些實踐經(jīng)驗。

環(huán)境介紹

該系統(tǒng)除進行分布式架構(gòu)改造外，還同步實現(xiàn)了自主研發(fā)軟硬件適配和云化部署，具體架構(gòu)和使用的技術(shù)產(chǎn)品如下所示。

1.基礎(chǔ)設(shè)施層部署模型介紹

該系統(tǒng)在光大銀行最新一代云計算平臺——全棧云部署，從底層硬件到操作系統(tǒng)、中間件及數(shù)據(jù)庫均選擇自主研發(fā)軟硬件解決方案。平臺主要分為：分布式云原生應(yīng)用、分布式數(shù)據(jù)庫和緩存數(shù)據(jù)庫三部分。其中云原生應(yīng)用和緩存數(shù)據(jù)庫分別以容器和虛擬機的形式部署，分布式數(shù)據(jù)庫則部署在裸金屬服務(wù)器上并搭配了NVMe本地存儲，操作系統(tǒng)全部使用自主研發(fā)Linux系統(tǒng)。

圖1 某大型分布式業(yè)務(wù)系統(tǒng)架構(gòu)圖

2.業(yè)務(wù)模型

為了驗證分布式架構(gòu)對高并發(fā)場景下的支撐能力，本次調(diào)優(yōu)特意選取了對高并發(fā)要求較高的聯(lián)機交易類系統(tǒng)。

如圖2所示，GW（網(wǎng)關(guān)）服務(wù)、DP（存款）服務(wù)、IA（內(nèi)部賬）服務(wù)、UNISN（全局序列號）服務(wù)、SEATA開源分布式事務(wù)等均采用微服務(wù)架構(gòu)運行在容器集群中。微服務(wù)會持續(xù)對服務(wù)注冊中心進行心跳檢測，同時定期獲取微服務(wù)清單和配置信息，以實現(xiàn)配置更新及服務(wù)發(fā)現(xiàn)。

業(yè)務(wù)請求經(jīng)GW服務(wù)調(diào)用DP服務(wù)接口識別業(yè)務(wù)類型，并根據(jù)業(yè)務(wù)邏輯在各微服務(wù)和數(shù)據(jù)庫間流轉(zhuǎn)。該系統(tǒng)需要在內(nèi)部高頻遠程過程調(diào)用的情況下，保證聯(lián)機交易低時延高并發(fā)的需求。

圖2 某大型分布式業(yè)務(wù)系統(tǒng)業(yè)務(wù)模型圖

對比傳統(tǒng)架構(gòu)，我們不難發(fā)現(xiàn)系統(tǒng)在進行微服務(wù)改造后整體架構(gòu)較為復(fù)雜，各微服務(wù)間存在大量遠程過程調(diào)用，導(dǎo)致了更多的網(wǎng)絡(luò)交互開銷，而這部分時間開銷在云計算SDN網(wǎng)絡(luò)下被進一步放大。

通用調(diào)優(yōu)

整體調(diào)優(yōu)工作分為兩個階段。第一階段旨在梳理業(yè)務(wù)模型，確立調(diào)優(yōu)思路，并分別對云網(wǎng)、數(shù)據(jù)庫及系統(tǒng)環(huán)境進行普適性調(diào)優(yōu)。我行各技術(shù)領(lǐng)域?qū)＜揖鶇⑴c到調(diào)優(yōu)過程中，通過網(wǎng)絡(luò)模型優(yōu)化、數(shù)據(jù)庫對象及環(huán)境優(yōu)化等手段，使基礎(chǔ)組件及設(shè)施更適合分布式架構(gòu)，充分發(fā)揮分布式架構(gòu)的優(yōu)勢。

1.云網(wǎng)篇

全棧云使用基礎(chǔ)網(wǎng)絡(luò)架構(gòu)（三層SDN網(wǎng)絡(luò)模型），節(jié)點間多采用Vxlan通信，負責(zé)Vxlan隧道解封裝的隧道端點VTEP，廣泛分布在算力資源、SDN網(wǎng)元、裸金屬網(wǎng)關(guān)等節(jié)點，導(dǎo)致各節(jié)點間互訪的流量路徑較為復(fù)雜?？紤]到分布式架構(gòu)下的高頻遠程過程調(diào)用使網(wǎng)絡(luò)開銷較大，為追求最佳性能，需要針對分布式架構(gòu)單獨設(shè)計網(wǎng)絡(luò)部署模型。我們將虛擬機及容器全部部署到相同VPC下的同一子網(wǎng)內(nèi)，使虛擬機與容器的網(wǎng)絡(luò)通信收束在Leaf交換機以下，規(guī)避了SDN層的頻繁轉(zhuǎn)發(fā)。在網(wǎng)絡(luò)部署模型優(yōu)化后，網(wǎng)絡(luò)的整體性能有了大幅提升，通過最直觀的ping測試數(shù)據(jù)，平均時延被控制在250微秒以內(nèi)，較優(yōu)化前350微秒的平均時延有了近30%的提升，整體性能提升了20%以上。

圖3 全棧云網(wǎng)絡(luò)物理部署圖

2.數(shù)據(jù)庫篇

從傳統(tǒng)集中式數(shù)據(jù)庫遷移至分布式數(shù)據(jù)庫面臨很大的困難挑戰(zhàn)，需要充分發(fā)揮分布式數(shù)據(jù)庫海量數(shù)據(jù)、高并發(fā)的性能優(yōu)勢，同時也要避免架構(gòu)由集中式轉(zhuǎn)變?yōu)榉植际綆淼娜秉c與不足，為此我們進行了如下的優(yōu)化措施。

■ 減少自增列使用：典型的存算分離架構(gòu)的分布式數(shù)據(jù)庫為了保證帶有自增列值在全分片內(nèi)保持唯一且遞增，需要一個統(tǒng)一服務(wù)來生成這種遞增序號，即GTM組件。分布式數(shù)據(jù)庫自增列的寫入效率并不及集中式數(shù)據(jù)庫，在高并發(fā)寫入場景下會成為性能瓶頸。因此我們?nèi)サ袅巳肿栽鰧傩?，?guī)避了生成全局遞增序號導(dǎo)致的性能瓶頸。

■ 批量優(yōu)化：為充分發(fā)揮分布式數(shù)據(jù)庫高并發(fā)的性能優(yōu)勢，我們對業(yè)務(wù)表以賬號進行了哈希水平分片，并在每個分片也以賬號做了哈希分區(qū)。應(yīng)用程序可以利用多線程以及數(shù)據(jù)庫STORAGEDB語法特性將SQL透傳至對應(yīng)分片，通過多分片多分區(qū)并行執(zhí)行的方式極大縮短了結(jié)息批量的執(zhí)行時間。隨著后續(xù)建設(shè)中分片數(shù)量增加，批量執(zhí)行時間也會隨著并行度增加而進一步縮短，甚至能夠超過傳統(tǒng)架構(gòu)使用的集中式數(shù)據(jù)庫。

同時，我們參考同業(yè)實踐經(jīng)驗以及我行實際情況對數(shù)據(jù)庫服務(wù)器內(nèi)存管理、磁盤數(shù)據(jù)管理策略做了調(diào)整。

■ 定時清理buff/cache：數(shù)據(jù)庫面對高并發(fā)讀寫場景時，服務(wù)器buff/cache的高占用容易成為性能瓶頸。我們引入定時清理策略進行，以減少因服務(wù)器緩存釋放不及時造成TPS和時延的不穩(wěn)定。

■ 條帶化：分布式數(shù)據(jù)庫DN節(jié)點屬于I/O密集型服務(wù)，盡量降低NVMe本地盤的讀寫延遲是需要考慮的方向。通過條帶化配置，數(shù)據(jù)讀取和寫入可以獲得最大程度的I/O并行能力，從而降低SQL語句執(zhí)行以及事務(wù)提交的時間開銷。

針對性能瓶頸的專項調(diào)優(yōu)

在普適性調(diào)優(yōu)之后，系統(tǒng)的整體性能有了顯著提升，但離預(yù)期仍有一定距離。我們發(fā)現(xiàn)各個計算節(jié)點的CPU、內(nèi)存使用率等指標均處于較低的水平，這說明性能瓶頸仍然存在，因此我們將目標轉(zhuǎn)向提升各組件在壓力測試下的資源利用率，并利用云上overlay流量觀測，underlay網(wǎng)絡(luò)探針和應(yīng)用日志埋點等手段分析隱藏的性能瓶頸點，利用工具精準錨定瓶頸點，提升“短板性能”。

分段時延獲取、

瓶頸點定位與針對性調(diào)優(yōu)

圖4 單交易分段時延獲取與分析

鏈路監(jiān)測通過捕獲應(yīng)用服務(wù)和數(shù)據(jù)庫的日志關(guān)鍵字的方式獲取鏈路分段時延。雖然日志輸出會犧牲系統(tǒng)性能，但能夠有效幫助我們分析各環(huán)節(jié)調(diào)用次數(shù)與時延并找到隱藏的性能瓶頸。

分析發(fā)現(xiàn)，單筆交易的時間開銷主要來自于應(yīng)用內(nèi)部的數(shù)據(jù)處理、數(shù)據(jù)庫的事務(wù)處理和微服務(wù)間RPC。為此，我們進行了針對性調(diào)優(yōu)。

1.在業(yè)務(wù)層，主要進行了緩存優(yōu)化、批量優(yōu)化和通訊優(yōu)化

緩存優(yōu)化：

（1）對于需要高頻訪問且日常改動較少的參數(shù)類庫表，考慮通過采用緩存數(shù)據(jù)來優(yōu)化訪問效率。

（2）一般情況，應(yīng)用在每次調(diào)用數(shù)據(jù)庫前會對SQL進行預(yù)編譯，對于SQL比較多的場景，預(yù)編譯的時間將被放大，通過對SQL預(yù)編譯的結(jié)果進行緩存，可以減少耗費在SQL預(yù)編譯上的時間。

（3）對注冊中心可用性進行了優(yōu)化，通過本地服務(wù)列表內(nèi)存緩存、本地服務(wù)列表文件緩存的多級緩存策略，在注冊中心整體宕機時盡量減少了對業(yè)務(wù)系統(tǒng)的影響。

批量優(yōu)化：充分發(fā)揮分布式架構(gòu)的優(yōu)勢，在資源允許的范圍內(nèi)進一步提高任務(wù)處理的并發(fā)度，將批量任務(wù)化整為零，通過合理的任務(wù)分片全面提升批處理效率。同時盡量避免大事務(wù)的產(chǎn)生，通過減小單個事務(wù)的規(guī)模，有效規(guī)避業(yè)務(wù)處理的潛在鎖沖突。

底層通訊優(yōu)化：在內(nèi)部服務(wù)高頻交互的場景下，將服務(wù)間的通訊協(xié)議由http協(xié)議改成了基于socket長連接的bolt協(xié)議，減少了通訊的損耗。

2.在數(shù)據(jù)庫方向，主要從事務(wù)和裸金屬網(wǎng)絡(luò)兩個方面進行了優(yōu)化

事務(wù)優(yōu)化：在確保相關(guān)的表和數(shù)據(jù)行不會涉及分布式事務(wù)并發(fā)讀寫的情況下，我們針對性地通過hint的方式降低了部分事務(wù)會話級的隔離級別，減少了不必要的查詢活躍事務(wù)列表、select for update時間開銷。

裸金屬網(wǎng)絡(luò)優(yōu)化：由于分布式數(shù)據(jù)庫涉及多節(jié)點間的通信協(xié)調(diào)，在網(wǎng)絡(luò)鏈路上的開銷遠高于集中式數(shù)據(jù)庫，為此我行全棧云專家也針對分布式數(shù)據(jù)庫內(nèi)部網(wǎng)絡(luò)進行了專項調(diào)優(yōu)。

圖5 裸金屬網(wǎng)絡(luò)調(diào)優(yōu)前ping測試數(shù)據(jù)

我們?yōu)槊恳慌_裸金屬節(jié)點新增了一個私網(wǎng)地址，專門用于裸金屬節(jié)點之間的互通，并對數(shù)據(jù)庫內(nèi)部網(wǎng)絡(luò)的流量模型和通信矩陣進行調(diào)整，使得裸金屬內(nèi)部通信可以通過Leaf交換機直接轉(zhuǎn)發(fā)的方式實現(xiàn)路徑最簡的高速網(wǎng)絡(luò)，平均ping延時由130us下降到了80us，性能大幅提升。

圖6 裸金屬網(wǎng)絡(luò)調(diào)優(yōu)后ping測試數(shù)據(jù)

overlay層數(shù)據(jù)包分析

云上環(huán)境很難利用傳統(tǒng)的underlay探針預(yù)埋手段獲取全量網(wǎng)絡(luò)流量信息，在此我們利用網(wǎng)絡(luò)可視化工具，在云化資源上部署agent觀察overlay層網(wǎng)絡(luò)。

通過云網(wǎng)可視化工具進行網(wǎng)絡(luò)抓包，我們發(fā)現(xiàn)通信包內(nèi)多次出現(xiàn)了重傳和零窗現(xiàn)象，如圖7所示。

圖7 利用云網(wǎng)可視化工具定位網(wǎng)絡(luò)問題

考慮到自主研發(fā)ARM服務(wù)器與我們熟知的IntelX86服務(wù)器除指令集外，其多核架構(gòu)也是一大不同點，沿用X86相關(guān)參數(shù)配置服務(wù)器的方式需要進行調(diào)整。

經(jīng)過業(yè)務(wù)分析發(fā)現(xiàn)，其中零窗和重傳集中于BMS007->BMS011與BMS008->BMS011兩條裸金屬服務(wù)器通信線路中，因此懷疑此部分網(wǎng)絡(luò)鏈路存在性能瓶頸。在升級業(yè)務(wù)邏輯并針對服務(wù)器進行了網(wǎng)卡緩沖區(qū)擴展、關(guān)閉網(wǎng)卡中斷聚合、調(diào)整網(wǎng)卡中斷隊列與綁核后，重傳及零窗現(xiàn)象有了大幅優(yōu)化，重傳率降低至0.1%以下。

在第二階段的調(diào)優(yōu)中，聯(lián)合調(diào)優(yōu)小組通過多個云上系統(tǒng)觀測工具進行了瓶頸點分析并實施了多個針對性調(diào)優(yōu)，使得整體系統(tǒng)性能較調(diào)優(yōu)前有了80%以上提升，但是距離項目整體預(yù)期的性能仍有部分差距。在調(diào)優(yōu)實施中，有所收獲的同時，我們也深刻意識到了不足。面對“分布式+云化+自主研發(fā)適配”這種復(fù)合架構(gòu)改造場景，我們還存在諸如云上工具建設(shè)不足、微服務(wù)改造不徹底、自主研發(fā)軟硬件適配仍處于探索階段等問題。

回顧與總結(jié)

自主研發(fā)軟硬件適配正處于經(jīng)驗積累階段，在實際使用方面距離“開箱即用”還有一定距離。追求高穩(wěn)定性和極致性能的重要應(yīng)用系統(tǒng)在建設(shè)過程中都需要完成相對復(fù)雜的性能調(diào)優(yōu)適配工作，以找到每個系統(tǒng)需要的“最優(yōu)解”。后續(xù)光大銀行也將加強與相關(guān)廠商的合作，針對性滿足應(yīng)用系統(tǒng)“經(jīng)濟型”“均衡型”“穩(wěn)定性”和“性能型”等不同方向的需求，形成運維資源交付與應(yīng)用程序結(jié)合的最佳實踐。

在當前技術(shù)趨勢下，應(yīng)用系統(tǒng)建設(shè)同時面臨基礎(chǔ)設(shè)施云化、架構(gòu)分布式改造、系統(tǒng)軟件自主可控適配、應(yīng)用容器化等一系列挑戰(zhàn)，這都給系統(tǒng)性能的調(diào)優(yōu)造成了一系列不確定變量，將原本相對體系規(guī)范的性能調(diào)優(yōu)工作難度成倍增加。由于涉及從基礎(chǔ)設(shè)施到應(yīng)用程序的多層面配合協(xié)調(diào)，這就需要基礎(chǔ)設(shè)施建設(shè)人員、云平臺建設(shè)者、系統(tǒng)軟硬件工程師、應(yīng)用程序開發(fā)者“多向奔赴”，合作共贏，共同實現(xiàn)系統(tǒng)性能的極致化。

面對復(fù)雜的工作任務(wù)，多層面的人員協(xié)調(diào)，更需要體系化、系統(tǒng)化的工作方法進行情況分析、目標設(shè)定、人員協(xié)調(diào)和任務(wù)統(tǒng)籌。在本次性能調(diào)優(yōu)過程中，無論是分段獲取數(shù)據(jù)的標準測試方法論，還是引入的應(yīng)用日志、網(wǎng)絡(luò)流量和智能運維等工具完成性能情況的獲取都值得在后續(xù)工作中積累推廣。光大銀行也將積極推進相關(guān)工作方法、工具以及流程的積累，盡快形成一套標準高效的性能調(diào)優(yōu)方法論，進一步提升敏捷交付的效率。

關(guān)鍵詞：