架构师眼中的CRUD：你真的会写状态更新吗？update有学问！_crud图

声明

下面的故事，记录的技术要点，是真实发生在我身上的。为了记录下这些知识点，同时让大家以一个放松的心态去进行阅读，将其改编成诙谐幽默的小故事。

登场人物介绍：
H兄：我们的项目总监、技术负责人，老大哥的形象，一般也是问题的最后裁判员
C大：我们的架构师同学，技术涉猎面广，考虑问题全面，鬼点子也非常地多
小L：刚入职公司的应届毕业生开发，对技术有着无比的热情~需要的是时间磨练以及经验！
大V：高级JAVA开发，有着3年以上开发经验，正在朝架构师方向努力中！
Fox桑: 我们的测试同学，有着丰富的功能以及性能测试经验，总能在测试过程中发现很多虫子哦~

特别说明

本次的故事，素材依然来自我的工作经历。这次的故事，是一个发生在我们团队内部的真实案例，对于刚进入移动支付领域的同学来说，会是一个非常好的启发，让我们一起共勉。

背景知识

想要了解这个故事，首先我们得从移动支付的一般性流程说起。这里因为涉及到一些公司资产，有一些保密内容，因此我将整个移动支付系统模型做了一个简化。因此，在实际生产过程中，今天这个故事中讲到的数据模型以及流程，仅供大家学习研究之用，生产上是不够用的，切记哦！

一般来说，我们的移动支付中会有几个对象，订单、商品、支付流水。他们的关系，大体上是这样的：

一笔订单，会有多个商品信息与之关，换句话说，可能会有一个或者多个商品，合并到一个订单内进行支付。
支付流水，可能也会存在一个或者多个，为什么这么说呢？暂且不论有没有可能一笔订单分微信和支付宝两个方式拆分支付。比如我们要设计一个优惠券系统的话，优惠券的抵扣金额，也应该生成一笔支付流水。否则的话，日终对账就会出现订单总额与流水总额对不起来的情况。同时，给用户展示的订单信息中，不展示优惠券抵扣部分金额，其实也是说不过去的。因此，一般在设计过程中，一笔订单会有多个支付流水。
当然，我们这次的故事，跟这个模型基本上没有关系，只是作为一个前提背景，我先给大家做一个简单的介绍。
在来述说我们的支付，一般来说，当下主流的支付渠道的支付方式，都是异步的。比如，我们来看一下支付宝的支付API：

很明显，我们创建订单以及支付流水应该是在第1步就完成，那么最终在支付宝完成支付，应当是在第7步才收到支付宝的异步回调通知。
毫无疑问，整个步骤是异步的。那么用我们的时序图把他画出来，应该是这个样子的：

再次声明：上面的数据模型以及流程࿰