浅谈新一代账务系统的高可用演进思路

发布时间:2024年01月16日

随着时代的发展,移动办公已经成为了常态,大家也越来越离不开手机,微信、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集群的连接数、服务状态、读写性能、持久化、刷新积压等各类指标。

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

  • 充值业务监控大屏

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

文章来源:https://blog.csdn.net/whalecloud/article/details/135616000
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。