Kafka 在微众平台双路由应急切换中的探索与应用

时间：2024-07-28

［黄凯方刘诚吴文波］

1 引言

近年来，随着通信行业竞争的加剧,三大运营商都把政企客户的争夺作为重要的竞争领地。而政企客户对业务保障也提出了越来越高的要求，业务保障的及时性决定运营商竞争地位是否有利、是否持久。部分政企客户尤其是银行金融业务对话务保障提出了较高要求，业务出现问题后必须在2 小时甚至1 小时内解决。

目前传统故障的处理模式是，设备出现问题时网管产生告警，送至集中告警平台，集中告警平台送至电子运维系统，监控工位值班人员看到告警工单后再派单给后端人员处理，中间涉及环节多，而且有些环节需要人工判断处理，到系统维护人员接到工单时往往已经过了30 分钟甚至更长时间。而维护人员接收到工单后，还需要登录设备，作各种判断分析处理，处理效率低，如果遇到需要切换的号码多还极容易出错。而随着公司去年数字化转型的兴起与发展，本文尝试通过开源技术，以微众平台话务双路由保障为例，提出一种新的解决话务双路由实时切换的解决方案。

2 微众平台现网分析

2.1 话务路由

微众平台的话务采用注册代理或非注册对等方式，IPPBX 可通过SIP 中继接入到IMS 核心网ABAC/IBAC，ABAC/IBAC 做为语音核心网网边缘接入服务器，向客户提供号码注册/呼叫代理功能，安全隔离用户接入设备，隐藏核心网拓扑。

微众平台商呼中心非注册对等方式接入到深圳IBAC，同时为了保障业务的可靠性，商呼平台通过双路由接入到深圳IBAC01/02,实现平台呼出和呼入平台的话务负荷分担，确保在IBAC-平台单路由或IBAC 单设备故障时，呼出和呼入话务可通过配对的另一台IBAC 路由疏通话务，保障业务的连续服务。如图1 所示，后面就这几部分分别说明。

图1 微众平台网络拓扑图

2.2 话务保障要求

2.2.1 平台呼出业务保障

客户平台监测到IBAC 路由状态或呼叫接续情况，当监测到路由“中断”或在该路由上发出呼叫请求INVITE后收到5XX 响应消息时，客户平台启动重选路由功能，将呼叫申请发送到配对的另一个BAC。

如果平台具备监测路由状态能力，可在路由状态可用时自动取消重选功能；否则，采用人工方式取消重选路由功能。

2.2.2 呼入平台业务保障

IBAC 监测到平台路由中断或在到平台发出呼叫请求INVITE 后收到5XX 响应消息时，IBAC 启动重选路由功能，在被叫号码前插路由码，呼叫返回到AGCF，通过配对AGCF 将呼叫路由到配对IBAC 到平台落地。如：IBAC01到平台路由中断，IBAC 在被叫号码前插路由码，路由到AGCF63、AGCF64，AGCF64 删除前插路由码后，经过IBAC02 送到平台。

当IBAC 监测到平台路由可用，自动取消重选路由功能。

2.3 风险分析

首先，虽然目前核心网综合网管已实现对IMS 网络的全面监控，可以通过提升IBAC 到客户路由告警的等级，实现当IBAC 出现附录1 告警时，一方面立即上面集中告警系统，通过监控人员派单，通知相关维护部门/人员处理；另一方面通过短信方式，通知指定客户保障人员。但是告警经过的环节过多，告警目前上报途径为：IBAC →IMS U2000 网管→核心网综合网管→集中告警系统→电子运维系统→监控人员看到告警工单并派单→维护人员接单并联系微众平台客户经理处理，中间经过五六个环节才通知到系统维护人员，而且监控人员判断告警并派单、维护人员接单并联系客户经理这两个人工环节是不一定实时的，可能存在一定延迟。因此，这种方案并不是实时的监控处理，只能说是准实时。

其次，当两个IBAC 到客户的中继故障（承载中断或客户设备故障）时，重选路由的呼叫在两个AGCF 之间乒乓振荡，存在冲击AGCF 的网络风险，因此，需要在IBAC 取消重选路由功能。

3 改进后的告警监测方案

为满足客户业务保障需求，通过开源组件Kakfa 来实现告警消息实现实时监测，我们先介绍一下Kafka。

3.1 Kafka 介绍

Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala 和Java 编写。该项目的目标是为处理实时数据提供一个统一、高吞吐、低延迟的平台。其持久化层本质上是一个“按照分布式事务日志架构的大规模发布/订阅消息队列”，这使它作为企业级基础设施来处理流式数据非常有价值。此外，Kafka 可以通过Kafka Connect 连接到外部系统（用于数据输入/输出），并提供了Kafka Streams——一个Java 流式处理库。

可以看到Kafka 也就是一个发布/订阅的消息队列。只是它具有分布式以及大规模（支持大数据量）的特性。

3.2 Kafka 组件

Kafka 各组件之间的关系如图2 所示，具体组件用途说明如下：

Producer：消息生产者，就是向Kafka 发送数据。

Consumer：消息消费者，从Kafka broker取消息的客户端。

Consumer Group（CG）：消费者组，由多个consumer 组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

Broker：经纪人一台Kafka 服务器就是一个broker。一个集群由多个broker 组成。一个broker 可以容纳多个 topic。

Topic：话题，可以理解为一个队列，生产者和消费者面向的都是一个topic。

Partition：为了实现扩展性，一个非常大的topic 可以分布到多个broker（即服务器）上，一个topic 可以分为多个 partition，每个partition 是一个有序的队列；如果一个topic 中的partition 有5 个，那么topic 的并发度为5。

Replica：副本（Replication），为保证集群中的某个节点发生故障时，该节点上的partition 数据不丢失，且Kafka 仍然能够继续工作，Kafka 提供了副本机制，一个topic 的每个分区都有若干个副本，一个leader 和若干个follower。

Leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是leader。

Follower：每个分区多个副本中的“从”，实时从leader 中同步数据，保持和leader 数据的同步。leader 发生故障时，某个Follower 会成为新的leader。

高吞吐量、低延迟：kafka 每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic 可以分多个partition，consumer group对partition进行consume操作。

可扩展性：kafka 集群支持热扩展。

持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失。

容错性：允许集群中节点失败（若副本数量为n，则允许n-1 个节点失败）。

高并发：支持数千个客户端同时读写。

图2 kafka 结构

3.3 Kafka 消息获取模式

3.3.1 producer 采用push（推）模式向broker 中写入数据

pull（拉）模式需要kafka 集群事先知晓producer 的信息，即producer 需要先注册后才能使用。当有生产者实例宕机了，可能会存在空等。若需要扩展新的producer，则需要先注册，在后续的kafka版本中逐步地和zookeeper进行了解耦。

push（推）模式的优点是生产者有数据就塞给消息队列，不用管其他的事情，只用专注于生产数据。

3.3.2 consumer 采用pull（拉）模式从broker 中读取数据

push（推）模式很难适应消费速率不同的消费者，因为消息发送速率是由broker 决定的（如图3 所示）。它的目标是尽可能以最快速度传递消息，但是这样很容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而pull 模式则可以根据consumer 的消费能力以适当的速率消费消息。

pull 模式不足之处是，如果Kafka 没有数据，消费者可能会陷入循环中，一直返回空数据。针对这一点，Kafka 的消费者在消费数据时会传入一个时长参数timeout，如果当前没有数据可供消费，consumer会等待一段时间之后再返回，这段时长即为timeout。

图3 kafka 获取消息图

3.4 Kafka 实时监测路由方案

在IBAC 服务器上，部署脚本，将IBAC 每分钟产生的日志实时传送到部署Kafka 的机器上，这样Kafka 里面就有了IBAC 的实时日志。

然后配置Kafka 系统，订阅日志中路由变化的日志，一旦产生这类日志，通过预先编写好的java 程序，Kafka会自动通过短信业务网关、语音ivr 通知到客户经理以及维护人员，以Kafka 的特性，从告警日志产生到客户经理以及维护人员接到通知，正常情况只需要5 s 的时长（如图4 所示）。

图4 kafka 监测流程

4 改进后的故障处理方案

传统的政企客户故障处理流程是，维护人员接到报障后，首先登录网元查看告警，确认告警仍然存在后，立即联系客户经理处理。

客户经理则需要上报主管确定是否组织路由切换，得到主管同意以后再通知维护人员组织路由切换，然后维护人员编写脚本进行切换，整个过程都是人工进行，时间长效率低不说，还极容易出现差错，批复下来后中间网络状态也有可能发生了变更。

为解决这个问题，我们通过编写java 程序，改造成全自动的故障处理方式：

4.1 预制应急脚本，一键调用

按照客户保障要求，通过核心网综合网管预设定AGCF 侧路由切换应急脚本，包括检查从AGCF-IBAC-客户平台路由状态、当配对AGCF-IBAC-客户平台路由状态正常时，AGCF 调整落地号码路由指向配对AGCF 等。当客户保障人员收到短信通知后，或通知客户确认受影响情况、检查IBAC 与平台路由状态，或直接通过远程方式触发路由切换等等，需要时由核心网综合网管发送应急脚本到AGCF，并反馈执行结果给客户保障人员。

4.2 程序内置审批流程

通过编写java 程序内置流程，首先减少维护人员通知客户经理这个环节，直接由客户经理发起故障处理流程，也符合现在倒三角赋能前端，让一线呼唤炮火的实时要求。

重新改进过的流程如下。

（1）在上一环节中，客户经理接到语音IVR 后同时也会接收到短信，提示是否按照应急脚本进行操作，如果同意则按Y，否则则按N。

（2）客户经理按Y 进行操作后，对应主管会接收到语音IVR 以及短信通知，是否授权进行应急脚本操作，同意则按Y，否则则按N。输入Y 以后，同时为了保证网络安全，需要输入短信验证码，短信验证码由核心网控制系统下发，只有正确输入了验证码才能进行下一步操作（短信验证码有3 次机会）。

（3）客户经理得到主管授权后，同样需要核心网综合网管下发的正确的短信验证码进行验证后才能授权设备进行操作（短信验证码有3 次机会），验证通过后进入下一步。

（4）核心网综合网管首先检查告警是否仍然存在路由是否正常，如果告警已经消失，则不作任何操作，发短信和语音IVR 提醒客户经理、维护人员告警已经消失，路由正常，无需操作。

（5）如果告警依然存在，路由不正常，程序会检查另一侧IBAC 至AGCF 的路由是否正常，如果另一侧正常，则执行应急脚本倒换路由，倒换后自动测试路由情况，并将结果通知客户经理和维护人员。

整个环节下来沟通时间大大缩短，由原来的半个小时左右，压缩到几分钟就能完成，如图5 所示。

图5 改进后故障处理流程

4.3 如何测试方案是否可行

整个实时监测方案已经出炉，但问题所之而来，如何测试这个方案是否可行呢？整个方案是采用java 程序+Kafka 组件+短信通知模块+语音IVR 模块等编写，肯定会存在多个bug，需要反复测试多次才能保证毫无问题，但现网平台不可能这样操作，必须建立测试环境进行测试，只有在测试环境反复测试没有问题了，才能在现网进行真实演练。

为模仿客户的商呼平台，我们申请了E8-C 终端以及测试IPPBX 各一台，并对测试IPPBX 分配固定1994VPN IP 地址。

然后配置测试IPPBX 双上联IBAC，在IBAC 实施主叫鉴权，号码为办公号码，如图6 所示。

测试时在IBAC01/02 上同时打开信令跟踪工具，首先正常时拨打电话，观察话务走哪个IBAC，然后运行程序，手工去激活测试ippbx 至IBAC01 的链路，看是否产生告警短信和语音IVR 推送。

图6 测试网络

接着测试审批流程是否顺畅，程序自动执行倒换脚本后，话务是否正常从另外一边的IBAC 出去，信令流程是否正常，为了保证客户业务万无一失，需要同时测试到话务走IBAC01 切换到IBAC02，以及话务走IBAC02 切换到IBAC01 这两种情况，实际测试中发现需要多次电话拨打才能保证测试到这两种情况（某一时间段可能话务都走IBAC01 或者IBAC02）。

其次就是验证程序的高可用性、高可靠性和健壮性，设想多种可能出现的极端情况，比如客户经理验证码输错或者没有输，执行脚本时发现另外一边路由不可用，或者要执行倒换时发现告警异常等10 多种情况，每种情况都要考虑到话务走IBAC01 还是走IBAC02 两种情况，每种情况都测试数十次以上，解决发现的bug 几十个，保证了应急方案在任何情况下都能正确无误地执行。