转载

京东物流出问题了？褥了30块羊毛 & 浅析系统架构

本人亲身经历，但后续的流程分析都是个人猜测的，毕竟没有实际做过这块的业务。

订单物流阻塞经过

火热的双11刚刚退去，截止今日，我在京东购买的矿泉水终于到货啦，下单两箱还只收到了一箱 :( ，从下单到收到货过去了14天，足足两周的时间。

我从11-20号开始与京东客服联系，直到11-25整个购物体验才完成，也因为京东没有按照约定重新发货，算是补偿了我3000个京豆。

朋友们，不会不知道京豆是干啥的吧，100个京豆相当于一块钱，1000个京豆相当于10块钱，3000个京豆就是40块钱。

可那不是现金有啥卵用，你不会不在京东购物吧，下单的时候就可以选择用京豆来抵用一部分下单金额了。

所以一般购买商品后鼓励你去评价，文字超过一定字数且上传了购买商品的图片，就能得到比如20个京豆。京豆积少成多，就可以下单抵用现金了。

废话不多说，回到正题！

双11我在京东下单，自营商品的订单一般都是次日达，因为双11物流紧张，所以下单后提示11-13日送达。

11-13日：

遗憾的是，11-13日并没有如期送达，查看订单物流，增加了一段温馨提示：「由于销售火爆，根据目前情况，订单预计11月16日送达到您的手中」，额~，当然大家都能理解，原来京东商品这么「火爆」，毕竟双十一累积销量2000亿呢。

11-20日周三：

问题是到了11-16日并没有送达，我把这个订单差点忘记了，11-20号突然想起来了这件事，上京东确认了订单，才发现还是那个「销售火爆...」的提示呀！竟然没有给我送货。。。

然后在线联系人工客服，说了一下情况，客服态度很好，两箱水拆分下单后因已经拆分为了两个订单，有两个订单号，为了表示歉意，每个订单号补了500个京豆，1000个京豆到手了。

然后，客服跟我说，已经给我催促仓储发货了，让耐心等待一下，预计第二天就能到了。

11-21号周四：

可惜到了第二天，并没有像客服MM所说的那样如期送达，反正已经晚了，心想也不差这一天儿，还赠送了京豆，再等等了...... 。

11-22号周五：

然而，到了11-22号还是没有配送物流通知，订单中的分拣流程没有完成，这是什么操作？？

当天继续联系客服，问了是什么原因，又来「话术」：小妹已为您催促正在发货中，此时我有点怀疑了，可能这个流程本身就中断了，需要人工来协助处理补单流程。

此刻，「客服的嘴，骗人的鬼」终于用到这了~

同时，京东客服升级来了个电话沟通，诚挚的表示歉意，说是仓储这边发货有点问题，正在重新补货中... ，预计明日就能送到，请注意查收！

11-23日周六：

「客服的嘴，骗人的鬼」再一次用到这了~

周六仍然没有收到货，而且订单里的物流配送流程一动也没动~

京东物流出问题了？褥了30块羊毛 & 浅析系统架构

11-23日周日：

周日仍然没有收到货，而且订单里的物流配送流程一动也没动~

看来没很好的注重用户体验嘛，再次在线联系客服，每次接线的不是同一个客服，所以每次都要求提供一下订单号，很烦，此时很无语了，本用户表示很生气啊，自己查！

然后呢，客服又说已经重新补发货了，并且这次竟然不给我大概的送货时间点了，因为他不相信到底有没有真的去补发货操作了，补发货这个操作多半客服是没有权限的。

另外，解释到因订单延迟时间过长，又一次非常的抱歉，给申请了1000京豆，不过这次京豆并不是实时到账的，需要经过审核流程。

11-25日周一：

早上已经在地铁上了，收到了京东快递小哥的来电，但是只到了一个订单的货。查了一下另外一个订单物流状态仍然一动没动 :(。

最后，客服专员再次电话联系，解释到这个订单给疏忽了，建议我重新下单，然后这个订单走退款流程。并且再一次给予了1000京豆的补偿 :)。

物流系统异常分析：

上述物流配送异常流程中，想了解故障原因，电话中我也有意识的去问一下客服，是不是某个环节有这样的问题，但是从客服那里只能给到说仓配流程有问题，具体他们也不是很清楚了，全都是针对用户的话术，避免说错话。

作为个技术人，通常得思考一下问题背后的原因：

到底是哪个环节出现的问题
出现这样问题的原因
对用户的影响及应对方案
如何能避免类似的问题发生
...

物流系统介绍

由此次问题引出，我还特意去查资料看了一下京东物流的系统架构演进过程。记得当时京东物流招人非常猛，作为一个内部非常重量级的项目投入了很多研发人力。

在2012年的时候京东内部开始对物流系统进行设计改造，那时访问量应该还不算高，最初的系统还没那么复杂。新改造的物流系统：「 青龙系统 」

京东物流出问题了？褥了30块羊毛 & 浅析系统架构

青龙系统演进过程如上图所示，它的系统发展至今，已经包含了分拣中心，运输路由，终端，对外拓展，运营支持等五十余个核心子系统，构建了完善的电商物流体系。

并且青龙系统中总结了一些最佳的实战原则，如下所示：

京东物流出问题了？褥了30块羊毛 & 浅析系统架构

这些系统设计原则我认为对任何系统都是通用的，值得我们一起学习的:

高可用

选择合适的架构方案；大系统小做，服务拆分；并发控制，服务隔离；灰度发布；全方位监控报警；核心服务，平滑降级。

高性能

缓存和异步化，同步接口异步化设计；接口数据缓存化。

接口数据缓存化是非常重要的手段，对Redis缓存系统的很好的利用，构建了具有自己特色的缓存体系，很好的支撑了业务发展。同时，还发展了基于Redis的分布式调度系统

数据一致性

高实时性/高一致性，高实时性/低一致性，低实时性/高一致性，低实时性/低一致性。

针对具体的业务，可以匹配到具体的数据场景，找到对应的解决方案。要客观的结合业务分析，选择最适合的一致性方案，并不是高实时性/高一致性就好，成本是很更贵的。

用户体验

东哥要求过任何人不能对用户体验提升的建议说No。用户体验主要遵循MVP原则和动态运营的原则。

MVP原则：也就是敏捷开发中的迭代思路。即快速迭代，核心需求线上，及时的反馈和改进。

动态运营：跟MVP原则强关联，上线后收集并分析用户数据，使得产品落地的设计符合用户的需求，不符合设计要求的就要不断的持续调整，是一个动态持续的过程。

物流分拣系统

简单介绍完了物流系统的演进过程及架构原则，还是回到主题，到底是哪个环节出现了问题？

需要了解整个购物链路的各个环节：

京东物流出问题了？褥了30块羊毛 & 浅析系统架构

用户整个购物流程经过以上几个关键的流程，已经生成订单号并且已经支付了，流程到了订单中心。

各个系统都是分布式部署的，订单中心会发送一个MQ消息给各个下游系统，积分系统增加积分京豆等，促销系统发放优惠券等，仓储系统接收到MQ消息进行处理，调用物流系统生成物流单，通知到配送站，由配送员送货。

结合一个火爆的订单，看一下订单跟踪过程：

京东物流出问题了？褥了30块羊毛 & 浅析系统架构

该订单在仓库处理中已经打包完成，订单在京东【北京李桥接货仓库】分拣完成。注意到了「分拣」二字，顺便看了一下正常的订单流程，会经过多个货仓的分拣过程，最终会分拣到离用户最近的货仓。

所以，猜测，这笔订单的问题就是在配送前的分拣系统处理过程中出现了异常情况。

青龙物流系统其中就包括了预分拣流程，如下所示：

京东物流出问题了？褥了30块羊毛 & 浅析系统架构

当用户下单后，首先必须是经过预分拣环节，但是根据最新的订单跟踪过程看，是先进行了仓库打包处理，然后进入分拣流程。

分拣系统接收到订单，根据不同的订单进行规则匹配，分配站点，处理成功后生产包裹打印标签。

订单无法被正常分拣完成，将无法生成订单：

京东物流出问题了？褥了30块羊毛 & 浅析系统架构

想必我的订单大概率就是在分拣环节出现了问题 ~

分拣系统的目标：

京东物流出问题了？褥了30块羊毛 & 浅析系统架构

其中可用性要求是达到99.99%，4个9的可用率呢，看来很不幸啊，不可用的0.01%小概率事件偶发在了我的订单上。

京东物流出问题了？褥了30块羊毛 & 浅析系统架构

预分拣算法：

京东物流出问题了？褥了30块羊毛 & 浅析系统架构

1、经验值

只适用于同一个地址多次购买，依赖于第一妥投地址。

2、特征值

需要提前人工维护关键字，依赖于关键字的准确性。

3、特殊配置

需要提前人工配置，依赖于该区域是否有特殊配置。

4、GIS

通过GIS技术精准的匹配地理位置。

上述都没有匹配到，那么只能走人工处理流程了。

预分拣系统架构：

京东物流出问题了？褥了30块羊毛 & 浅析系统架构

订单系统下发服务，默认会进入到预分拣系统，不同的订单有不同的匹配规则，匹配规则使用开源的Drools来实现的，规则匹配完成，会按照预分拣算法匹配，优先匹配到离用户最近的地址，返回自动预分拣的结果。

一旦回传失败，应该会有预警，需要人工介入来协助完成预分拣，将结果返回给订单服务。

预分拣服务系统交互流程：

京东物流出问题了？褥了30块羊毛 & 浅析系统架构

分拣服务使用Tomcat分布式部署的Worker进程，完成后，将结果写入到任务库，回传服务从人物库抓取分拣结果回传站点。

下图来源于网络，不是很清晰了：

京东物流出问题了？褥了30块羊毛 & 浅析系统架构

其中预分拣服务接受订单服务都是分布式部署的，并且针对不同的订单做了服务隔离，使用应用服务器是Tomcat；全文检索使用的Solr，可能目前已改进为流行的ElasticSerach架构了；分布式缓存使用了Redis集群；预分拣算法中的地址库、特征值、配置都对应了自己的Worker集群，也是做了服务隔离，每个服务分布式部署，最终将结果写入到MySQL数据库中；预分拣回传站点单独的Worker集群，用来从数据库抓取分拣数据，返回给用户站点。