背景
今天跟大家分享一个话题，就是对于和钱有关的在线计费系统，钱算错的时候在线可能出现的一些问题，以及我们如何设计一个框架来解决这些问题。
但是所有跟钱算有关的系统都是每个公司的重中之重，比如价格系统、运费系统、计费系统、支付系统、资金系统、财务系统、结算系统等等。，因为在这些系统运行过程中，随时可能因为技术问题或人为误操作而把钱算错。
所以今天我就给大家讲讲这种和金钱计算有关的系统。怎么才能保证他不会算错钱？
计费服务系统的架构设计|业务场景介绍
首先，我们来介绍一个业务场景。假设我们现在有三个系统:B端，M端，C端。其中，B端可以按商户/常驻客户/供应商/合作伙伴的角色进行设置和调整。M-terminal是公司可以统一调整基本计费规则的运营。c端是面向用户的。在处理一些请求时，会按照B端和M端的计费规则进行计算。
图1 计费业务系统架构图1计费业务系统架构
可能这个时候你说了。好像没什么问题。允许在平台层和商户层修改计费规则，然后C端系统根据两个系统的计费规则实时计算费用。真的是这样吗？在上面的一套计费模式中，看起来很简单，但实际上存在很多问题。让我们逐一解释。
|业务系统消息同步丢失
首先，由于历史原因，上面的计费模式会非常复杂，并没有看起来那么简单。其实B端系统每次修改计费规则，都会通过MQ将计费规则同步到M端系统，然后M端系统会汇总B端系统所有商家的计费规则。然后在后续C端系统计费时，调用M端系统的接口拉取所有需要的计费规则进行计算，如下图2所示。
图2 计费业务系统消息同步图2计费服务系统的消息同步
只是上图所示的架构，可能会在我们充电的时候造成一些技术问题。比如最典型的就是，不管怎样，B端系统修改了计费规则后，可能因为网络原因、MQ故障、代码bug等各种原因，无法与M端系统同步。，会导致C端系统一直用旧的收费规则收费。严格来说，这已经导致了收费错误，如下图3所示。
图3 计费业务系统同步信息丢失图3计费服务系统同步信息丢失
这只是同步问题导致的计费错误。其实还有一个更麻烦的问题，就是当M端系统接收到B端系统同步的计费规则时，可能会将复杂的计费规则一个接一个地写入多个数据存储中。没错，你是对的。有可能M-terminal系统会使用异构数据存储架构来存储不同的计费规则，比如mysql、mongodb等等，如下图4所示。
图4 不同计费规则写入不同类型数据库图4不同的收费规则写入不同类型的数据库。
|计费业务系统计费问题
这时候可能会出现一个问题，就是在你第一次计费规则同步的时候，C端系统可能会从你的M端系统查询各种计费规则进行计费，但是这时候可能会出现一个问题，就是最新的计费规则可能已经在mongodb中找到了，而从mysql中找出的旧的计费规则，也就是可能会完整的出现，使用不一致的计费规则进行计费，比如下图5。
图5 计费规则不一致导致C端系统计费异常图5计费规则不一致导致C端系统计费异常
这是可能发生计费错误的第二种情况。第一个计费规则的同步失败和第二个计费规则的并发读写都是技术问题。
第三种计费错误场景是我们的商家或者自己运营，欠钱甚至手动取钱，把计费规则改成了非常离谱的错误。比如某个计费规则的正常基准金额是一百元，他却改成了几块钱，可能导致公司严重亏损，如下图6所示。
图6 计费规则错误导致C端系统计费异常图6计费规则错误导致C端系统计费异常
这些问题都有可能导致计费错误，那么在这里，你是不是想说不简单，一个个案例的优化处理就完了？比如大范围加强B端和M端系统，实现MQ消息不丢失保障机制，M端系统异构存储读写，增加分布式锁，做到写时读不到，读时写不到，修改计费规则时检查操作。
是的，你说的都没错，但是我不知道你有没有想过一个问题。对于一个真正复杂的公司级系统，比如上面提到的B端系统，似乎只是图中的一帧。其实一个公司可能就是几十个人维护的大平台，M端系统也是一样。所以要想推动各方实现各种技术方案来保证，一开始跨部门推广的成本是很高的。
这只是一个，还有一个就是你现在采取了一些措施加强，但不代表以后就没有新的问题了。比如你实现了MQ同步的无消息丢失方案，但是MQ哪一天会挂掉？例如，如果在M-terminal系统中实现互斥的分布式锁读写，可能会导致并发性能的大幅下降。比如你在修改计费规则的时候增加了验证规则，计费规则的不断变化很可能会导致你的验证规则失效，或者会不断增加更多新的验证规则，如下图7所示。
图7 计费业务系统校验规则失效图7计费服务系统失败验证规则。
计费数据补偿系统的设计
这一切其实都是治标不治本。对于这种网上涉钱的，从技术和业务上都要严加防范，但这一切都取决于技术团队的技术素养和对业务验证规则的持续维护。如果你想一劳永逸，那么通常我们会推出一个计费数据补偿系统。
这个计费数据补偿系统是独立开发的。我们先来看看用这个系统我们会实现哪些功能来解决刚才看到的问题。首先，本质上我们并不关心具体B端和M端的代码逻辑是怎么写的。首先可以肯定的是，B端和M端需要实现数据同步和最终的一致。所以我们不管它们是通过MQ同步还是什么同步，我们可以直接监控B端和M端系统的数据存储，通过定时拉取数据进行对比。如果发现两边数据不一致，会自动实现补偿，如下图8所示。
图8 计费业务数据补偿系统架构图8计费业务数据补偿系统架构
那么我们来看第二个问题。不管你的M端计费规则的编写和查询逻辑是什么，最大的问题是你的一个计费结果可能没有按照一致正确的计费规则进行。所以我们的计费数据补偿系统可以直接让C端系统的计费接口把每个计费请求的日志上报给我们，然后我们也可以同时把查询和修改M端系统的每个计费规则的日志上报给我们，我们可以把相关的日志数据存储在大数据系统中。
如果对Kafka、ElasticSearch等大数据技术感兴趣，可以私信回复“大数据”，免费获得《es顶级大师系列》和《Kafka内核源代码深度解析》两门全网10w+订阅量的硬核课程。
然后可以基于大数据技术进行相关系统的日志操作，检查每次计费操作查询多个规则时，是否存在短时间内修改多个规则然后使用不一致的规则进行计算的问题，如下图9所示。
图9 计费业务规则不一致检测图9计费业务规则的不一致检测
最后，对于运营可能误操作和修正计费规则的问题，我们可以拉取C端系统的每一个计费结果，然后逐环检查计费结果。也就是说，你的计费结果每次都可以和过去类似的计费结果进行对比。如果差距过大，超过50%，会自动向运营发送报警，提醒他可能存在计费规则的误操作，如下图11所示。
图10 计费业务节费结果校验图10计费服务费用节省结果验证
摘要
通过上述计费数据补偿系统，可以直接绕过所有具体的计费规则和逻辑，与C端系统、B端系统、M端系统完全解耦，利用大数据等技术进行各种测试，从根本上解决问题，实现在线计费系统技术问题或误操作导致的计费错误。
私信回复“大数据”，免费获得《es顶级大师系列》和《卡夫卡内核源代码深度解析》两门全网10w+订阅量的硬核课程。目录和架构图如下图所示:
Kafka消息中间件内核源码深度剖析大纲Kafka消息中间件内核源代码深入分析概要
Kafka Producer端源码图Kafka生产者端源代码图
