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

張巍

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

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

中圖分類號：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

緒論

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

1 實時消息流程現狀分析

1.1 實時消息處理流程

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

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

目前在實時消息處理的運營過程中，發現存在如下一些問題：

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

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

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

上述問題都曾引起過單個或者多個系統的異常。“一點接入、服務全網”的移動互聯網跨地域業務需求，要求BON對外提供穩定、可靠、高效的能力封裝調用，因此實時消息服務能力必須進一步的提升。

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

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

2.1 業務網元永遠在線

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

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

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

業務網元永遠在線可以有效避免系統升級、異常等內部原因導致的完全不可用，但此期間還是可能導致處理性能下降。因此系統升級仍應選擇凌晨等系統閑時，而發生異常時也需盡可能快的修復，及時恢復系統至最大處理能力。

2.2 業務網元消息隊列優化

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

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

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

系統增加高低水監控線程，對CPU、內存等主機資源、業務處理進程內部消息隊列積壓消息數進行循環掃描。

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

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

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

消息隊列的優化可以在有限的系統資源下盡可能的優化資源使用率，智能的進行調度，并增加系統容錯率，保證持續可用。

2.3 消息超時機制優化

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

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

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

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

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

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

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

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

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

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

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

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

4 結論

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

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

參考文獻

[1]中國電信計費結算處.全網計費系統適應移動互聯網能力封裝及調用的協議框架優化改造規范[M].中國電信股份有限公司，2016.

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

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

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

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