2 支付能力的快速接入
支付快速接入：
设计流程主要目标：屏蔽接入第三方支付平台的复杂度，为业务提供便捷接入的支付的能力。
整体交互逻辑：用户下单后，业务线生成生订单的同时请求支付系统，返回携带加密后的收银台链接，业务前端渲染收银台H5链接，之后用户操作都直接与支付系统直接交互，不再经过业务线。
支付渠道-接入微信支付
左上是收银台（支付页），包括订单基本信息、随机减活动和微信引流活动等。
右上是支付平台和微信交互逻辑。
3 配置化支付方式
最小粒度是支持按不同渠道配置，如最核心的商超业务渠道有几十个，根据不同终端适当屏蔽风控能力减弱的支付方式，或在某些特别终端按业务要求配置指定支付方式，每种相同的支付方式，根据具体的业务线或具体的业务配置不同的商户号，不同的商户号在第三方平台的费率，收款账户都不服务器托管网同。
4 支付单的生命周期
一笔支付单的生命周期：
多端支付场景
第一： 由于我们无法感知用户唤醒sdk后的操作。
所以不能限制用户的支付行为，一个订单可从多个手机多个渠道使用相同或不同支付方式、不同的人同时对一笔进行支付。
第二：支付、退款跨越多个端。
支付跨越多机构，就会经过支付平台、第三支付平台、银行等。支付和退款是天然异步场景，这是不可抗因素。
5 如何安全保证金额正确性
交易金额的强一致性保障设计
台账信息记录4个金额字段：应收、实收、应退、实退。收到支付通知时，会在收到支付通知的时候进行一次对账。
判断：应收+应退=实收+实退
保持该等式，即可正确计算每笔次金额变动。虽然使用一个简单公式来保障多端并发下金额修改的正确性，但由于金额频繁改动，是否可能出现逻辑bug？
若给用户少退了，第一时间即可得到用户的反馈，及时修正bug，并补偿给用户；但如果给用户多退一些钱，很可能用户不会产生反馈，我们自己也没发现。
所以系统底线保障是：
确保不会产生多退款
实收的钱应≥应收的钱。
通过不变量和不需要加工的数据来验证变量
要通过啥手段，保证实收≥应收？尽可能通过不变量和无需加工的数据来验证变量：
- 不变量：订单金额
- 无需加工的数据：业务申请的退款。业务一旦申请退款，校验通过就会插入DB。这里是业务产生的退款，退款可能细分人工退款、多支付退款等，但这些都不用关心。
我们要关心：订单金额-业务产生的退款，即至少收到多少钱，若和实收相等，则认为没问题。
如何保证实收就是正确的？
继续使用实收和支付平台对账，就可进一步确保实收没问题，需对账每一笔正向支付交易和逆向支付交易产生的金额记录，且对账至少需要2种机制来相互保障。
6 高可用架构实践及思路
引用:软件在本质上是复杂的，软件本身的复杂性在于除了要解决问题域，还要解决非功能性需求和软件域特有问题：安全性、可用性、可维护性、可扩展性、性能、一致性、容错性、稳定性、可重用性、幂等、兼容等等。
6.1 分类
三部分：
6.2 实时性保障
支付是一个不可抗拒的跨端异步场景，还服务器托管网要抵抗网络带来的不确定因素。一笔银行转账，大家在心里有预期，即使实时转账，大家也会自觉等待一段时间。
但对在线支付，用户支付完后，用户很理所当然的想到应该看到订单是已支付状态，而非待支付状态，延迟增加到一定时长，客服就找到研发。
线上场景特征
- 配送时效性。一笔订单生命周期就不到1小时，所以在支付上我们不能延迟，不能像银行转账这么慢
- 高并发。银行等金融机构有钱，活动力度不亚于一些商品秒杀场景
- 营销限量。若用户享受支付优惠，但最终由于支付通知的延迟、服务器负载较高的情况下未能成功处理支付通知，那么用户就会要求索赔营销优惠
线下
比线上更复杂：
- 即时性。大家去的线下商店，都支持收银台在线支付，所以在排队的情况下，就需要商家及时完成顾客支付请求
- 网络环境不可控。不同位置，网络信号存在不确定性
- 群体性。线上主要是平台和支付平台的网络交互，但线下还涉及商家，整个支付环节也没这么流畅
尽可能快的让订单支付完成或在某种支付有问题时，第一时间下线这种支付方式。
过去做法是通过暴力从DB反查待支付订单，但对DB压力较大，还得单独写个任务表，后改写为
基于事件通知机制
使用MQ作为事件管道，但由于不同场景触发的反向查询时机不同，不能对所有对待支付订单进行无差别对待，因此就受限MQ特性。目前不支持个性化延迟消费消息，对此策略是申请多个队列，并按不同延迟level入队。
查询补偿设计
反向查询主要场景
① 支付唤醒
由于用户需要输入密码，我们考虑到需要用户参与，进行多次间隔3秒到重试之后，如果还没支付结果则放到更大时间间隔到重试leave中。
② 协议支付、代扣类
用户无需输入密码，所以我们选择更低延迟到消费队列、或无延迟队列。
③ 订单取消
由于反向查询在一定的次数之后会放弃，不然会很占用资源；但如果一笔订单取消了，那么也有可能会因为支付延迟导致订单取消，所以我们就会最后查询一次。
④ 支付通知
同步进行查询结果，主要为防止伪造通知，但增加了一次外网交互，超时可能性很大，伪造通知是极端场景。所以在超时之后会暂时信任本次通知，继续交给反查队列，继续对这笔通知进行验证。
6.3 应用部署隔离
高可用部署的一个架构，划分维度 2C，2B：
根据2C和2B业务请求，对服务器部署上做资源倾斜。确保业务互不影响。
2C一般正向交易场景，RT要求高；2B场景对时效基本没要求，某些业务场景下，会存在集中性大批量退款申请、退款流程的事务也比较大，ToB就针对一些任务worker更消耗CPU。
目标是尽量避免非业务耗时导致的RT升高，而导致RT升高因素有：
- 池化资源不够（http请求线程、rpc处理线程、数据库线程、以及http连接等）
- CPU资源抢占
- GC 导致的业务线程等待
- …
6.4 多级本地缓存
商品支付的营销需求。参与商品不到百万级，但调用量大，峰值调用量超10万QPS、RT苛刻5ms。
但也由于这是刚新起的业务，产生的业务价值收益有不确定性，所以没打算通过机器去抗量，所以我们把业务请求直接请求到Redis。
但是redis需要较多副本才能扛超高并发，避免大量无效请求。并且增加内存基本的缓存，使用布隆过滤器（Bloom Filter），仍然会把cpu打高，通过门店的过滤把cpu降到最低，所以我们最后会通过caffeine来做热点sku缓存。
Redis的利用率已达97%，这完成是布隆过滤器来决定的，效果明显！
6.5 监控
某晚，手机一阵震动，打开报警一看，报警很明显。红色框是垂直类-支付渠道层的报警，而且都是apple Pay导致的报警，大概率影响支付方式apple Pay。
绿色框是水平维度监控，显示我们的影响功能：支付、查询。同理报警没有显示的业务线，就跟这些具体业务场景没关系。
所以，做平台，监控非常重要的，：“没有度量就没有管理”。
跑在线上生产环境中的每一个服务，也需要管理，我们需要管理它们的运行情况，所以就需要我们建立的完整指标反馈监控系统。
① 机器层面的监控
- 机器维度：系统指标：cpu、负载、内存
- 网络指标：tcp连接数、丢包数、tcp重传
- 磁盘指标：磁盘使用率和磁盘繁忙度
- 容器指标：关注线程数
- 应用：软件异常
② 应用层面的监控
- 系统异常：基础组建异常（数据库、Redis）、RPC异常
- 业务异常：业务异常的捕获主要是为了捕获业务线的一些非法出入参。
- 非预期逻辑：主要一些没想到的一些逻辑场景。通过自定义监控。
- Bug(Jex接入)：上线一阵时间后。大家可以去搜搜excpetion、error关键词。总有意想不到的收获。
③ 业务监控维度
作为平台类系统，最重要的是结合水平维度+垂直维度划分系统报警情况：
- 水平维度：支付、退款、营销、通知
- 垂直维度：业务方、渠道平台
FAQ
延迟队列使用什么框架实现的？
京东的JMQ按照队列进行消费延迟。RocketMQ支持消息级的延迟。
如何避免单重复支付呢？或者避免重复退款呢？
支付是一个不可抗拒的多支付场景。在接收到支付通知的时候，要做对账，如果是多支付，就进行退款。
商品价格类型是用float还是decimal？
支付系统最好使用bigDecimal，因为和支付平台交互单位都是元。其他交易系统尽可能使用long类型，分作为单位。
个阶段对账，如果有差错，怎么处理？
程序设计越复杂，bug的可能性就会越多，所以要尽可能通过一些不变对量和不可修改的数据进行底线保障，至少需要2种金额校验相互保障。
如果应收50，A付款30，B付款40 你这个情况咋退款呢？退款给谁呢？
不会出现。支付金额至少是50，即便多支付，也是100 或者150。
sku的缓存怎么做的，说到是基于Redis的，那数据库和缓存的同步呢？比如下单后扣减库存呢？或更新呢？
整体是基于redis的。但是redis需要较多的副本才能扛超高并发，避免了大量无效请求。增加了内存基本的缓存，使用了布隆过滤器，但是仍然会把cpu打高，通过门店的过滤把cpu降到最低，最后通过caffeine来做热点sku缓存。
关注我，紧跟本系列专栏文章，咱们下篇再续！
作者简介：魔都国企技术专家兼架构，多家大厂后端一线研发经验，各大技术社区头部专家博主，编程严选网创始人。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。
负责交易平台及数据中台等开发设计，通过深入业务，构建合理业务架构。目前主攻降低软件复杂性设计、构建高可用系统方向。
参考：
- 编程严选网
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.fwqtg.net
