京东到家订单履约时效系统演进

一.背景

二.系统整体架构

1.系统架构

2.上下游关系

三.到家时效系统迭代

1.早期旧时效

2.业务增长带来的时效问题

3.解决时效问题-时效迭代

4.提升履约率

1.手动控单

2.自动控单

5.商品维度时效：

6.系统最终业务架构

四.总结

一.背景

京东到家作为一个即时零售的电商平台，不仅有万千好物供消费者购买，同时提供1小时送达的极致服务体验,其中订单时效是重要一环。时效系统提供了整个订单的履约时效计算服务，其主要职责是对即将履约的订单计算出各环节需要花费的时间，并将结果服务于购物车，结算页，订单生产，售后，搜索推荐等系统。其主要场景为 ：

• 正向履约：计算出即将履约订单的各生产环节所需时间,将结果返回给门详列表页,购物车,订单等系统，从而有效管理用户预期。

• 逆向履约：在用户产生售后订单时，计算出售后订单所需时效，将结果返回给售后等系统。

• 履约保障：当门店履约能力不足时，如:恶劣天气,运力不足,大促爆单,疫情等情况，通过调整时效来保障履约。

二.系统整体架构

1.系统架构

主要包括日历计算服务组件，缓存，worker和mq以及服务监控和日志管理等组件。

组件简介:

• 监控系统:采用统一监控与告警服务平台，可以达到秒级监控、多方位监控、服务 告警 、全链路跟踪。

• 日志管理:日志采集与查询服务

• 消息中间件:使用京东的mq中间件，实现业务解耦和数据异步同步等

• worker组件:使用TBSchedule分布式调度引擎框架进行任务的分发和执行

• 配置管理：到家自研的统一配置管理组件

• 存储:jvm缓存，redis缓存，数据库

2.上下游关系：

在订单生产中，时效系统与门店，商品，实时数据等系统交互，获取计算所需数据，将时效计算结果服务于门店列表页，商品详情页及订单生产，售后等系统。

三.到家时效系统迭代

1.早期旧时效

由于平台早期的单量不大，时效计算仅依赖于门店时效配置。主要通过“订单时效” 设置 和“定时达间隔”设置计算。订单时效设置用来描述整个订单的履约时长。

基本的计算逻辑为  预计送达时间=当前时间 + 订单时效。

2.业务增长带来的时效问题

随着公司业务不断增长，单量不断增多，旧时效暴露出的履约问题渐渐明显，这些问题已经影响到订单履约。其核心问题如下：

配送时效不准确：

1. 履约超时责任不清 : 平台在考核订单履约时，对履约超时的订单存在判责不准确问题。通过静态配置计算出的时效没有明确区分出拣货时间和配送时间。

2.骑手配送时效不合理 : 骑手配送时长与配送距离成正比，门店坐标和收货人地址坐标间的距离近则配送时效短，距离远则配送时效长，不能通过配置统一设置。

3.时效因子少: 影响履约时效的因素很多，如 恶劣天气，运力不足，大促，订单中商品种数多，收货人地址送达较困难等，这些都会影响到履约时效，也是时效计算应该考虑的因子。

4.时效粒度较大 :旧时效中时效力度为小时级，这种粗粒度的时效，对于用户体验差。

3. 解决时效问题- 时效迭代

为了解决旧时效诸多问题，提升订单履约率，时效系统进行了迭代。

1.解决超时责任问题 ：为了解决履约超时责任不清问题，增加了 【拣货时长】配置，作为时效计算重要参数。拣货时长明确定义出商家的拣货用时，根据拣货时长可以计算出 每个订单的“拣货截止”时间,从而可以明确知道商家是否拣货超时。再通过门店地址坐标和收货人地址坐标间的骑行距离获得骑手配送时间，则可知晓配送是否超时。由于区分了超时原因，及时制定优化方案，因此履约得到一定提升。

2.解决骑手配送时效不合理问题 : 新时效中根据门店坐标和收货人地址坐标的骑行距离获得骑手配送时间,从而精确了配送时效，远距离订单履约超时问题得到了很好的解决,履约率得到提升。

3.解决时效因子少问题 ：新时效引入了很多计算因子，如恶劣天气增加延迟时效，运力不足增加时效，难送poi增加时效，节假日等。

4.解决时效粒度大问题 :新时效采用分钟级时效更精确,用户体验更好。

新时效计算逻辑：

时效迭代上线后，履约率得到提升。用户体验也得到了改善。

4.提升履约率

4.1 爆单

随着平台业务不断发展壮大，大促活动越来越多，活动的力度也越来越大，随之带来了一个严重的问题，就是大促期间的履约率很差。有些门店因为单量过多，产能无法跟上，采取了关店或修改营业时间等措施。造成了很不好的用户体验，也影响了正常的生产。

4.2 控单

为了解决大促爆单问题，时效系统增加了控单能力。在门店出现产能不足时候，需要适当调整时效，来保障门店的正常生产。如门店运力不足，产能不足，大促爆单等，时效系统会根据运营设置的控单配置，计算哪些时段需要被控，被控的时段用户将不可选择，从而将高峰期的订单导流到低谷时段。达到削峰填谷，导流订单的目的。

1.手动控单

控单计算逻辑

时效系统 计算出时效列表后，再获取每一时段时效的实时单量与门店配置的控单数量对比，判断当前时段是否需要控单，如果实时单量大于了配置值，那么这一时段将被控。

控单逻辑示意图

控单系统上线以后，大促爆单影响履约的问题得到很好的解决，商家不需要在产能无法满足单量的情况下下线门店或调整营业时间。但也随之带来了新的问题:

1.控单设置是人工开启的，当门店产能好转或不需要控单时，往往不能及时关闭。

2.控单设置的单量，是人工估算出来的，门店产能变化后需要及时调整，需要人员的实时关注，比较耗费人力。

3.对单量的预估存在不准确的问题。

2.自动控单

由于人工设置的控单配置，存在很多的不足，时效系统针对控单业务进行了新一轮的迭代，就是现在的自动控单。自动控单简单来说，就是模拟人工设置的过程，通过一套智能算法，实时计算出控单设置列表。当履约指标数据变化后，控单设置会自己动变化，从而可以及时调整控单数据。

自动控单完美的解决了手动控单设置带来的诸多问题，但自动控单本身也存在一些不足，比如控单延迟问题,由于自动控单必须监控到有履约差的数据才会做出相应的配置调整，所以整体调整比较后置。目前我们采取了 手动控单 和 自动控单相结合的策略，效果比较理想。

5.商品维度的时效：

由于平台业务的发展，商品品类越来越多，商品对时效有一定的要求，时效系统增加了对商品维度的迭代。

1.加工类商品时效支持。增加品维度的加工时长设置,作为时效计算因子，如蛋糕类需要加工时长。

2.预售品的支持。对于一些预售品，增加预售时效计算能力。

3.多sku增加拣货延迟。对于sku种类繁多的订单，时效系统会适当增加拣货时间。

6.系统最终业务架构

时效系统经过了几次大的迭代后，目前主要有三块核心业务逻辑。首先是商家拣货履约，这一块主要是针对不同行业不同商家拣货用时的计算逻辑迭代,其中还包括商品种类多，加工商品，预售品等业务逻辑迭代。其次是配送履约，配送履约主要对骑手的配送时效进行迭代，如配送的距离，天气，poi等因素。最后是 履约保障,主要是针对大促，门店产能不足，运力不足等情况，通过调整时效来保障履约，保障订单的正常生产。

四.总结

随着业务的不断发展，用户对履约时效的要求越来越高。时效系统还需要不断优化,一些场景目前还需要人工干预,如: 控单场景中需要人工配置一系列参数，门店的产能发生变化场景中需要人工调整时效设置等。对于这些问题，目前我们也在尝试使用大数据与算法结合,基于历史订单通过机器学习更加精准的计算时效。期待未来我们的时效会更加智能化,精细化，用户体验越来越好。