物流系统的难题
菜鸟的物流系统脱胎于天猫、共享交易，系统之间存在着"打断腿连着皮"的紧密的联系，多年来双方配合默契，承担着整个泛电商业务最核心的链路。
随着集团业务的蓬勃发展，线上购物更加深入人心，在每年双十一订单峰值纪录不断被打破的背后，技术投入和成本也在不断增加，特别是近几年，支付的能力提升已经渐渐可以和下单持平，这对物流系统的压力也越来越大。交易和物流两者间密不可分的技术脐带逐步变成了缠绕在菜鸟脚上的链条。
双十一的巨大成本压力
仅分析 2015 年双十一峰值背后的业务数据，其中 0 点起创建的订单，在前一个小时完成发货的订单仅有几十万,相比支付订单量可以说九牛一毛，可以看出，支撑大流量高并发的订单创建，并非物流领域自身业务的刚需驱动，而更多的是为了保障交易-支付-物流链路的稳定。
再从业务场景上来看，物流在双十一是以单据驱动的核心业务，即发货。发货对应的是实物的实操业务，需要大量的人力物力投入，这种物理空间上的线下协同能力，具有流量相对平稳，无明显峰值的特点，整个业务流程复杂、业务执行周期长、参与角色较多。从用户的核心诉求来说，用户只关心交易订单是否成功创建，而物流订单是否能马上创建出来，并不是刚需。
因此，如果交易订单的创建峰值每年持续上涨，物流系统就需要对等部署同样的机器来保证同步链路的顺利执行，从物流业务的特点来说，这不是必须的，对一个非刚需的场景，每年投入大量的成本来保证同步链路，是非常不明智的，物流系统的架构升级已经刻不容缓。
RocketMQ——菜鸟架构师的选择
这也是菜鸟的系统架构师王维在 2016 年双十一前面对的最大挑战，那一年双十一的订单创建峰值要从 15 年的 18 w 涨到 30 w。他要做一次意义重大的升级，让交易和菜鸟的业务能更清晰的划清业务模型和链路，让天猫快速激增的系统流量不再让菜鸟系统追赶，让菜鸟能专注去完成物流领域内的事情，让天猫交易能更专注的保障交易链路的稳定。
在双十一订单峰值的要求下， DB 和 REDIS 显然不能满足异步解耦的要求，因此王维将目光锁定在了 RocketMQ 上，一个在阿里集团内部广泛使用的分布式消息中间件。
RocketMQ 在阿里巴巴已经经受了双十一多年的的洗礼，服务性能已经是世界领先水平，可以支持用户亿级的堆积，同时客户端也提供完善的 SDK 让用户能做到精确的控速消费，在架构解耦和削峰填谷上，有明显的优势。
使用 RocketMQ 做异步解耦，物流订单中心在满足自身领域业务的前提下，只要保持一个较高水位平稳消化支付的交易订单流量，无需承受交易支付的高峰，既可以减少大量的人力物力成本投入，可以规避同步依赖时的稳定性风险。两个系统保持良好的沟通，更加专注做好自己的事。简单说，如果交易创建的峰值是 50w/s, 持续 20 分钟，如果物流系统通过 RocketMQ 控制消费速度，比如保证 8w/s 的消费，那么也可以在 2 小时内消费完所有的数据，对用户来说，整个过程也是无损无感的。
与消息中间件团队深度合作，充分利用 MQ 削峰填谷的作用后，在 2016 年双十一前，通过 2 个的月的开发、测试、验证、灰度等工作后，王维成功推动了菜鸟系统架构从电商高并发向更加贴合物流作业的特点转型。16 年后，在电商持续攀高的下单峰值背景下(4 倍增长)，菜鸟物流系统峰值 QPS 保持不变，节省了大量技术成本，并且为未来多年的成本降低奠定了基础。
作者介绍：
周礼，花名：不铭，阿里云智能技术专家 。主要负责阿里云消息中间件的研发工作，关注分布式消息服务、云原生等技术方向。
本文转载自公众号阿里巴巴中间件（ID：Aliware_2018）。
原文链接：
https://mp.weixin.qq.com/s/C5OosuY2pYhRu23RPXCegA
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论