曹劍鋒　張偉

摘要：傳統(tǒng)的電信運營支撐系統(tǒng)在遇到系統(tǒng)性能問題，提升系統(tǒng)效率的時候，一般采用的是多并發(fā)機制來解決效能的不足：（1）擴展硬件配置;（2）增加硬件數(shù)量;（3）增加軟件并發(fā)。通過多并發(fā)機制一定程度上可以提升系統(tǒng)的性能，但會導(dǎo)致硬件設(shè)備無限度的增加，不論從管理維護上還是經(jīng)濟效益上都是不允許的，與企業(yè)降本增效的前提也是相悖的。本研究主要是針對MBOSS中的綜合激活系統(tǒng)為例，借助分布式架構(gòu)解決集中式系統(tǒng)帶來的問題，利用隊列和緩存技術(shù)，提升應(yīng)用的并行接入能力和計算能力，降低高并發(fā)對應(yīng)用和數(shù)據(jù)的IO壓力。根據(jù)設(shè)計的需要把龐大的系統(tǒng)模塊拆分成多個子功能模塊，把一個整體的功能模塊或者事務(wù)劃分成不同的子功能模塊獨立部署，異步通信，以達(dá)到提高系統(tǒng)效率的目的。

關(guān)鍵詞：分布式;隊列;緩存

中圖分類號：TP311.13 文獻標(biāo)識碼：A 文章編號：1007-9416（2019）05-0180-02

1 關(guān)鍵技術(shù)方案分析與設(shè)計

根據(jù)調(diào)研的情況，當(dāng)前IT系統(tǒng)均部署在Weblogic中間件上，采用Oracle數(shù)據(jù)庫，是典型的三層IOE架構(gòu)，系統(tǒng)的擴展性取決于數(shù)據(jù)庫的性能及Weblogic的擴展性。

為了解決傳統(tǒng)三層IOE架構(gòu)存在的問題，也是其典型的特點：軟件系統(tǒng)龐大復(fù)雜，擴展節(jié)點資源浪費嚴(yán)重，系統(tǒng)變更難度大;硬件配置要求高，基本都是小型機，財務(wù)成本高;集中架構(gòu)受限于IO能力，性能無法大幅提升。我們提出了具體的設(shè)計思路：（1）利用隊列和緩存技術(shù)，提升應(yīng)用的并行接入能力和計算能力，降低高并發(fā)時，對應(yīng)用和數(shù)據(jù)的IO壓力。（2）針對業(yè)務(wù)量高峰期，應(yīng)用優(yōu)先級、核心/非核心網(wǎng)元分離、隊列水平擴展等方案，解決業(yè)務(wù)擁塞問題。最終提出流水式業(yè)務(wù)調(diào)度功能架構(gòu)，實現(xiàn)系統(tǒng)高性能的處理方式：

（1）流程引擎與規(guī)則引擎緊密結(jié)合，使用自然的語言定義流程流向，靈活配置。（2）交互采用異步操作方式，提高系統(tǒng)響應(yīng)速度。（3）引擎內(nèi)部對頻繁訪問的熱表，采用內(nèi)存表的技術(shù)，固化到內(nèi)存中，極大提高流程引擎的處理速度。（4）引擎內(nèi)部引用緩存隊列，緩存流程數(shù)據(jù)，提高系統(tǒng)性能。

2 業(yè)務(wù)隊列調(diào)度方案設(shè)計

2.1 隊列設(shè)計

系統(tǒng)基于內(nèi)存數(shù)據(jù)庫設(shè)計相應(yīng)的隊列機制。主要包括以下兩方面：

（1）基于網(wǎng)元建立隊列。針對不同的業(yè)務(wù)網(wǎng)元，需要建立不同的調(diào)度隊列，簡化了隊列的設(shè)計復(fù)雜度，將網(wǎng)元任務(wù)隔離開，屏蔽了不同任務(wù)的互相影響。在調(diào)度模塊處理時，可針對不同網(wǎng)元，部署多個模塊，以水平擴展應(yīng)對業(yè)務(wù)量的不斷增長。（2）取模調(diào)度原則。應(yīng)對關(guān)系型內(nèi)存數(shù)據(jù)庫時，對于接口表的處理，采用關(guān)鍵字段取模的方式，多個處理模塊可掃描同一個接口表，互不影響。

2.2 多網(wǎng)元順序控制

系統(tǒng)需要對接多個不同的網(wǎng)元，這就存在網(wǎng)元的執(zhí)行依賴關(guān)系。系統(tǒng)以預(yù)配置的方式，針對不同業(yè)務(wù)場景，對網(wǎng)元的先后順序進行相應(yīng)編排，并將該映射關(guān)系緩存至內(nèi)存中。緩存機制基于以下原則，首次接收業(yè)務(wù)請求時，將通過數(shù)據(jù)庫查詢依賴關(guān)系，并緩存至內(nèi)存，后續(xù)處理相同業(yè)務(wù)時，則直接從緩存中獲取配置信息，減少IO交互，提升處理效率。

2.3 隊列優(yōu)先級

隊列處理機制提供兩種方式，先進先出和優(yōu)先級隊列。針對某些特定場景的業(yè)務(wù)，需要提供較高優(yōu)先級以獲得更快速地處理。系統(tǒng)針對不同場景，設(shè)計輕量化的優(yōu)先級隊列，為不同網(wǎng)元提供不同隊列通道，以簡化隊列需求場景，滿足優(yōu)先級施工要求。

2.4 消息擁塞處理機制

隨著運營業(yè)務(wù)的不斷發(fā)展，系統(tǒng)需承受倍數(shù)增長的用戶請求，若保持當(dāng)前軟硬件水平，終會達(dá)到極限承受點，進而造成業(yè)務(wù)擁塞。因此，系統(tǒng)在設(shè)計期間，充分考慮了水平擴展功能，以支撐大并發(fā)量的交易訪問。

基于分布式組件化設(shè)計，系統(tǒng)應(yīng)用模塊設(shè)計采用進程分布劃小原則實現(xiàn)，每個模塊進程實現(xiàn)支撐業(yè)務(wù)處理過程中的一環(huán)，避免集中式的模塊處理，在運行計算過程中，由于操作系統(tǒng)或JVM的線程調(diào)度競爭機制限制了模塊的計算能力，無法充分利用應(yīng)用服務(wù)器的CPU、內(nèi)存和IO資源。

2.5 核心/非核心網(wǎng)元分離

在實際業(yè)務(wù)中，部分網(wǎng)元的執(zhí)行結(jié)果并不影響整體業(yè)務(wù)的成功與否，因此需要制定相應(yīng)的容錯機制，以屏蔽這些網(wǎng)元執(zhí)行失敗帶來的影響。對于非核心網(wǎng)元，系統(tǒng)將自動識別，無需等待該類型網(wǎng)元施工完畢，即可認(rèn)為整個工單業(yè)務(wù)施工完成，極大地加快了業(yè)務(wù)開通能力。

3 系統(tǒng)派單調(diào)度方案設(shè)計

系統(tǒng)拆分為小的功能性模塊后，最關(guān)鍵的問題是模塊間派單及消息通信的問題，需要對派單調(diào)度實現(xiàn)以下關(guān)鍵功能：

3.1 內(nèi)存調(diào)度

消息通過內(nèi)存進行調(diào)度，包括兩方面，內(nèi)存數(shù)據(jù)庫和jvm內(nèi)存。

利用內(nèi)存數(shù)據(jù)庫隊列緩沖接口消息，避免消息直接落地，影響接口的交互性能，處理模塊可異步掃描隊列進行后續(xù)處理。同時內(nèi)存中消息報文成為中心共享數(shù)據(jù)，計算處理模塊通過訪問緩沖的消息數(shù)據(jù)，完成計算處理，節(jié)省磁盤IO開銷，提升性能。

利用內(nèi)存數(shù)據(jù)庫隊列交互模塊數(shù)據(jù)，上下游模塊直接通過內(nèi)存讀寫，極大地提升了處理能力。

采用線程并發(fā)模式，在jvm基礎(chǔ)上實現(xiàn)多隊列，多線程處理，針對接口、模塊間消息分配jvm內(nèi)存隊列，以實現(xiàn)派單隊列的二級緩沖，加快數(shù)據(jù)流轉(zhuǎn)。

3.2 進程守護

在分布式架構(gòu)的前提下，各處理單元通常是獨立的進程，在調(diào)度隊列時，需要保證調(diào)度操作的原子性，即同一個消息，不會被重復(fù)多次調(diào)度。采用守護進程的方式，結(jié)合應(yīng)用的冷備模式，確保處理單元的持續(xù)工作能力。即通過一個守護進程，定期發(fā)起對守護對象的檢查，監(jiān)聽進程PID信息判斷進程是否存活，可以根據(jù)配置策略，對存活進程發(fā)起自動拉起，或者發(fā)送短信通知到系統(tǒng)管理員，對進程進行手工重啟。

4 緩存及異步持久化方案設(shè)計

系統(tǒng)高性能實現(xiàn)的設(shè)計原則為“一次計算，異步持久”，計算過程通過分布式應(yīng)用部署，最大化利用CPU、內(nèi)存和網(wǎng)絡(luò)IO資源完成高并發(fā)處理，利用消息管道，銜接關(guān)系型數(shù)據(jù)、內(nèi)存數(shù)據(jù)庫和文件化持久操作，實現(xiàn)IO異步化。

基于以上原則實現(xiàn)的高性能系統(tǒng)，要實現(xiàn)以下關(guān)鍵功能：可根據(jù)需要選擇落入大數(shù)據(jù)平臺或轉(zhuǎn)存到集中的文件服務(wù)器當(dāng)中。

4.1 利用內(nèi)存數(shù)據(jù)庫緩沖報文消息

利用內(nèi)存數(shù)據(jù)庫緩沖接口消息，避免消息直接落地，影響接口的交互性能;

讓消息報文成為中心共享數(shù)據(jù)，計算處理模塊通過訪問緩沖的消息數(shù)據(jù)，完成計算處理，節(jié)省磁盤IO開銷，提升性能。

4.2 配置緩存，降低IO交互

應(yīng)用啟動過程加載配置數(shù)據(jù)，緩存在進程內(nèi)部，有效降低計算過程中配置數(shù)據(jù)在數(shù)據(jù)庫中的訪問調(diào)用，減少應(yīng)用和數(shù)據(jù)庫的交互次數(shù)，提升系統(tǒng)的處理能力。

4.3 嵌入式隊列，保障持久高性能

計算過程結(jié)束后，消息對象避免經(jīng)網(wǎng)絡(luò)IO傳遞到其它模塊完成持久，實現(xiàn)嵌入式隊列，由計算模塊中的持久線程池完成消息處理，持久對象落地數(shù)據(jù)庫或者文件系統(tǒng)。

4.4 文件化系統(tǒng)處理大消息持久

利用文件系統(tǒng)的IO能力，應(yīng)用程序通過隊列異步本地存儲大報文消息，避免大消息落入關(guān)系型數(shù)據(jù)庫，存放成LOB結(jié)構(gòu)，可有效降低數(shù)據(jù)庫開銷，充分利用系統(tǒng)的整體資源。

5 流水線結(jié)構(gòu)在即時開通激活系統(tǒng)的應(yīng)用情況

去IOE架構(gòu)的即時開通激活系統(tǒng)，整體設(shè)計借鑒了互聯(lián)網(wǎng)高并發(fā)高性能高擴展的設(shè)計思想，應(yīng)用了業(yè)界成熟的開源解決方案，拋棄了傳統(tǒng)重型的EJB架構(gòu)設(shè)計，改用輕量級多進程集群，運行在X86架構(gòu)虛擬資源池上，歷史歸檔和過程數(shù)據(jù)分離，過程數(shù)據(jù)分功能存儲于Oracle（支持MYSQL集群），采用分布式緩存、異步IO和事件驅(qū)動等技術(shù)大幅提升性能。

在新架構(gòu)中，我們引入了分布式緩存REDIS技術(shù)，每個REDIS實例均有主備節(jié)點，確保緩存數(shù)據(jù)的安全性，不僅存儲配置數(shù)據(jù)，還存儲工單處理過程數(shù)據(jù)。在激活的多進程架構(gòu)下，這些緩存中的過程數(shù)據(jù)可以跨進程共享，大大降低了生產(chǎn)數(shù)據(jù)庫的IO消耗。

在新架構(gòu)中，我們借助REDIS內(nèi)存數(shù)據(jù)庫，將進程通知消息寫入內(nèi)存隊列中，消費進程異步讀取，隊列性能較傳統(tǒng)JMS和數(shù)據(jù)庫表都提升了一個等級，消息在隊列中透明可控，維護成本也大大降低。

新架構(gòu)的即時開通激活上線應(yīng)用后，效果明顯：采用云化部署，效率高、容災(zāi)能力強;工單處理速率高，比原系統(tǒng)提高10倍;表空間使用少，比原系統(tǒng)節(jié)約空間綜合約7倍。