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

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

(資料圖片僅供參考)

環(huán)境介紹

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

1.基礎設施層部署模型介紹

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

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

2.業(yè)務模型

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

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

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

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

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

通用調優(yōu)

整體調優(yōu)工作分為兩個階段。第一階段旨在梳理業(yè)務模型，確立調優(yōu)思路，并分別對云網、數(shù)據庫及系統(tǒng)環(huán)境進行普適性調優(yōu)。我行各技術領域專家均參與到調優(yōu)過程中，通過網絡模型優(yōu)化、數(shù)據庫對象及環(huán)境優(yōu)化等手段，使基礎組件及設施更適合分布式架構，充分發(fā)揮分布式架構的優(yōu)勢。

1.云網篇

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

圖3 全棧云網絡物理部署圖

2.數(shù)據庫篇

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

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

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

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

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

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

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

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

分段時延獲取、

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

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

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

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

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

緩存優(yōu)化：

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

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

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

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

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

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

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

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

圖5 裸金屬網絡調優(yōu)前ping測試數(shù)據

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

圖6 裸金屬網絡調優(yōu)后ping測試數(shù)據

overlay層數(shù)據包分析

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

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

圖7 利用云網可視化工具定位網絡問題

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

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

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

回顧與總結

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

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

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

關鍵詞：