张巍

摘要：目前实时消息的服务能力业务种类增加，业务量大幅提升，对各相关系统的要求不断提高。在系统硬件有限的情况下，一旦短时业务量峰值超负荷或者某业务节点异常，容易引发雪崩效应，导致业务流程整体不可用且难以恢复。经过研究分析，我们提出了一系列方法来提升实时消息服务能力和恢复：各系统接口具备消息队列蓄水能力；增加超时消息预判和下游截断功能；对关键系统设置复制库等。这方法在很大程度上提升消息服务能力，减少了异常状况的影响，便于快速维护，快速定位问题，同时避免影响用户感知和对周边系统造成压力。

关键词： 实时消息；服务能力提升；超时预判；复制数据

中图分类号：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.