第1页
千万级电商物流系统是怎么练成的
2014/10/25
http://weibo.com/pengtaoli
— 来自京东青龙系统的最佳实践
第2页
目 录
一、京东物流配送简介
二、京东青龙系统 1.0
三、京东青龙系统 2.0
四、京东青龙系统 3.0
五、青龙系统修炼总结
第3页
京东物流配送?
第4页
青龙就是京东物流配送系统
信息流
资金流
实物流
谁掌握了物流配送,谁就掌握了市场主动,在客户体验,提高效率和降低成本方面取得优势,从而赢得更多的用户。
15年中国电子商务史,就是一部送货速度的战争史,这是一场必须用百米冲刺的速度角逐的马拉松竞赛。生死时速,中国电商的配送速度之争。---《电商风云》
第5页
青龙业务流程
仓库&商家
分拣中心
车队
配送站/自提点/自提柜
配送员
客户
第6页
青龙系统1.0
第7页
青龙1.0核心子系统
基础服务
运营支持
分拣中心
运输管理
对外拓展
终端服务
商家客户端
自提点
配送PDA
站点ERP
3PL
路由跟踪
快速退款
PDA网关
接货中心
分拣PDA
分拣服务端
分拣缓存
预分拣
逆向物流
监控报表
运费结算
资金归集
合同管理
消
息
服
务
基础资料
GIS服务
运单服务
服务中心
第8页
青龙1.0系统架构
自动部署
监控报警
日志服务
DMS
B商家
财务
第9页
子系统间强依赖
TMS
运单
TMS
运单
TMS应用强依赖于运单系统,运单出现问题,TMS也不可用;
运单是基础模块,基础模块的不可用导致系统不可用。
第10页
子系统间强依赖-解决之道
将系统间依赖关系转换为弱依赖(异步方式);
如果不能完全转换为异步调用,需要将子系统进一步切分。如将运单切分为稳定的只读接口和回传接口,TMS强依赖于稳定的运单只读接口,而回传接口修改为异步方式。
TMS
运单
只读接口
运单
回传接口
异步
A
B
异步
同步
第11页
子系统间依赖要点
系统间尽可能异步调用;
对调用设置合理超时时间;
对被调用方设置并发限制,特别是Web调用(Nginx & Tomcat);
TMS
运单
只读接口
运单
回传接口
异步
同步
超时设置
并发限制
第12页
灰度部署
灰度(华中)服务组
系统更新首先更新灰度(华中)服务器,华中生产确认没有问题后,再升级全国服务,避免Bug引起全国故障。
第13页
服务隔离(柔性控制)
灰度
对外
全国
运单服务
硬件隔离:利用硬件对服务进行隔离;
软件隔离:利用SOA服务对内部调用进行分组隔离。
第14页
统一监控&统一日志
青龙生产系统
统一监控
业务监控
接口监控
青龙应用
日志分块
青龙应用
统一日志
日志分块
第15页
1.0的双十一:遭遇战
预计单量是多少?
系统压力多少?
哪些是关键环节?
系统怎么监控?
有应急预案吗?
。。。
OMG!这么多需要考虑?
第16页
青龙系统2.0
第17页
第18页
青龙2.0核心子系统
基础服务
运营支持
分拣中心
运输管理
对外拓展
终端服务
快递网站
商家客户端
客户拓展
自提点
配送PDA
站点ERP
3PL
自提柜
路由跟踪
快速退款
PDA网关
流媒体
运输PDA
车辆管理
车辆调度
全网路由
接货中心
分拣PDA
分拣服务端
分拣缓存
预分拣
逆向物流
物料管理
质控管理
知识库
监控报表
时效管理
运费结算
资金归集
合同管理
开
放
A
P
I
/
消
息
服
务
基础资料
GIS服务
运单服务
配送门户
路径规划
服务中心
绩效管理
第19页
青龙2.0系统架构
自动部署
监控报警
日志服务
DMS
B商家
财务
第20页
PDA 网关
TMS Worker
TMS任务表
Redis
调用Web接口
插入Redis队列
取出任务处理
。。。
taskA
0 1 。。。n-1
适配层
适配层
解决方案特点:
兼容性:兼容已有数据库方案,可以平滑升级;
安全性:重启等不会丢失数据;
效率:高并发,支持批量处理等;
支持防重注;
支持Redis故障(自动和手动)切换;
。。。
基于Redis的分布式调度
第21页
基于Redis的分布式缓存
解决方案既保证了缓存的高效性,又保障了数据的一致性。
缓存分为两部分:集中式缓存和分布式缓存;
集中式缓存为Redis分片组成的集群;
分布式缓存存在于各个应用,也分为两个部分:Redis Pub/Sub通知和直接基于内存实现的缓存。
接口服务以基础资料为例,调用接口应用以监控应用为例。
基础资料接口服务
Redis消息通知集群
Redis缓存服务集群
监控应用
版本
结果
。。。
监控应用
版本
结果
监控应用
版本
结果
第22页
青龙2.0系统技术优化
青龙团队对系统持续技术优化,包括SOA框架,分布式调度,Redis,MQ,分布式MySQL等,有力的保障了系统稳定运行(容错性),提升了系统效率(性能)。
第23页
GIS应用创新
第24页
2.0的双十一:阵地战
当你预计了最大单量,预测了系统最大压力,对于关键环节胸中有数,也有强大的系统监控,是不是就可以高枕无忧???
艾玛,你依赖的兄弟系统出问题了!
第25页
青龙系统3.0
第26页
第27页
青龙系统模式
接货服务
产品服务
应用访问层
注册服务
投放平台
GIS服务
运单服务
规则引擎
核心服务
全程跟踪
数据存储
数据清洗
数据挖掘
数据支撑
数据检索
青龙平台
JOS
SAF
接口
京东平台
易迅平台
O2O
C2C
拍拍
社会化订单
B2C
垂直电商
京邦达
物流云
三方物流
管理服务
财务结算
监控报表
客户管理
统一门户
合同
管理
认证服务
路由服务
第28页
系统分层
第29页
分布式部署
1. 支持多机房部署;
2. 单个机房出现故障,可以快速平滑进行切换。
第30页
用户体验提升
配送员使用的POS一体机长时间以来一直注重功能的实现,用户交互和UI设计有待提升,本次从多个个方面进行优化,包括:
1)人机交互更加人性化,操作更加简单化;
2)增加移动端的元素,页面更具美感。
第31页
配送员主页
包含头像、姓名、星级评价、电话、配送站点,部分优秀配送员还会有个性签名和优秀勋章。
点击电话可以直接拨打。
第32页
3.0的双十一:不过是演习
事前准确预计单量和变化趋势;
预测系统压力,并进行多次模拟军演;
对于关键环节胸中有数,并对技术方案进行专家评审和优化;
建立强大的系统监控,细致到每个方法调用;
制定可操作的应急预案和系统降级方案,确保任何情况下生产不中断;
安排24小时值班和现场实时沟通,快速对出现问题进行解决。
原来也可以这么简单!
第33页
3.0的双十一:问题举例(1)
对应架构升级方案,需要进行相关性能测试,并且,要有线上回退开关:
尽可能提前进行性能测试;
核心系统,尽可能进行线上压力测试(军演);
至少应该有对容量和性能的相关计算,以及应对方案(回退&降级)。
第34页
3.0的双十一:问题举例(2)
接到报警,团队紧急集合讨论;
可能决策:
1,不更换:避免更换风险,后期运行中可能有数据库Crash风险;
2,更换:有可靠紧急预案,更换过程中数据库有Crash风险,但是风险较低,后期可以保障稳定运行。
2014/11/10 20:00 核心数据库存储一块硬盘损坏!!!
决策:启动数据库硬件故障预案,确认可以安全执行,之后决定进行硬盘更换;
过程:
1. 22:00进行硬盘更换;
2. 00:30数据同步完毕,问题解决。
第35页
青龙系统修炼总结
第36页
青龙系统修炼目标
高可靠
高效
核心功能
数据精准&决策智能化
平台化&社会化&行业标准
第37页
青龙系统修炼模型
第38页
欢迎加入
欢迎加入
联系方式:
邮件:lipengtao@jd.com
微博:weibo.com/pengtaoli
第39页
谢谢!
Thank you!