張巍

摘要：目前實時消息的服務能力業(yè)務種類增加，業(yè)務量大幅提升，對各相關系統(tǒng)的要求不斷提高。在系統(tǒng)硬件有限的情況下，一旦短時業(yè)務量峰值超負荷或者某業(yè)務節(jié)點異常，容易引發(fā)雪崩效應，導致業(yè)務流程整體不可用且難以恢復。經(jīng)過研究分析，我們提出了一系列方法來提升實時消息服務能力和恢復：各系統(tǒng)接口具備消息隊列蓄水能力；增加超時消息預判和下游截斷功能；對關鍵系統(tǒng)設置復制庫等。這方法在很大程度上提升消息服務能力，減少了異常狀況的影響，便于快速維護，快速定位問題，同時避免影響用戶感知和對周邊系統(tǒng)造成壓力。

關鍵詞： 實時消息；服務能力提升；超時預判；復制數(shù)據(jù)

中圖分類號：F626.11 文獻標識碼：A 文章編號：1672-9129（2018）07-0015-02

Abstract： at present， the service capacity of real-time information is increasing， the business volume is greatly improved， and the requirements of all related systems are constantly improved. In the case of limited system hardware， it is easy to cause the avalanche effect once the peak load of short-term business volume or abnormal business node can cause the whole business process to be unusable and difficult to recover. Through research and analysis， we propose a series of methods to improve the capability and recovery of real-time message service. Increase timeout message anticipation and downstream truncation function； Set up replication libraries for key systems. This method to a large extent promote message service ability， reduce the influence of abnormal conditions， to facilitate rapid maintenance， rapid positioning problem， at the same time to avoid impact the user awareness and pressure on surrounding system.

Key words： real-time information； Service enhancement； Overtime pre-judgment； Copy the data

緒論

中國電信作為一家全網(wǎng)全業(yè)務運營的綜合性運營商，與中國移動、中國聯(lián)通三足鼎立。隨著移動互聯(lián)網(wǎng)業(yè)務的發(fā)展，新型態(tài)支付、電子商務等更多新業(yè)務的逐漸成熟，中國電信上海公司建立了計費運營網(wǎng)（Billing Operation Network，下面簡稱BON），整合全網(wǎng)各網(wǎng)元的業(yè)務能力，對外提供統(tǒng)一接入及標準化服務能力，為新業(yè)務的發(fā)展打下基礎。

1 實時消息流程現(xiàn)狀分析

1.1 實時消息處理流程

實時消息按照指定的業(yè)務流程在新BON網(wǎng)的各個網(wǎng)元之間流轉(zhuǎn)。網(wǎng)元按照不同的功能分為：數(shù)據(jù)網(wǎng)元，是計費網(wǎng)元中主要提供公共 數(shù)據(jù)訪問、變更及同步等數(shù)據(jù)業(yè)務能力的網(wǎng)元；業(yè)務網(wǎng)元，是BON中提供各種應用類業(yè)務能力的網(wǎng)元；控制網(wǎng)元，負責BON的安全、路由、消息轉(zhuǎn)發(fā)、全網(wǎng)配置管理等。Subscriber Server，以下簡稱HSS）的用戶資料下發(fā)為例，消息會在全國中心HSS、全國中心的業(yè)務路由（Service Router，以下簡稱SR）、省SR、省HSS之間流轉(zhuǎn)，（Credit-Control-Request，以下簡稱CCR）消息至下游網(wǎng)元，等待下游系統(tǒng)返回信用控制應答（Credit-Control-Answer，以下簡稱CCA）消息。超過閾值時間仍未收到，則判定為超時；正常收到，則解析消息內(nèi)容，根據(jù)返回的結(jié)果碼正?；虍惓＿M行不同的后續(xù)業(yè)務處理。對于中間網(wǎng)元（上例中為全國中心SR和省SR），監(jiān)聽到上游發(fā)來的CCR消息后，根據(jù)業(yè)務邏輯判斷下游網(wǎng)元，并向下游轉(zhuǎn)發(fā)CCR消息。超過閾值時間未收到CCA消息，則判定為超時，向上游返回標識下游系統(tǒng)超時的CCA消息；正常收到CCA消息則轉(zhuǎn)發(fā)收到的CCA消息。對于接收方（上例中為省HSS），監(jiān)聽到上游發(fā)來的CCR消息后，進行驗證、解密、業(yè)務處理等工作，根據(jù)業(yè)務處理結(jié)果，生成處理結(jié)果、業(yè)務代碼等，組成CCA消息，并進行加密、簽名等工作，再將CCA發(fā)送至上游網(wǎng)元。

1.2 目前實時消息處理碰到的問題及分析

目前在實時消息處理的運營過程中，發(fā)現(xiàn)存在如下一些問題：

1.2.1 業(yè)務網(wǎng)元由于升級、維護等原因需要在升級窗口進行停機。在停機期間查詢等各類服務中斷較多，無法轉(zhuǎn)發(fā)消息或處理業(yè)務，很大程度上影響了用戶感知。

1.2.2 各業(yè)務網(wǎng)元采用簡單的單隊列方式進行串行消息調(diào)度，消息調(diào)度水平不足，消息處理效率低，擴展性、靈活性差，并容易產(chǎn)生積壓、堵塞等問題。一旦當前消息發(fā)生超時等異常情況，唯一隊列里的后續(xù)消息會越積越多，最終導致隊列溢出，系統(tǒng)異常。

1.2.3 消息超時判斷機制簡單。目前網(wǎng)元的消息超時判斷僅僅是在發(fā)出CCR消息后，等待下游返回CCA消息時判斷消息是否超時。由于業(yè)務流程和處理的復雜性，通常該超時閾值也設置的較長。這導致一條超時消息會大幅消耗系統(tǒng)資源，且所有上游網(wǎng)元的系統(tǒng)資源都會被占用受影響，批量的超時消息很容隱引發(fā)雪崩效應。

上述問題都曾引起過單個或者多個系統(tǒng)的異常?！耙稽c接入、服務全網(wǎng)”的移動互聯(lián)網(wǎng)跨地域業(yè)務需求，要求BON對外提供穩(wěn)定、可靠、高效的能力封裝調(diào)用，因此實時消息服務能力必須進一步的提升。

2 實時消息服務能力提升方法分析研究

根據(jù)對現(xiàn)狀和問題的分析，我們提出從以下幾個方面來實現(xiàn)實時消息服務能力的提升：

2.1 業(yè)務網(wǎng)元永遠在線

各個業(yè)務網(wǎng)元都不可避免的會有升級、系統(tǒng)異常等，按照系統(tǒng)現(xiàn)狀，類似情況下必然會導致系統(tǒng)不可用。針對此，我們提出網(wǎng)元永遠在線的思路，解決這一問題。而要實現(xiàn)永遠在線，主要需要實現(xiàn)以下兩方面：

2.1.1 數(shù)據(jù)庫永遠在線。查詢類消息、業(yè)務操作類消息的主要目的分別是獲取數(shù)據(jù)、更新數(shù)據(jù)。而目前各個系統(tǒng)的數(shù)據(jù)都是存在數(shù)據(jù)庫內(nèi)的，因此數(shù)據(jù)庫永遠在線是業(yè)務網(wǎng)元永遠在線須首要實現(xiàn)的。用復制庫的方法可實現(xiàn)原數(shù)據(jù)庫不可用時的數(shù)據(jù)庫永遠在線。復制庫的實現(xiàn)可基于Oracle GoldenGate（OGG）技術建立復制庫，復制庫數(shù)據(jù)從原有數(shù)據(jù)庫進行“1比1”復制。各應用程序添加復制庫以及生產(chǎn)庫鏈接配置，只需修改配置，通過腳本實現(xiàn)一鍵切換生產(chǎn)以及復制庫，保證對外無感知。

2.1.2 應用永遠在線。在數(shù)據(jù)庫永遠在線的基礎上，就可實現(xiàn)應用永遠在線。各個網(wǎng)元情況不同，需要根據(jù)各自的情況進行改進來以支持應用永遠在線。如：主、備機結(jié)構(gòu)，當異常時從主機HA等方式切換到備機；多機負載均衡，當其中一臺主機升級或異常時，將該臺主機的業(yè)務配比修改為0，使業(yè)務消息不轉(zhuǎn)發(fā)到該臺主機；系統(tǒng)云化，基于云平臺統(tǒng)一調(diào)度各個集群，任何一臺業(yè)務集群故障，不影響后續(xù)業(yè)務處理，且在系統(tǒng)升級時可實現(xiàn)按批次灰度發(fā)布。另外為實現(xiàn)數(shù)據(jù)庫永遠在線，應用除了自身永遠在線外，還需具備快速主備動切換到數(shù)據(jù)庫復制庫的能力。

業(yè)務網(wǎng)元永遠在線可以有效避免系統(tǒng)升級、異常等內(nèi)部原因?qū)е碌耐耆豢捎茫似陂g還是可能導致處理性能下降。因此系統(tǒng)升級仍應選擇凌晨等系統(tǒng)閑時，而發(fā)生異常時也需盡可能快的修復，及時恢復系統(tǒng)至最大處理能力。

2.2 業(yè)務網(wǎng)元消息隊列優(yōu)化

目前各業(yè)務網(wǎng)元采用簡單的單一隊列方式進行串行消息調(diào)度，很容易在性能不足或下游異常等情況時發(fā)生堵塞、擠壓，進而導致整個網(wǎng)元不可用性。對于網(wǎng)元內(nèi)部消息隊列的優(yōu)化，可以從隊列的數(shù)量、隊列蓄水能力和高低水動態(tài)擴展等方面進行。

除了數(shù)量，還可為消息隊列增加蓄水能力。當上游消息到達時不超過隊列深度，則接收該消息繼續(xù)處理；如果上游消息到達時超過隊列深度，立刻返回系統(tǒng)錯誤，不再向下游發(fā)送消息，或者丟棄。錯誤或被丟棄消息的業(yè)務會被發(fā)起方回滾或者一定時間后重試。消息隊列作為消息池的蓄水能力，可平衡消息到達高峰期與非高峰期的消息處理能力，形成錯峰，緩解消息到達高峰期的消息處理壓力。

在多消息隊列基礎上，還可新增隊列高低水可動態(tài)擴展功能進行優(yōu)化。業(yè)務網(wǎng)元的系統(tǒng)消息處理量隨時間是一個存在很多個波峰波谷的隨機過程，在消息高峰期需要加大業(yè)務處理模塊的處理能力，而在波谷期則可以適當減少處理能力，將處理資源適量釋放用于處理節(jié)點中的其他業(yè)務的處理。具體步驟如下：

系統(tǒng)增加高低水監(jiān)控線程，對CPU、內(nèi)存等主機資源、業(yè)務處理進程內(nèi)部消息隊列積壓消息數(shù)進行循環(huán)掃描。

在主機資源滿足的前提下，當積壓消息數(shù)超過高水位閾值的消息隊列數(shù)超過總消息隊列數(shù)百分比閾值（如50%）時觸發(fā)動態(tài)線程擴展，通過創(chuàng)建新處理線程和線程對應消息隊列，提高整體并發(fā)處理能力，線程擴展設置擴展上限（可配置），避免無限擴展。

當消息隊列積壓消息數(shù)低于低水位閾值的隊列數(shù)超過總隊列數(shù)百分比閾值時，動態(tài)減少線程數(shù)及對應的消息隊列，減少后的線程數(shù)不能小于線程數(shù)下限（配置好的線程數(shù)初始值），消息隊列增加一個是否不再接收新消息字段，線程的減少通過先設置線程對應隊列的該字段，不再分配消息到該隊列，等線程處理完已有的消息后，該線程和該消息隊列銷毀。

以上的高低水位閾值，占總消息隊列的百分比閾值以及線程數(shù)上、下限值均為可配置參數(shù)。

消息隊列的優(yōu)化可以在有限的系統(tǒng)資源下盡可能的優(yōu)化資源使用率，智能的進行調(diào)度，并增加系統(tǒng)容錯率，保證持續(xù)可用。

2.3 消息超時機制優(yōu)化

目前的簡單消息超時判斷機制在異常情況下會占用大量系統(tǒng)時間，消耗系統(tǒng)資源，擴大異常的影響，DCC消息超時或在消息隊列中積壓情況下丟棄處理機制亟待增加完善，因此我們制定了進一步的策略加以改進：

2.3.1 上游消息到達，網(wǎng)元接口接收后，查看消息體內(nèi)容，有時間信息的，可直接判斷超時后返回，或者丟棄，不再向下游發(fā)送消息或者執(zhí)行業(yè)務操作。超時閾值需要視網(wǎng)元和業(yè)務而定，因此應該是可配置的閾值。

2.3.2 網(wǎng)元接口在向下游發(fā)送消息前，消息體內(nèi)容有時間信息的也直接判斷是否在自身隊列中已經(jīng)超時，超時后直接返回，或者丟棄，不再向下游發(fā)送消息或者執(zhí)行業(yè)務操作。超時閾值同樣應為可配置閾值。

2.3.3 如消息本身沒有消息時間戳或者消息包內(nèi)不具備時間的，則業(yè)務網(wǎng)元記錄下消息到達自身接口的時間點，以此作為判斷超時的標準。

2.3.4 接口向下游發(fā)送消息后，下游超時未返回時，向上游返回錯誤碼的同時自動殺死該超時線程，以及時釋放資源，防止自身服務夯死或者占用更大量的系統(tǒng)資源。

2.3.5 各個業(yè)務網(wǎng)元時間必須一致，才能用時間戳準確進行超時的判斷，因此需要所有系統(tǒng)對標自身服務器，確認是否配置ntp服務，進行時鐘同步。

優(yōu)化后的消息超時機制幾乎不會占用額外的系統(tǒng)資源和系統(tǒng)處理時間，但在消息超時的情況下能盡可能提前、優(yōu)化的處理，騰出系統(tǒng)資源處理可正常處理的消息，保證整體流程正常。

3 實時消息服務能力提升的后續(xù)建議

在研究、制定了以上的實時消息服務能力提升的策略后，我們先后在SR、準實時計費系統(tǒng)、計費業(yè)務網(wǎng)關、綜合賬務等系統(tǒng)逐步擴大改造范圍，效果明細。但同時我們也發(fā)現(xiàn)，改造后仍不可避免的還是會有一些消息被丟棄或返回錯誤，如果其中包含受理等操作類消息的話，會對客戶體驗有較大的影響。因此我們提出如下將來可能的改進方向：

3.1 對不同的消息設置不同的優(yōu)先級。在消息隊列處理消息時將優(yōu)先級和先后順序等統(tǒng)一考慮，在保證整體可用性的前提下，保證受理等操作類消息優(yōu)先于查詢類消息，發(fā)生異常必須丟棄時先丟棄優(yōu)先級較低的查詢類消息。

3.2 查詢受理分離。受理類業(yè)務從主數(shù)據(jù)庫進行操作，原查詢功能從復制庫獲取數(shù)據(jù)進行改造。受理類和查詢類的消息隊列也相互分離，互不影響。由于通常查詢類消息的數(shù)量遠大于受理類消息，避免查詢類的消息峰值對受理造成沖擊。

上述建議由于消息的具體種類、業(yè)務場景繁多，受理和查詢等各類消息數(shù)量不均衡等原因，必須謹慎的進行優(yōu)化，否則可能導致系統(tǒng)性能無法充分利用或者消息隊列調(diào)度混亂，因此還需在之后通過實際運維中觀察、總結(jié)經(jīng)驗，進一步的摸索后來加以完善。

4 結(jié)論

在實施了以上這些方法對消息業(yè)務流程中的各個網(wǎng)元進行了系統(tǒng)升級、優(yōu)化后，我們通過對月初開賬、批量業(yè)務查詢等消息峰值期間業(yè)務可用率、消息成功率的觀察，發(fā)現(xiàn)實時消息服務能力得到了切實提升，保證了系統(tǒng)永遠在線，能持續(xù)可靠的提供服務，完成了盡可能多的業(yè)務需求，提升了用戶感知，同時避免了對周邊系統(tǒng)的不良影響。

但是同時也應看到目前的業(yè)務流程中仍有不足，當短時的消息峰值超過了網(wǎng)絡、系統(tǒng)性能的最大值時，優(yōu)先級較高的受理類消息會和優(yōu)先級較低的查詢消息一并丟棄。因此我們后續(xù)需要再進一步摸索和研究，考慮業(yè)務量的持續(xù)增長和新發(fā)展的業(yè)務需求，不斷的對系統(tǒng)結(jié)構(gòu)和處理機制優(yōu)化以提升服務能力，滿足更高的業(yè)務支撐能力要求。

參考文獻

[1]中國電信計費結(jié)算處.全網(wǎng)計費系統(tǒng)適應移動互聯(lián)網(wǎng)能力封裝及調(diào)用的協(xié)議框架優(yōu)化改造規(guī)范[M].中國電信股份有限公司，2016.

[2]中國電信集團公司.中國電信計費運營網(wǎng)安全框架 V1.0 [M].中國電信股份有限公司，2012.

[3]中國電信上海公司.中國電信上海公司2018年智能交換平臺系統(tǒng)優(yōu)化項目建設方案[M].中國電信股份有限公司上海分公司，2018.

[4]敖錦蓉，王小峰，古英杰，周衛(wèi)星.基于消息重發(fā)的電信在線計費系統(tǒng)可靠性提升研究[J].移動通信，2016（06）.

[5]陳龍等.電信運營支撐系統(tǒng)[M].人民郵電出版社，2017.