高并發(fā)環(huán)境下的MBOSS 系統(tǒng)架構(gòu)優(yōu)化方案

鄧曉蓓

（中國電信廣東公司企業(yè)信息化事業(yè)部，廣東廣州 510081）

0 引言

廣東公司MBOSS 核心系統(tǒng)承載著營業(yè)一線的業(yè)務(wù)受理、服務(wù)開通等關(guān)鍵服務(wù)，系統(tǒng)運行的穩(wěn)定性、高效性直接影響著營業(yè)一線對外服務(wù)的質(zhì)量和效率。由于廣東公司的業(yè)務(wù)量大，特別是每月月底業(yè)務(wù)高峰期，業(yè)務(wù)量比平常時間業(yè)務(wù)量更增漲30%～100%，突增的業(yè)務(wù)量，造成大量并發(fā)的服務(wù)調(diào)用，對MBOSS 核心系統(tǒng)網(wǎng)絡(luò)連接負載造成很大的沖擊，容易造成響應(yīng)延時、服務(wù)排隊等問題。針對此類問題，常規(guī)的解決方案是針對核心系統(tǒng)按業(yè)務(wù)進行分拆，部署到新的系統(tǒng)硬件架構(gòu)上，以提高系統(tǒng)的并發(fā)訪問性能，但需增加大量的硬件設(shè)備投資，實施周期長，對業(yè)務(wù)運行影響大。針對此類高并發(fā)引起的系統(tǒng)延時問題，本文從問題的源頭開展深入分析，全面核查業(yè)務(wù)量的變化情況、應(yīng)用服務(wù)的運行情況、系統(tǒng)平臺的資源情況，并準(zhǔn)確定位各個系統(tǒng)性能瓶頸，制定出高并發(fā)環(huán)境下的IT 架構(gòu)優(yōu)化方案。

1 問題分析

1.1 系統(tǒng)架構(gòu)

按照均衡用戶數(shù)原則，廣東電信MBOSS 核心系統(tǒng)采用分大區(qū)部署模式。每一個大區(qū)的數(shù)據(jù)庫使用兩節(jié)點的Oracle 數(shù)據(jù)庫RAC，為了盡可能避免RAC 實例之間出現(xiàn)過多的數(shù)據(jù)傳輸，采用一部分地市接入RAC 一個節(jié)點，另一部分地市接入RAC 的另外一個節(jié)點的辦法。應(yīng)用節(jié)點包含TUXEDO 和WEBLOGIC 中間件應(yīng)用，按地市應(yīng)用域分別部署，通過千兆以太網(wǎng)絡(luò)連接訪問數(shù)據(jù)庫。應(yīng)用主機及數(shù)據(jù)庫主機集群均部署在同一生產(chǎn)機房內(nèi)。以其中一個大區(qū)為例，系統(tǒng)部署架構(gòu)如圖1所示。

圖1 系統(tǒng)架構(gòu)

我們首先選取了延時問題最為突出的A 大區(qū)地市2 和同一大區(qū)的地市1 進行對比分析。地市2 的業(yè)務(wù)量遠低于地市1，系統(tǒng)架構(gòu)部署和地市1 基本相同。但地市2 在月末出現(xiàn)服務(wù)延時問題極為突出，其中堵塞最為嚴(yán)重的OSQ 服務(wù)，5—7 月共出現(xiàn)121 次堵塞，其中最長一次的堵塞時間長達285min，對營業(yè)一線業(yè)務(wù)受理造成較大的延時影響。而地市1 業(yè)務(wù)量雖然基數(shù)大，但極小出現(xiàn)堵塞問題。

由于此類性能問題影響因素眾多，堵塞出現(xiàn)的時間不確定，難以在測試環(huán)境下重現(xiàn)，因此需要從業(yè)務(wù)量、應(yīng)用部署、數(shù)據(jù)庫、主機、網(wǎng)絡(luò)等層面展開多維度分析，對性能瓶頸進行定位，分析的方法主要包括數(shù)據(jù)比對法和硬件排除法。

1.2 業(yè)務(wù)量分析

由于此類問題一般在月末出現(xiàn)較多，跟月底業(yè)務(wù)量增長存在一定的關(guān)聯(lián)關(guān)系。我們選取了A 大區(qū)的各個分公司的月末業(yè)務(wù)量與平日進行了對比分析，結(jié)果見表1。可見各地市月底的業(yè)務(wù)量增漲20%～100%。其中地市1 平日業(yè)務(wù)量基數(shù)大，月底增幅相對較小，約20%左右，地市2 平日業(yè)務(wù)量基數(shù)小，月底增幅相對較大，超過100%。

表1 各地市業(yè)務(wù)量統(tǒng)計

1.3 應(yīng)用部署分析

地市1 和地市2 的應(yīng)用服務(wù)部署在同型的中端小型機上，由于地市1 業(yè)務(wù)量大，單獨部署在2 臺小型機上，地市2 和地市3、地市4 業(yè)務(wù)量較小，合并部署在另外2 臺小型機上。這四個地市的數(shù)據(jù)庫服務(wù)部署在同一套OracleRAC 數(shù)據(jù)庫上，地市1 單獨部署在RAC 實例節(jié)點1，地市2 和地市3、地市4 以及數(shù)據(jù)交換服務(wù)部署在RAC 實例節(jié)點2。

1.4 主機資源分析

數(shù)據(jù)庫主機和應(yīng)用主機CPU、內(nèi)存資源都比較空閑，基本在80%以內(nèi)。分析情況如圖2 數(shù)據(jù)庫主機CPU使用率和圖3 應(yīng)用主機CPU 使用率所示。

圖2 數(shù)據(jù)庫主機CPU 使用率

圖3 應(yīng)用主機CPU 使用率

1.5 數(shù)據(jù)庫資源分析

從表2 數(shù)據(jù)庫連接數(shù)分析情況可以看到，地市2數(shù)據(jù)庫服務(wù)與多個地市及交換節(jié)點部署在RAC 實例節(jié)點2 上，主機的網(wǎng)絡(luò)連接數(shù)比RAC 實例節(jié)點1 大將近2 倍。

表2 數(shù)據(jù)庫連接數(shù)分析

1.6 網(wǎng)絡(luò)資源分析

地市2 和地市1 應(yīng)用服務(wù)器與數(shù)據(jù)庫服務(wù)器之間的網(wǎng)絡(luò)架構(gòu)基本一致。通過排除法將應(yīng)用服務(wù)器與數(shù)據(jù)庫服務(wù)器之間的主機、網(wǎng)絡(luò)交換機端口逐個進行重啟排除故障，均無發(fā)現(xiàn)硬件問題。通過網(wǎng)絡(luò)監(jiān)控軟件分析如圖4 所示，網(wǎng)絡(luò)流量未超過百兆，未達到網(wǎng)卡最大流量。

圖4 網(wǎng)卡流量分析

1.7 分析結(jié)論

通過大量的性能比對和測試排查工作，排除了部分影響因素，例如主機CPU、內(nèi)存，存儲IO，網(wǎng)絡(luò)帶寬等資源都是相對富余的，同時我們通過關(guān)聯(lián)分析地市2的OSQ 服務(wù)排隊和以下因素關(guān)聯(lián)度非常高的。Ping 延時：服務(wù)排隊期間，從應(yīng)用主機ping 數(shù)據(jù)庫主機存在明顯的延時，服務(wù)排隊期間，應(yīng)用程序執(zhí)行的SQL 語句較為簡單，在數(shù)據(jù)庫端執(zhí)行時間很短，但執(zhí)行頻率非常高。

因此可以得出以下結(jié)論：地市2 數(shù)據(jù)庫服務(wù)與多個地市及交換節(jié)點部署在同一臺主機服務(wù)器上，數(shù)據(jù)庫主機的網(wǎng)絡(luò)連接數(shù)明顯高于其他數(shù)據(jù)庫主機。地市2總體業(yè)務(wù)量不大，但月底業(yè)務(wù)量增幅較大，經(jīng)分析是由于后臺提交批量業(yè)務(wù)較大。此類業(yè)務(wù)會導(dǎo)致應(yīng)用程序頻繁發(fā)起大量的數(shù)據(jù)庫并發(fā)訪問，進而導(dǎo)致出現(xiàn)類似網(wǎng)絡(luò)風(fēng)暴的性能問題，使應(yīng)用服務(wù)器和數(shù)據(jù)庫之間的網(wǎng)絡(luò)訪問出現(xiàn)較為明顯的延時。由于該核心業(yè)務(wù)OSQ需要連接訪問數(shù)據(jù)庫非常頻繁，一旦出現(xiàn)網(wǎng)絡(luò)延時將會明顯影響數(shù)據(jù)處理速度，進而導(dǎo)致嚴(yán)重的業(yè)務(wù)堵塞。

2 優(yōu)化方案

由于此類性能問題特殊性，并不能按照常規(guī)的手段單純靠硬件擴容手段來解決。因此考慮重點從以下三方面著手。

2.1 擴展網(wǎng)絡(luò)并發(fā)連接訪問能力

針對排隊問題最為突出地市2 的OSQ 服務(wù)全面排查，定位到性能瓶頸在于應(yīng)用服務(wù)器到數(shù)據(jù)庫服務(wù)器之間網(wǎng)絡(luò)訪問延時。產(chǎn)生問題的主要原因在于高并發(fā)量的數(shù)據(jù)庫連接訪問。解決此類問題需要從應(yīng)用程序、數(shù)據(jù)庫、主機、網(wǎng)絡(luò)架構(gòu)綜合考慮，增加新的數(shù)據(jù)庫連接通道，從而擴展系統(tǒng)并發(fā)連接訪問能力。

由于此類問題涉及面較廣，目前并無成熟可用的解決方案，通過多次反復(fù)嘗試，創(chuàng)新性使用多通道方案實現(xiàn)數(shù)據(jù)庫訪問連接。

在Oracle 數(shù)據(jù)庫系統(tǒng)架構(gòu)中，通過監(jiān)聽器（LISTENER）管理Oracle 數(shù)據(jù)庫服務(wù)器端與客戶端之間的通信。監(jiān)聽器通常部署在數(shù)據(jù)庫主機對外提供服務(wù)的特定網(wǎng)卡端口上，進行監(jiān)聽連接請求，并將連接轉(zhuǎn)發(fā)給數(shù)據(jù)庫。在常規(guī)的部署方案中，單臺數(shù)據(jù)庫服務(wù)器通過唯一的網(wǎng)卡對外提供連接服務(wù)。而在此案例中的高并發(fā)環(huán)境下，控制網(wǎng)卡連接的部件已成為系統(tǒng)瓶頸之一，因此需進一步增加對外提供服務(wù)的網(wǎng)卡并配置相應(yīng)的數(shù)據(jù)庫監(jiān)聽服務(wù)，具體實現(xiàn)方案如圖5 所示。

圖5 系統(tǒng)架構(gòu)優(yōu)化方案

通過以上創(chuàng)新性的多通道連接方案，能極大地優(yōu)化應(yīng)用服務(wù)與數(shù)據(jù)庫連接效率，分流高并發(fā)的網(wǎng)絡(luò)訪問。

2.2 改造應(yīng)用實現(xiàn)錯峰業(yè)務(wù)處理

通過數(shù)據(jù)分析發(fā)現(xiàn)批量業(yè)務(wù)處理也是導(dǎo)致此類高并發(fā)訪問的關(guān)鍵因素之一，因此通過應(yīng)用程序改造，實現(xiàn)對批量業(yè)務(wù)錯峰處理功能，在日間業(yè)務(wù)高峰期對批量業(yè)務(wù)進行攔截，錯峰安排至夜間業(yè)務(wù)相對空閑的時間進行處理，避免在業(yè)務(wù)高峰期產(chǎn)生高并發(fā)的數(shù)據(jù)連接訪問。

2.3 優(yōu)化SQL 執(zhí)行減少阻塞事件

通過優(yōu)化SQL 語句執(zhí)行計劃，數(shù)據(jù)庫表碎片整理，調(diào)整表分析策略等手段，提高應(yīng)用SQL 語句執(zhí)行效率，避免由于高消耗SQL 造成的阻塞事件。

3 優(yōu)化效果

優(yōu)化方案第一階段首先在分公司2 實施取得明顯效果，其中核心OSQ 服務(wù)處理性能提升5 倍以上，OSQ服務(wù)處理耗時比對如圖6 所示。

圖6 OSQ 服務(wù)處理耗時比對

后續(xù)逐步推廣至全省其他分公司，系統(tǒng)關(guān)鍵性能指標(biāo)也得到了較大的提升。有效解決了月底業(yè)務(wù)高峰期由于高并發(fā)調(diào)用引發(fā)的系統(tǒng)訪問延時問題，改善一線營銷人員的使用感知。且該方案較常規(guī)的硬件擴容方案節(jié)約了數(shù)百萬的硬件設(shè)備投入，對業(yè)務(wù)運行影響非常小。該優(yōu)化方案由于技術(shù)創(chuàng)新、實施效果顯著，獲廣東電信勞動競賽、崗位創(chuàng)新等獎項。