从双十一看天猫订单数据对接及订单流程优化课件.pptVIP

杨大伟 软件工程师| 小米科技 MP: + Email: 内容总结 ArchSummit全球架构师峰会（北京）2014。设计上的硬伤，不管消息是哪个环节丢的都不好搞，只能天天对数据。实时消化销售峰值（全天的销售计划的80%前一个小时完成来估算）。正在犹豫聚石塔的时候，天猫JDP抛出的橄榄枝。系统优化，没有最好的只有更适合自己的。首先然后做结构解耦 – 对业务发展的理解。相互制约的代码需要尽量分到不同的组。其次优化架构及中间件 – 做细。最后是优化代码 - 基本功。Cache Queue。订单生成/订单校验/订单推送等后端业务流转操作都是针对同一数据库的同一个表做操作，在实际的应用场景中会存在数据库资源争抢的情况，所以针对多场景的联合测试很有必要。在测试过程中发现，系统主要的瓶颈在数据库方面(24core的cpu最高可达约70%的资源占用率)，同时从库的延迟会达到2分钟以上。有了这个结果我们就可以放心的做生产线实际演练了。Cache Queue 做好前期沟通调配好资源 # 下午好，非常荣幸参加这次峰会,借此机会给大家分享小米电商的一点经验和体会 #一谈到电商，首先想到的是一些峰值系统，大数据处理等技术。今天给大家换个思路，聊聊躲在峰值系统后边的 业务流处理。 * 接下来的内容 很大部分是分享发展史。从无到有，从小到大的过程 希望能给想做电商系统的朋友，尽可能的提供一些有帮助的东西 先讲一下小米的一个特点是，在活动期间，商品售卖按产品的热度基本上是秒级或几分钟就抢空，峰值基本上完成活动的80%的订单销售 小米天猫旗舰店基本上也是这个特点，只要上活动，都会有一个瞬时峰值，峰值过了，基本上就没有问题了 基于这个特点我们一起来分享天猫与小米的对接过程 * 去年6月份接到开店通知，我们开始筹备，当时只有两个人来作这个事情，还是从别业务中抽出来的。当时人手就这么多，也没有过这方面的经验，业务部门也不知道要作的业务规模，以及对接的深入程度。基于这种条件与背景开始了第一版的对接。对接后问题多，不适合小米，去年双十一前作了第二次大规模改版，完成去年双十一活动。第三版是今年双十一前完成，基本达到实时处理的目标，完成深入对接，天猫后台操作完全可以在小米电商管理平台完成。对接基本上就是围绕这三次的改版。 标题加个双十一也正是是为了能够和今天的主题对应，当然一个系统做得好不好，还的看考试是否能通过，系统负载能力的体现，还是得靠能够带来峰值的活动，那就是双十一。 Qps 203 tps 46 写入6K,读2.5k * 上面提到了，第一版受资源限制，我们参考了其它公司的方案，完成最简对接，基本流程能跑通 第一版其实当初就是简单的入住，上线后大量的操作还是通过天猫的后台来完成，客服和财务人员工作量还是很大的。 并且这套方案无法去承载双十一这样的活动 * 产品总弄出来这些图来吓唬我们，这是第一版实现的对接天猫的业务流程图 * 这是天猫和小米订单涉及各种业务分支， 业务实现确实比较复杂 * 于是2013年7月份上线第一版，完基本业务流程 通过天猫的消息订阅，接收交易和退款消息，然后按照消息类型从淘宝top接口取数据，然后解析数据存储到对接系统的db 这个模型本身没有问题，问题在于对对接系统中从天猫获取订单性能低下，退款流程没有完全对接对小米 * 知道下面有好多天猫的朋友，讲这个之前我得特别说一下，这里没有吐槽 就简单说明一下我们遇到的问题，天猫对接商家都有自身的特点，不可能面面俱到。 而且天猫对小米的支持是非常给力的，我们也借鉴了很经验和技术。 我们第一版丢消息和取单慢的原因，是因为我们单量很大，这个方案很难满足我们现实情况 结果就是双十一前，必须改！ * 怎么改呢，目标是有的,就是实时消化峰值订单量，天猫有多少，小米就要有多少 于是我们开始选 方案，当时的可选方案有聚石塔，和JDP(直通港) 当时评估，JDP方案是对我们改动最小，实现的成本最低的。 直通港服务，所有数据都会全量 主动的 推送给商家，不用自动取抓任何数据。 这个方式对接确实轻松了很多 （目前可能是因为安全原因，这个全量数据推送已经没有了） * 这个是第二版的模型，区别在于直通港会下发数据给对接系统，对接系统可以直接把全量消息转成原始订单持久化到db中，订单系统再生成小米订单，接下的ERP流程 * 我个人的体会，这一版接入非常方便，而且降低了接入的成本。消息类别丰富，可以用来驱动整个业务系统。 真没什么缺点可言，至少13年双十一真的非常的给力！特别感谢孟铸和他团队的当时对我们的鼎力支持！ 这么好用，我们为什么要改第三版呢？ 直通港最后的问题在于没有团队继续去维护，一些bug长期得不到解决，最后14年4月份通知将下线。这个可能和天猫整体规划有关啦 接下来就是要去作第三版改版 *