​

随着时代的发展，移动办公已经成为了常态，大家也越来越离不开手机，微信、QQ、网游、邮件、电话会议等等，网络通信几乎一刻都不能中断。对于电信运营商来说，缴费、充值、复机等关键应用几乎不能中断，否则就会导致终端用户无法使用手机业务，引起客户的投诉。然而软件产品出现故障有时候又是不可避免的，出现故障的原因也是五花八门，有网络的，有硬件的，有中间价的，有数据库的等等，因而实现这一目标并非易事。

本文重点阐述计费领域在高可用方面的一些思考和实践。

软件系统的高可用架构演进通常经历以下几个阶段：

• 单点故障：初始阶段，系统中存在单点故障，即某个关键组件或服务的故障会导致整个系统不可用。

• 水平扩展：通过增加更多的节点来扩展系统的处理能力和容量。水平扩展可以通过添加更多的服务器、分布式存储或数据库节点来实现。

• 负载均衡：引入负载均衡器，将流量均匀地分发到多个节点上，以避免单个节点过载。负载均衡器还可以检测节点的健康状态，并在节点故障时自动将流量转移到其他健康节点上。

• 冗余备份：为了提高可用性，引入冗余备份的概念。通过复制关键组件或服务，当一个节点故障时，可以切换到备份节点继续提供服务。

• 容错设计：在架构中引入容错机制，以应对节点故障或网络故障。例如，使用多个数据中心进行跨区域备份和容灾，或者使用分布式存储和数据库系统来实现数据的冗余和恢复能力。

• 自动化运维：引入自动化工具和流程，减少人工干预，提高系统的可靠性和可恢复性。自动化运维可以包括自动监控、故障检测和恢复、自动扩展等。

2019 年，中国电信完成了 BSS3.0 系统的升级改造，实现了全面去 IOE，全面引进中国电信集团的各种组件，包括分布式数据库组件、分布式消息中间件、分布式缓存、分布式文件系统、微服务框架等，全面实现了分布式架构的提升，在系统高可用方面实现了全面的提升，已经基本上解决了单点故障、水平扩展、负载均衡等能力。但是随着系统引入的分布式组件越来越多，系统架构越来越复杂，不可避免的会引入一些新的问题，比如分布式组件集群出现问题时，如何能够做到业务的永不中断呢？比如数据库变慢，分布式内存数据库出现问题，该如何确保充值能够及时复机？

针对这些影响高可用的问题，先思考下策略：

• 数据库变慢了，数据库短时不可用，该怎么办？可不可以脱库运行呢？能不能把数据加载到分布式内存数据库，减少对数据库的依赖？

• 分布式内存数据库也不行了怎么办？能不能多部署一套分布式内存数据库，实现蓝绿部署？

• 分布式消息中间件、分布式缓存不行了怎么办？能不能多部署一套，实现一键切换呢？

• 如何做到一键切换呢？当前系统中有多种方式实现参数配置，有在业务代码中的，有在参数组件中的，有在共享内存中的，能否引入配置中心，实现一点配置即时生效呢？

根据上述的一些思考和细化讨论，形成了关键解决方案和举措：

• 充值复机全内存化，彻底避免了 Teledb/TelePG/TeleHTAP 等物理库异常带来的故障风险，提升了充值服务的性能及稳定性。

• 异常异步充值，充值服务异常时先返回充值成功，触发异步充值重试，屏蔽充值服务异常报错时对用户的直接感知。

• 绿色复机通道，通过充值端到端消息追踪实时监测充值业务异常，针对系统环节异常积压造成的复机不及时场景，优先保障充值用户及时复机，避免用户投诉。

• 蓝绿故障转移，针对 PAAS 组件集群级故障，包括资料内存库集群、CTGMQ 集群、CTGCache 集群异常时，自动触发蓝绿自动切换，保障充值服务不受影响。

01 服务内存化方案

充值 &冲账全内存化，脱离对 TelePG 和 TeleDB 的依赖，从而避免分布式事务问题，以及防止物理库故障或并发性能波动影响充值服务，提升充值服务的性能及稳定性。

充值、冲账、余额预占、快速复机等服务中涉及到资料查询、余额欠费、收费记录、接口流水、余额来源支出、余额支出明细、未打单记录等均需要进行内存化。通过 MDB 的持久化服务同步数据到物理库。

02 绿色通道方案

充值复机任何环节出现异常时，先触发用户绿通复机，保障用户及时复机，不影响用户的业务使用。

针对充值到账不及时场景，异步自动重试补充值。

充值到复机端到端流程进行 jaeger 调用链埋点，实时监控从充值到账及复机处理的及时率，针对端到端时延超过阀值的充值交易记录，触发告警并自动启用绿色通道先行开机，平均复机及时率达到一定阀值时全面开启绿色通道。

充值复机绿色通道监控大屏

方案关键亮点如下：

充值异常监测服务，实时监测充值端到端日志，识别异常工单实时自动触发绿色通道开机。

• 充值到账不及时：以集团充值接口日志和 GPRC 充值成功日志（覆盖全渠道）为基准时间，3 分钟内没有充值成功日志，调用 openapi 补充值。

• 复机处理不及时：以集团充值接口日志和 GPRC 充值成功日志（覆盖全渠道）为基准时间，在 3 分钟内没有查询到快速复机或者信控处理的消息，触发绿色通道直接复机。

• 复机工单发送不及时：以快速复机或信控处理日志复机工单日志为基准时间，在 3 分钟内没有查询到复机发送的日志，则记录充值复机异常工单，触发绿色通道直接复机。

绿色通道开机服务均不能依赖业务系统使用的组件和数据库，覆盖全充值渠道及复机工单发送异常的场景。

• 直接写 CRM 复机工单表，内部状态变更等正常信控处理更新，针对经过信控判断后不应该复机的情况，定期检查并通知信控服务更新内部状态，后续实时信控可再停机。

通过充值业务监控大屏，实时监控各渠道充值业务情况，直观展示系统端到端各环节性能、积压及异常情况，以及绿色通道服务情况。支持人工一键开通绿色通道。

• 可链接到充值端到端明细查询，体现每笔充值交易的各环节的处理情况，快速找到异常的充值记录及绿通复机处理情况。

• 可关联查看每笔充值交易的详细调用链，快速定位充值复机的异常问题

03 蓝绿部署方案

MDB 资料库、 CTGMQ、CTGCACHE 采用双集群互备，业务应用服务采用蓝绿部署，PAAS 组件集群级异常时，故障自动转移、蓝绿一键切换。

​

MDB 资料库集群和 PAAS 组件蓝绿部署

• MDB 资料库通过资料刷新应用双边刷新，保障两套 MDB 资料库集群的数据一致性。

• CTGCACHE 通过参数刷新应用，在参数发生变更时两套集群同时刷新。

• CTMMQ 集群蓝绿各自使用一套集群，集群间不做数据同步，蓝绿两套 MQ 消费者各自消费各自的 MQ 集群。

应用服务蓝绿部署

• 接口层服务保持一套：仅启动时依赖数据库，运行过程中不依赖数据库、MQ、CACHE 组件，无需蓝绿部署。

• Dubbo 服务、Grpc 服务、MQ 消费者服务采用蓝绿部署，分别连接蓝绿两套的 MDBCUST、CTGMQ、CTGCACHE 集群，可通过 istio 服务网格的服务路由规则，实现蓝绿服务负载均衡。

• 故障自动转移、蓝绿一键切换：当发生 MDB 资料库、CTGMQ、CTGCache 集群级异常时，配置 istio 的故障自动转移规则，故障服务自动熔断，业务路由自动转移到正常服务；通过健康探针机制实现服务故障自愈，并自动恢复业务路由。当故障短期无法恢复时，通过修改 istio 路由规则，人工一键蓝绿切换。

通过 Istio 控制蓝绿路由策略，支持默认三种路由策略，三种策略可以一键切换：

• 自动负载均衡，故障自动转移（推荐）

• 全部路由到蓝色服务

• 全部路由到绿色服务

账务中心监控大屏，实时检测 IAAS、PAAS、SAAS 三层立体监控，实时检测蓝绿业务流量负载及业务服务情况，异常时一键切换。

​

• 第一层：监控各个应用服务的情况，包括调用成功率、实时调用量、性能时延及服务状态等关键指标，异常时红色预警；按充值、查询、发票、其他四类业务类别分别展示蓝绿服务各自的情况，以及蓝绿当前实时业务流量总占比。

• 第二层：监控 MDB、MQ、CACHE、UDAL 等数据库及 PAAS 组件的状态、访问量等指标，异常时红色预警；

• 第三层：监控各个 PAAS 组件、数据库及应用主机的情况，对于主机 CPU、内存、IO 及主机状态进行监控，当主机异常时可以红色预警。

通过账务中心监控大屏，可链接到各 PAAS 组件及应用监控的子屏，进行更详细的指标监控

• 主机监控：展示包括数据库、PAAS 组件及应用主机等所有主机的详细监控指标，快速发现主机故障问题，并生成预警。

• MQ 集群监控：实时检测 MQ 集群的消息生产和消费情况。

• CtgCache 集群监控：实时检测 cache 集群的访问量及内存使用率等情况

• MDB 集群监控：实时检测 MDB 集群的连接数、服务状态、读写性能、持久化、刷新积压等各类指标。

• 账务中心服务性能监控：检测账务中心各渠道各层级服务的交易量、性能时延、成功率等关键指标，快速定位异常服务。

• 充值业务监控大屏

通过以上的服务内存化、绿色通道以及蓝绿部署等举措，实现了浩鲸科技新一代账务系统的高可用，保障充值复机业务的永不间断。