<bdo id="ks4iu"><del id="ks4iu"></del></bdo>
  • 
    <pre id="ks4iu"></pre>
  • <bdo id="ks4iu"><del id="ks4iu"></del></bdo>
    <input id="ks4iu"><em id="ks4iu"></em></input>
    
    
  • <center id="ks4iu"><cite id="ks4iu"></cite></center>
  • 首頁 > 空調 >

    實戰 | 淺談分布式系統的性能調優

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

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

    環境介紹

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


    (資料圖片僅供參考)

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

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

    圖1 某大型分布式業務系統架構圖

    2.業務模型

    為了驗證分布式架構對高并發場景下的支撐能力,本次調優特意選取了對高并發要求較高的聯機交易類系統。

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

    業務請求經GW服務調用DP服務接口識別業務類型,并根據業務邏輯在各微服務和數據庫間流轉。該系統需要在內部高頻遠程過程調用的情況下,保證聯機交易低時延高并發的需求。

    圖2 某大型分布式業務系統業務模型圖

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

    通用調優

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

    1.云網篇

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

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

    2.數據庫篇

    從傳統集中式數據庫遷移至分布式數據庫面臨很大的困難挑戰,需要充分發揮分布式數據庫海量數據、高并發的性能優勢,同時也要避免架構由集中式轉變為分布式帶來的缺點與不足,為此我們進行了如下的優化措施。

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

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

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

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

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

    針對性能瓶頸的專項調優

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

    分段時延獲取、

    瓶頸點定位與針對性調優

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

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

    分析發現,單筆交易的時間開銷主要來自于應用內部的數據處理、數據庫的事務處理和微服務間RPC。為此,我們進行了針對性調優。

    1.在業務層,主要進行了緩存優化、批量優化和通訊優化

    緩存優化:

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

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

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

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

    底層通訊優化:在內部服務高頻交互的場景下,將服務間的通訊協議由http協議改成了基于socket長連接的bolt協議,減少了通訊的損耗。

    2.在數據庫方向,主要從事務和裸金屬網絡兩個方面進行了優化

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

    裸金屬網絡優化:由于分布式數據庫涉及多節點間的通信協調,在網絡鏈路上的開銷遠高于集中式數據庫,為此我行全棧云專家也針對分布式數據庫內部網絡進行了專項調優。

    圖5 裸金屬網絡調優前ping測試數據

    我們為每一臺裸金屬節點新增了一個私網地址,專門用于裸金屬節點之間的互通,并對數據庫內部網絡的流量模型和通信矩陣進行調整,使得裸金屬內部通信可以通過Leaf交換機直接轉發的方式實現路徑最簡的高速網絡,平均ping延時由130us下降到了80us,性能大幅提升。

    圖6 裸金屬網絡調優后ping測試數據

    overlay層數據包分析

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

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

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

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

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

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

    回顧與總結

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

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

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

    責任編輯:Rex_21

    關鍵詞:
    推薦閱讀

    李興浩涉案 志高空調渡劫

    · 2023-08-21 15:12:03
    欧美国产在线一区,免费看成年视频网页,国产亚洲福利精品一区,亚洲一区二区约美女探花
    <bdo id="ks4iu"><del id="ks4iu"></del></bdo>
  • 
    <pre id="ks4iu"></pre>
  • <bdo id="ks4iu"><del id="ks4iu"></del></bdo>
    <input id="ks4iu"><em id="ks4iu"></em></input>
    
    
  • <center id="ks4iu"><cite id="ks4iu"></cite></center>
  • 主站蜘蛛池模板: 秀婷和程仪全集| 3d动漫精品一区二区三区| 精品熟女少妇av免费久久| 日本xxxxx高清视频| 国产婷婷一区二区三区| 久久青青草视频| 黑人巨大videos极度另类| 欧美一区2区三区4区公司贰佰| 国产精品午夜爆乳美女视频| 亚洲日产综合欧美一区二区 | **aaaaa毛片免费同男同女| 欧美日本在线观看| 国产精品亚洲欧美云霸高清| 亚洲国产欧美日韩精品一区二区三区| 2019天堂精品视频在线观看| 欧美国产日韩a在线视频| 国产精品亲子乱子伦xxxx裸| 亚洲av综合色区无码一区爱av| 国产性夜夜春夜夜爽三级| 日韩人妻精品一区二区三区视频 | 欧美婷婷六月丁香综合色| 国产精品久久99| 哇嘎在线观看电影| 一级一级毛片免费播放| 看一级毛片**直播在线| 在线观看国产精美视频| 亚洲成av人片在线观看无码不卡 | 男女搞基视频软件| 在线播放中文字幕| 亚洲天堂一区在线| 精品四虎免费观看国产高清午夜| 日韩中文字幕视频| 四虎国产精品免费久久影院| 一级做a爰片性色毛片视频图片| 色偷偷人人澡久久天天| 成人免费观看网站| 人人看人人添人人谢| va亚洲va欧美va国产综合| 激情综合婷婷色五月蜜桃| 国产精品亚洲一区二区三区| 久久国产热视频|