本站小編為你精心準備了銀行集群架構非功能測試創新實踐參考范文，愿這些范文能點燃您思維的火花，激發您的寫作靈感。歡迎深入閱讀并收藏。

隨著中國光大銀行（以下簡稱“光大銀行”）打造“一流財富銀行”的戰略目標深入落地，高并發、高吞吐量的應用系統越來越多，具備彈性擴展能力的大規模集群化系統也相應增多。動輒幾十臺數量的大規模集群，不僅給開發、運維帶來巨大壓力，同時也對非功能測試提出了更高的要求。本文以光大銀行某系統非功能測試項目為例，闡述在大規模集群項目中實施非功能測試時面臨的挑戰和應對方法。

一、項目背景

光大銀行某系統因數據庫服務器容量出現瓶頸，無法滿足業務增長需要，需通過對數據庫服務器擴容升級以更好地支持業務發展。為此，根據光大銀行管理要求，項目組提出非功能測試需求，需要通過非功能測試驗證升級后的系統容量，以保障擴容效果和生產安全。

二、項目特點

1.系統架構系統架構通過多層負載均衡，實現快速橫向擴展能力，架構節點包括外部接入層、接入主控層、路由層和應用層等，各節點層均可橫向擴容。數據庫服務器采用主備模式，單點提供服務，不具備橫向擴展能力。系統物理架構如圖1所示。2.傳統測試方案本次測試驗證的主要目的是驗證升級后系統的最大容量。傳統的測試方法有以下三個步驟：（1）部署與生產環境一致的測試環境，包括服務器數量、網絡環境以及服務器的主要配置如CPU/內存、存儲和數據等。（2）考慮到生產節點部署不是一步到位，因此會增加擴展性驗證，即獲取單臺服務器容量后，逐步增加服務器數量，驗證擴展能力（線性程度）。（3）加大壓力，直至獲取到數據庫的容量拐點，因數據庫一般不可橫向擴展，因此獲取到數據庫容量拐點即意味著獲取到應用系統的最大容量。以上測試方法針對的是服務器數量在10臺以內的傳統架構，測試環境的準備和測試驗證過程，風險都相對可控，但當前該系統采用的是集群架構，服務器設備達到50臺左右，CPU總核數達到400C，量變會產生質變，面對新的情況，如果仍然按照傳統測試方法則會面臨一系列的問題和挑戰。3.困難和挑戰由于架構變化和集群規模的擴大，非功能測試實施過程中產生了很多新問題、新挑戰，主要體現在以下四個方面：（1）一個系統幾十臺設備，常備測試環境無法滿足要求，需要運維設備團隊協調資源，但如此大規模的資源調配，其難度可想而知。（2）系統使用的服務器中，除數據庫外，基本都是光大銀行私有云虛擬機，測試環境申請到的虛擬機無法保證與生產設備型號完全一致，甚至會差異較大，對性能有明顯影響。同時，由于私有云特性，CPU和內存等基礎資源會根據運行時狀態進行動態調整，測試環境中虛擬機之間資源爭用往往不期而至，測試結果分析面臨很大困難。（3）數據庫資源配置較高，有限的測試資源無法支撐獲取最大容量的要求。如果要獲取數據庫最大容量，則測試工作量巨大，測試周期無法保證，對項目建設目標造成重大影響。（4）由于設備數量較多，測試場景復雜，測試過程需要開發配合的事項也會比較多，對于本已經較為緊張的項目周期來說是一個較重的負擔。

三、創新實踐

“思則變，變則通，通則達”，面對測試資源不足的客觀條件，光大銀行嘗試轉變測試思路和方法，另辟蹊徑，規避上述難題。首先，對系統架構特點進行仔細分析。本次變更業務服務器（含接入、網關和應用）未做調整，生產運行相對穩定，而業務服務器出現瓶頸時，均可以通過橫向擴展提高平臺處理能力。進一步分析可以發現，接入層和網關層資源消耗都較低，容量風險很小，因此重點關注應用服務器擴展能力即可。從整個系統架構來看，數據庫不能橫向擴展，也就是數據庫的處理能力決定了系統的最大處理能力。其次，結合理論和歷史實踐，若數據分布和索引相對合理，數據庫服務器CPU使用率不超過60%時，數據庫處理能力應該呈線性增長。而各業務處理層相對穩定，基于負載均衡集群架構，橫向擴展能力理論上也接近線性。最后，由于業務發展具有不確定性，我們希望本次測試交付的數據不僅是一個靜態的容量數據，最好能提供動態的擴展配置表，運維可以根據配置表，針對不同的業務發展調整合理的資源配置。基于以上分析和考慮，新的測試方案確定如下：（1）準備少量與生產配置相同的應用服務器，驗證應用擴展趨勢以及數據庫資源消耗趨勢。（2）準備盡可能多的應用服務器資源（不要求與生產配置一致，應用服務器資源消耗不作為考察點），盡可能地對數據庫施壓，獲取一組實測的數據庫容量數據，提供給運維作為預警參考。（3）通過線性回歸分析工具，對測試結果進行回歸分析，并預測隨著業務發展，應用服務器資源配置和數據庫資源消耗情況。以上方案在與開發和運維的溝通中獲得了理解和認可，我們著手開展測試執行。

四、結果驗證

按照新方案，本次測試協調了5臺與生產匹配的應用服務器資源，同時準備了一些異構的應用服務器，測試結果說明如下。1.橫向擴展驗證應用層共驗證了5個點，按1-2-3-4-5臺擴展，獲取不同應用服務器數量對應的TPS和數據庫服務器CPU使用率。橫向擴展實測驗證結果見表1。2.數據庫容量驗證通過異構應用服務器資源，最終實測驗證的數據庫容量峰值為4456筆/秒，對應的DB-CPU使用率為16.2%。3.容量預測根據橫向擴展驗證的結果，分別從TPS應用服務器數量和TPS數據庫CPU使用率兩個維度進行線性回歸擬合。處理能力與應用服務器數量擬合效果如圖2所示。處理能力與數據庫CPU使用率擬合效果如圖3所示。從擬合結果看，R2達到0.995以上，擬合效果比較理想。根據擬合結果，我們獲得了兩個線性關系公式，一個是處理能力與應用服務器的線性公式y=203.2x1.009,另一個是處理能力與數據庫CPU使用率的線性公式y=36150x1.126。根據這兩個公式，我們可以進一步獲取更多的預測數據，如圖4所示，可以看到預測數據和實測結果吻合度還是比較高的。至此，我們本次的測試目的全部達到，而且為運維交付了更為詳細的動態容量數據，可以更好地指導生產運維。容量擴展預測數據見圖5。

五、項目總結

1.方法論說明針對本次測試采用的測試方法，為了方便說明和推廣，我們將該方法命名為“驗證預測法”，為了更好地理解，對該方法進一步解釋如下：（1）驗證點1的目的是獲取處理能力與資源配置的相關性趨勢，需要硬件配置（CPU、內存等）盡可能與生產接近一致，需要獲取多組數據（建議不少于5組），是預測的基礎。（2）驗證點2的目的是獲取一組在最大測試環境下能達到的實測容量，為運維提供預警參考，改組數據對應用服務器資源配置要求比較寬松，主要是為了盡可能給數據庫施壓。（3）根據驗證點1的結果進行回歸擬合，對預測圖4容量測試驗證測試法示意區1和預測區2的數據進行預測，為運維提供參考，同時通過驗證點2對預測數據和實測數據進行對比，了解預測數據可信度。2.價值和收益驗證預測法在應對大規模集群架構的容量測試中具有明顯的優勢。一是能夠有效規避傳統測試方法對測試資源過度依賴的痛點，利用較少的資源達成測試目標，大大降低了環境準備成本，縮短測試周期。二是可以提供動態容量數據，更有效地指導生產。運維可以通過查詢預測數據表，根據業務發展情況動態配置服務器資源，既能通過擴容來快速應對業務高峰，又能在業務低谷時合理釋放冗余資源，做到高效節約配置資源。3.局限性由于是實測驗證和預測相結合，圖5中驗證點2以下囊括的區域基本是可信的，驗證點2之外即預測區2的數據，由于數據的不斷積累和更新，有可能存在數據熱點、索引失效和sequence不足等引發的容量問題，須謹慎使用。有條件的情況下可以在預測區2中增加驗證點進行驗證。當前銀行科技發展迅猛，各種新技術、新架構不斷出現，給非功能測試帶來諸多挑戰，如果僅按照傳統的測試方法去思考，很多問題將很棘手且難以解決，而換一種思路或許能夠取得意想不到的效果。

作者：田淵文 雷宏波 單位：中國光大銀行信息科技部