公司重用我独立负责一个核心系统，我该怎么设计系统的高可用架构？
Posted 石杉的架构笔记
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了公司重用我独立负责一个核心系统，我该怎么设计系统的高可用架构？相关的知识，希望对你有一定的参考价值。
V-xin：ruyuanhadeng获得600+页原创精品文章汇总PDF目录
- 业务场景引入
- 业务系统消息同步丢失
- 计费业务系统的计费问题
- 计费业务数据补偿系统设计
背景
今天给大家分享一个话题，就是对于线上跟钱有关的计费类的系统，在线上可能出现的一些把钱算错的问题，以及我们如何来设计架构解决这些问题。
但凡是跟算钱相关的系统，都是每个公司的重中之重，比如说价格系统、运费系统、计费系统、支付系统、基金系统、财务系统、结算系统等等，因为这些系统运行过程中，随时可能因为技术问题或者运营的人为误操作问题，把钱给算错了。
所以今天来给大家讲讲这一类跟算钱有关的系统，我们应该如何来保证他不会把钱给算错呢？
计费业务系统架构设计
| 业务场景引入
首先，我们先来引入一个业务场景，假设我们现在有 B 端、M 端和 C 端三个系统。
其中 B 端可以由商家/入驻客户/供应商/合作伙伴这一类 B 端角色对自己的一些计费规则进行设置和调整，M 端是是公司的运营可以进行统一的基础性计费规则调整，C 端是面向用户的，在处理一些请求的时候，会根据 B 端和 M 端的计费规则进行计算，算出当前的支付金额。
如下图：
这个时候可能你说了，这看起来没啥问题啊，不就在平台层和商家层允许修改计费规则，然后c端系统实时根据两个系统的计费规则计算费用么。
真的是这样吗？上面那套计费模型里，看着简单，其实蕴藏着大量的问题，下面来给大家一一说明。
| 业务系统消息同步丢失
首先，因为历史原因，上述计费模型会非常的复杂，不是我们看起来那么的简单。
实际上，B 端系统每次修改完了计费规则以后，是要把计费规则通过 MQ 同步给 M 端系统的，然后 M 端系统会汇总 B 端系统的所有商家的计费规则，接着后续 C 端系统在计费的时候，是调用 M 端系统的接口拉取所有需要的计费规则来进行计算的。
如下图所示：
单单就上图这一个架构，就可能会让我们在计费的时候可能因为一些技术原因出现问题。
比如说最典型的就是，不管因为什么，B 端系统那里修改了计费规则以后，可能因为网络原因、MQ 故障、代码 bug 等各种原因，并没有同步到 M 端系统那里去，这就会导致 C 端系统一直用老的计费规则在计费。
严格来说，这就已经导致计费错误了，如下图所示：
这还仅仅只是同步问题导致的计费错误而已，其实还有更加麻烦的一个问题，那就是当 M 端系统收到了 B 端系统同步过来的计费规则了以后，他可能会陆续把复杂的计费规则写入多个数据存储中。
没错，你没看错，有可能 M 端系统会用异构数据存储架构，来存放不同的计费规则，比如 mysql、MongoDB，等等。
如下图：
| 计费业务系统计费问题
这个时候可能会出现一个问题，那就是 C 端系统可能会在你的一次计费规则同步的过程中，就从你 M 端系统这里来查询各种计费规则来进行计费。
但是这个时候有可能会出现一个问题，那就是 MongoDB 里可能已经是最新的计费规则，而从 MySQL 里查出来的还是老的计费规则，也就是说，完全可能会出现，用了不一致的计费规则来进行计费。
比如下图：
这是第二个可能出现计费错误的场景，第一个计费规则同步失败和第二个计费规则并发读写，都是技术类的问题。
第三个计费错误的场景，就是我们的商家或者自己的运营，手欠甚至手抽，把计费规则改成了非常离谱的错误。
比如说，某一个计费规则正常基准金额是百元级别的，但是他给改成了几块钱，这可能会导致公司出现严重的损失。
如下图：
所有这一切问题，都可能会导致计费的错误，那么说到这里，大家是不是想说，那还不简单，case by case 的优化和处理不就完了。
比如说对 B 端和 M 端系统进行大范围的加固，实现 MQ 消息不丢失保障机制，对 M 端系统异构存储写入和读取，加个分布式锁，写入的时候不能读取，读取的时候不能写入，对运营修改计费规则的时候进行校验，加入各种校验规则，乱改就不让你通过。
没错，大家说的这些其实都可以，但是不知道大家想过一个问题没有，对于真正复杂的公司级系统，比如上述的 B 端系统，看起来在图里仅仅是一个框而已。
其实一家公司里可能是几十个人维护的大平台，M 端系统也是同理，所以如果要推动各方实现各种技术方案来做保障，首先在跨部门推动方面成本就是很高的。
这仅仅是其一，其二，就是你现在做了一些措施做了加强，但是不代表以后就不会有新的问题了。
比如说，你对 MQ 同步实现了消息不丢失方案，可是哪一天如果 MQ 挂了呢？
比如说，你如果在 M 端系统实现写入和读取加分布式锁做互斥，那可能会导致并发性能大幅度的降低。
比如说，你给计费规则修改加入校验规则，可是随着计费规则不停的变化，很可能会导致你的校验规则失效，或者要持续不断的加入更多新的校验规则。
如下图：
计费业务数据补偿系统设计
所有这一切其实都是治标不治本，对于这一类线上跟钱相关的，固然应该在技术和业务上严防死守，但是这都依赖技术团队的技术素养，以及对业务校验规则的持续维护，如果想要一劳永逸，那么通常我们会引入一套计费数据补偿系统。
这个计费数据补偿系统，是额外独立开发的，我们来看看，用这个系统我们会实现哪些功能来解决刚才看到的那些问题。
首先，从本质上来说，我们不管具体的 B 端和 M 端的代码逻辑是如何写的，第一个有一点是可以肯定的，那就是 B 端和 M 端是需要实现数据同步和最终一致的。
所以说，我们不管他们之间是通过 MQ 来同步或者是什么，我们可以直接监听 B 端和 M 端系统的数据存储，通过定时拉取数据来实现比对，如果一旦发现两边数据不一致，则自动实现补偿。
如下图：
接着我们再来看第二个问题，不管你的 M 端计费规则的写入和查询逻辑如何，最大的问题就是你的某一次计费结果可能并没有按照一致和正确的计费规则来进行。
所以说，我们的计费数据补偿系统可以直接让 C 端系统的计费接口把每次计费请求的日志上报给我们。
接着我们可以同时把 M 端系统的每一次计费规则的查询和修改日志也上报给我们，我们可以把相关日志数据存储到大数据系统中。
接着我们就可以基于大数据技术来进行相关系统的日志运算，检查一下每一次计费运算查询多个规则的时候，是否出现了多个规则在短时间内先后修改，然后导致使用了不一致的规则来计算的问题。
如下图所示：
最后就是对于运营可能误操作改错计费规则的问题，我们可以拉取 C 端系统的每一次计费结果，然后对计费结果我们可以进行环比比对校验。
就是说，你每一次计费结果都可以更过去的类似的计费结果进行比对，如果说差距过大，超过了 50% 的话，那么就会自动发送告警给运营，提醒他可能出现了计费额规则误操作的问题。
如下图所示：
总结
通过上述的计费数据补偿系统，就可以直接绕开所有的具体计费规则和计费逻辑，跟 C 端系统、B 端系统、M 端系统完全解耦。
采用自行拉取数据、拉取日志、拉取计费结果等手段，用大数据一类的技术进行各种检测，从根本上解决问题，以此来实现线上计费系统因为技术问题或者误操作问题导致的计费错误。
V-xin：ruyuanhadeng获得600+页原创精品文章汇总PDF另外推荐儒猿课堂的1元系列课程给您，欢迎加入一起学习~
SpringCloudAlibaba零基础入门到项目实战（1元专享）
基于ShardingSphere的分库分表实战课（1元专享）
支付系统架构设计详解
Part one 支付系统总览核心系统交互内容导读：支付永远是一个公司的核心领域，因为这是一个有交易属性公司的命脉。那么，支付系统到底长什么样，又是怎么运行交互的呢?
抛开带有支付牌照的金融公司的支付架构，下述链路和系统组成基本上符合绝大多数支付场景。
其实整体可以看成是交易核心+支付核心 两个大系统。
交易系统关联了业务场景和底层支付，而支付系统完成了调用支付工具到对账清算等一系列相关操作。下面我们就来一起看下 各个系统的核心组成和交互。作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
交易核心把公司的业务系统和底层支付关联起来，让业务系统专注于业务，不比关心底层支付。
交易核心
基础交易类型抽象
多表聚合 & 订单关联
支付核心主要负责将多种支付类型进行抽象，变成 充值、提现、退款、转账四种支付形态。同时，还要负责集成多种支付工具，对支付指令进行编排等等。
支付核心总览
支付行为编排
其目的，是实现 插件式开发、支付规则可配置的 灵活开发方式。
异常处理
异常处理包括了 重复支付、部分支付、金额不一致、其他异常等异常场景。
通过确定系统边界、业务建模拆分之后，整个支付平台被拆分几十个服务，而如何保障在服务间流转业务信息不被丢失，是我们需要考虑的问题。平台统一上下文的要素信息（唯一业务标识码），在整个支付平台链路中全程传递，被用来解决这个问题。
大型的支付公司，内部都有非常严格和完备的数据一致性方案，比如采用业务侵入性非常大的分布式事务等，以牺牲开发效率来提升数据的稳定，是非常有必要的。而业务公司，如果不采用分布式事务又有哪些应对策略呢？
CAS校验
幂等 & 异常补偿
对账
准实时对账
支付是整个交易链路的核心环节，那么，怎么兼顾支付系统的稳定性和执行效率呢？是异步化。
消息异步化
外部支付调用异步化
在外部支付中，经常需要服务方与第三方支付交互，获取预支付凭证，如上图所示。
这种同步调用的情况下，由于需要跨外部网络，响应的 RT 会非常长，可能会出现跨秒的情况。由于是同步调用，会阻塞整个支付链路。一旦 RT 很长且 QPS 比较大的情况下，服务会整体 hold 住，甚至会出现拒绝服务的情况。
因此，可以拆分获取凭证的操作，通过独立网关渠道前置服务，将获取的方式异步化，从前置网关获取内部凭证，然后由前置网关去异步调用第三方。
异步并行化
资金核算异步化
热点账户账务单独处理
记账事务切分
以上是关于公司重用我独立负责一个核心系统，我该怎么设计系统的高可用架构？的主要内容，如果未能解决你的问题，请参考以下文章