公司重用我独立负责一个核心系统,我该怎么设计系统的高可用架构?

本文讨论了线上计费系统的重要性,并通过一个业务场景介绍了可能存在的计费错误,如消息同步丢失和并发读写问题。提出通过计费数据补偿系统来确保数据一致性,该系统通过监听数据存储、收集计费日志,并利用大数据技术进行日志运算和环比比对,从而避免计费错误。此外,文章提到了系统解耦和跨部门合作的挑战。
摘要由CSDN通过智能技术生成
V-xin:ruyuanhadeng获得600+页原创精品文章汇总PDF

目录

  • 业务场景引入
  • 业务系统消息同步丢失
  • 计费业务系统的计费问题
  • 计费业务数据补偿系统设计

背景

今天给大家分享一个话题,就是对于线上跟钱有关的计费类的系统,在线上可能出现的一些把钱算错的问题,以及我们如何来设计架构解决这些问题。

但凡是跟算钱相关的系统,都是每个公司的重中之重,比如说价格系统、运费系统、计费系统、支付系统、基金系统、财务系统、结算系统等等,因为这些系统运行过程中,随时可能因为技术问题或者运营的人为误操作问题,把钱给算错了。

所以今天来给大家讲讲这一类跟算钱有关的系统,我们应该如何来保证他不会把钱给算错呢?


计费业务系统架构设计

| 业务场景引入

首先,我们先来引入一个业务场景,假设我们现在有 B 端、M 端和 C 端三个系统。

其中 B 端可以由商家/入驻客户/供应商/合作伙伴这一类 B 端角色对自己的一些计费规则进行设置和调整,M 端是是公司的运营可以进行统一的基础性计费规则调整,C 端是面向用户的,在处理一些请求的时候,会根据 B 端和 M 端的计费规则进行计算,算出当前的支付金额。

如下图:

图片

这个时候可能你说了,这看起来没啥问题啊,不就在平台层和商家层允许修改计费规则,然后c端系统实时根据两个系统的计费规则计算费用么。

真的是这样吗?上面那套计费模型里,看着简单,其实蕴藏着大量的问题,下面来给大家一一说明。

| 业务系统消息同步丢失

首先,因为历史原因,上述计费模型会非常的复杂,不是我们看起来那么的简单。

实际上,B 端系统每次修改完了计费规则以后,是要把计费规则通过 MQ 同

  • 1
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值