- 快召唤伙伴们来围观吧
- 微博 QQ QQ空间 贴吧
- 文档嵌入链接
- 复制
- 微信扫一扫分享
- 已成功复制到剪贴板
唯品会供应链技术架构的实践
展开查看详情
1 .www.vip.com 唯品会物流信息部 应用架构实践总结 1
2 . 物流信息部系统大事记 接入MA-SCALE系统,唯品会有独立的wms系统,满足单仓订 2011/7 单2-4w单 2012/5 MA-SCALE系统改造, 满足单仓订单7-10万单 2014/1 随着业务的发展,开始自主研发wms2.0 2014/5 ODS,CIS开始研发 2014/7 Wms2.0上线,ODS,CIS系统上线 2014/11 Wms2.0全国部署上线 2015 通用wms的研发上线,开放仓储和配送 2
3 .混沌期:2011之前 B2C 在这期间,公司属于 启步阶段,业务量不 是很大,没有专门的 物流部门,ERP承担 了订单履约的全部功 ERP系统 能 3
4 .小结 和其它创业公司一样,仓储物流的管理由ERP代管。 没有专门的仓库作业流程软件,订单量不大,属 于粗放式管理。 4
5 .创业期:2011-6-- 2012-5 VIS ERP统 WMS 随着订单量的增加,公司租用专门仓库,ERP的功能进行拆 分,引入MA的仓储系统,单仓日订单量为(2-4w) 5
6 .创业期: 2011-6-- 2012-5 B2C VIS WMS 由于系统是从ERP中分了出来,wms承担了部分原有ERP的功能 6
7 .创业期: 2011-6--2012-5 B2C VIS WMS 由于系统是从ERP中分了出来,wms承担了部分原有ERP的功能 7
8 .小结 在Sku数增加,单量增加,需要专门的仓库进行存 放,以及研发资源有限的情况下,购买成熟行业相近的 wms软件,继续发展。 传统的wms管理的每日的入库,出库相对较少,订 单的履约时效一般都不是很强。通用wms软件的厂商,其 设计的通用性是以牺牲性能为代价的。在订单量少,对系 统的性能要求不是太强,业务变化也不是复杂时还能满足。 8
9 .成长期:2012-5---2014-1 随着全国各地新开仓库的增加,我们的系统开始变得复杂了 9
10 .2012-5---2014-1 在这期间,随着业务的发展,单仓订单量增加,新开仓 数由原来的1个扩展到3个。业务流程也发生了变化。 在这过程中,物流事业部对MA wms系统进行不停的修 补和业务的积累。由于是购买的第三方系统,物流研发 部碰到了一些问题。 10
11 .成长期:2012-5---2014-1碰到的问题 业务变化快,数据量增加也在加快。Wms系统面临一系列的挑 战。 SCALE自身 大量的查询影 产品功能实现 响正常业务 效率差 部分复杂业务, 接口出错难以 需要一次性写 定位问题 十几张表 11
12 .成长期:2012-5---2014-1我们的改善对策 使用大量存储过程实现SCALE原效率较低的功能 搭建119报表查询系统把报表查询从业务剥离。搭建DB从库, 非实时报表查询从库 将复杂业务进行拆分,部分业务操作通过数据库自动任务+ 存储过程异常实现 接口模块增加配置开关和跟踪日志,实现接口业务的灵 活配置和出错日记 数据库由oracle换为mysql,搭建廉价的可扩展的DB架构 12
13 .小结 MA-SCALE上线10个月以后,单仓日均7-10万单,业务流程面临大的 改造,日单量成倍增长,系统业务实现和技术性能都面临较大挑战。在原 MA-SCALE上进行修改满足需求已经很困难。需要开发新的系统来满足性 能和业务的需求。 随着订单量上升,sku的增加,这是每一个购买第三方wms系统面临 的问题,继续修补还是另起炉灶。 在权衡修补的成本和将来业务发展上的 支持上,需要重新进行抉择。我们选择了另起炉灶。 13
14 .成熟期:2014-1---2014-10 决定开发新的wms2.0系统,但我们不能让MA系统出现的问题再现 产品客制化功能代码 结构混乱 大量用户使用,远程 存储过程大量应用, 桌面方式导致部分应 数据库服务器负载压 用服务器性能差 力大 SCALE的RF功能性 能无法使用 14
15 .成熟期: WMS2.0新架构改进 所有客制化功能采用MVC架构重新构造 订单表/工作表/交易日志表等关键业务表按照业务进行拆表,有效降低 DB的并发压力 业务数据进行二级归档策略,根据业务情况分别进行接口,入库,出库模 块的表数据归档,确保业务表数据数量可控,降低数据库服务器压力 并发性高的OQC操作开发WEB版本,降低远程桌面的APP服务器性能压 力 重新开发所有RF,将其改为本地化应用 15
16 .成熟期:同时对系统进行扩充和拆分 随着开仓数不断的增加,以及订单履约时效以性增强, 需要新的系统来协调订单的生产,运单的发运,物流信息部引 入新的成员。 wms拆分为:主数据库,iqc和oqc三部分 CIS:中心库存。负责更高层次的库存管理 ODS:订单履约调度。 TMS:内外APP接口分离部署,接口集群部署 16
17 .成熟期:系统拆分后架构的变化 17
18 .成熟期:引入CIS作为中心库存概念 VIP自营仓库库存 3PL仓库库存 标准化库存查询接口 数据使用者 供应商仓库库存 库存整合逻辑 其它标准化接口 库存对接接口 18
19 . 成熟期:现状 • 将系统升级为mvc模式,业务,展现和数据层进行了分离,代码维 护简单。 • 在应用层上整体得到水平扩充。目前单仓当日最大出仓量30w左右。 • 由于上线时间短,系统的稳定性和性能还需要持续优化。 19
20 .小结 系统自主研发升级改造后,对整体的性能有了很 大的提高,对业务的响应也及时。但随着单量的上升 (目前单仓当日最大出仓量30w),如果维持当前业 务模式(闪购模式)下,重构优化,应当可以达到 50w。但系统将变的非常不稳定,任何操作节点的变 化都会影响到整个系统的性能。另外所有数据都存储 在一个数据库。对数据库的压力也会增大。 20
21 .展望:2014-10-- 公司销售目标在变,对物流平台的需求也在变。 我们仍需 21
22 .物流平台总体的需求 • 集中化管理和部署 • 接入第三方库存管理 • 层次化的仓库管理 • 允许第三方租用WMS(SAAS) • 可以接入不同平台(渠道)的订单 • 一套系统同时满足集中和分仓部署 – 大型仓库,每个仓库部署一套 – 小的仓库集中部署 • 有些数据处理需要及时回传 • 全国配送系统的搭建 22
23 .重新规划后各系统的功能定位和数据流向 23
24 .新的架构新的起点 Region LoadBlanceN Region LoadBlance1 Region LoadBlance2 监控平台 性能监控 Camel Node1 Camel Node1 Camel Node1 ….. 流程监控 Came watch HttpClient HystrixClient Jersey Client 日记收集 web RF Rich Client 24
25 . 开源技术列表 • Dropwizard:微服务框架 – Jetty – Jersey – Jackson – Guava – Logback – JDBI • Camel:组合微服务 • Mustache / Handlebars :前台展示 • Restsuperman:监控 • Hystrix:服务的降级和弹性 • Kafka:消息处理 • Venus:数据库分库分表 • …. 25
26 .欢迎大家加入vip 26
27 .27