以变应变，苏宁采购平台架构演进之路

会员服务 ·

以变应变，苏宁采购平台架构演进之路

2019 年 4 月 22 日 51CTO博客

“

在“智慧零售大开发”的战略驱动下，2018 年苏宁新开门店超过 8000 家，目前各类门店总数已经超过 1.1 万家，在线下形成了“两大两小多专”的智慧零售业态群。

同时构建了以苏宁超市、苏宁拼购为代表的线上平台。从而形成了线上多平台、线下场景多业态互联网化，不断打造跨线上线下全场景的消费环境和空间。

随之而来的是新增各式各样的业态带来的业务链路的多样化，以及适应行业的急速发展带来业务需求的多变化…

总之一切都是“变”的，作为自营采购的核心系统采购平台，是如何适应这些变化？

下面会通过采购平台发展的三个阶段，介绍我们是如何通过积极的“拥抱”变化，走出自己独特的架构演进之路。

第一阶段：系统搭建&功能完善期

采购平台是基于 2006 年上线的 SAP-R3 采购管理模块搭建的。

SAP-R3 作为苏宁信息化历程上重要里程碑，为苏宁的飞速发展曾立下汗马功劳，但随着多元业务急速发展，已经不能很好的满足业务的多变性和支撑新业态的发展。

就采购管理而言，SAP-R3 未与商品规划、选品等前置管理环节衔接，无法在此基础上开展采购业务。

另一方面 SAP-R3 中采购和财务相关业务耦合紧密，牵一发而动全身，无法支持各业态新的业务的快速部署，再就是存在操作复杂，培训学习成本高的问题。基于以上的问题，2015 年开始搭建基于 Java 的自主研发采购系统。

方向已定，同时困难也是显而易见的，SAP-R3 作为已经运行 9 年多的系统，已经有很多业务在上面运行，同时与大量外部系统有关联，系统关系错综复杂。

新系统的切换，首要考虑的是保持业务的持续性，平滑的过渡尽可能降低对外部系统的影响，这对我们来说也不亚于“在行驶的汽车上换轮胎”。

综合各种情况考虑，最终确认新系统的切换方案：第一步新系统提供各种创单以及管理功能，提供体验更好的服务，SAP-R3 系统继续承担调度功能，双系统并行，业务逐步切换。

如上图所示使用 R3 管理采购业务、订单调度、账务库存，对现有系统架构、库存结构、库存核算没有改动，风险相对可控，投入资源相对较少，虽然离去除 R3 的目标只算迈出一小步，但对于保障业务的稳定性是值得的！

确定好方案以后，着手新系统的框架搭建，考虑系统的可扩展性和稳定性，将模块功能独立化，类似微服务的概念，将业务模块采购，退厂，调拨，样机&不良品，采购需求作为独立应用部署，降低相互之间的耦合。

同时部署一个资源能力系统为各个业务系统提供统一的公共服务，主数据服务，权限服务，降低代码的重复度。

系统结构如下图：

系统搭建完成后，随着系统的平稳运行，第一步工作暂告一段落，2016 年开始第二步的架构改造：去除 SAP 的中转，由采购平台作为核心调度，真正承担对物流和库存的调度！

如果说第一步改造如同行驶中更换“轮胎”，那么第二步的改造，涉及整个链路上的核心的调整，就如同行驶中更换“引擎”，尽可能保障业务的无感知切换仍然是第一位的，切换过程采用双链路并行措施：试点+链路开关。

一旦发现试点的新链路功能有问题，可立刻切换到老的链路上，保证业务正常开展。

另外作为核心调度的系统，如何保证数据流转的闭环，可追溯，安全是必须要考虑的。在原有的系统基础上补充了操作日志系统，便于业务操作数据的追溯。

第二阶段：功能突增&业务爆发期

第一阶段主要是系统搭建和功能迁移，2017 年以后的系统的重点转移到提升用户体验，以及支撑新业务的急速发展。

主要从系统功能架构，数据存储架构，业务架构几个方面做出优化改进：

系统功能架构优化

为提升功能的丰富程度和体验，加上对新业态的支持，新增很多创单入口，创单逻辑本身复杂度很高和外围系统的交互又很多，加上项目周期短，前期都是基于已有的功能重新做一套。

虽然降低了对已有功能的影响，但是带来运维的复杂度成几何级提升，有时涉及一个创单共用逻辑的修改往往要改近十几个地方，开发容易遗漏，测试也苦不堪言。系统功能的架构优化提上日程。

针对上述情况和系统特点，我们采取的技术方案：服务原子化，功能积木化。

将一些基础服务，简单而言就是将创单逻辑分解成基础服务，新的功能基于基础服务进行积木式组合，如下图：

基础服务层提供独立的基础功能保持原子性，第二层服务组合层，主要考虑一些业务的功能实现。

虽然功能入口不同，但是业务逻辑上有很多一致的地方，为方便业务流程层使用，将业务上关系紧密存在先后顺序的原子服务耦合在一起。

业务流程层就按照业务需求将原子服务和服务组合搭建成一套完整逻辑。分层的好处就是对于新业务能实现快速迭代，另外涉及一些节点改动，只需要在基础服务层或者组合层做改动即可，不会再存在漏改的可能了。

系统存储架构优化

系统搭建初期，考虑到业务数据的量级，采用了分库+分表的方案。后来实践证明这并不是个好的方案，增加了系统运维的复杂度，每次的发布都要改动很多地方，极易出错。对数据库的动态扩展也带来很大复杂性。

经过技术内部讨论，果断将分库+分表改成只按模分库，按模分库可以保证每个分库上数据的量级差别不大，一旦量级达到需要再次切分的时候，可以将数据库动态扩一组。

目前公司自研的持久层组件 DAL 支持多次路由，代码层无需改动，只需要将数据库路由做调整。

先按照分库字段的 value 值与分库组的区间判断路由到准确的分库组，再按照分库字段的 value 值取模路由到分库，可以实现理论上的无限数据存储。

分库解决了数据存储的问题，同时带来数据使用上的不便，要充分发挥分库的性能最好的做法是每次都将分库字段做条件传入。

这意味着每次只能进行单表的操作，大大限制了业务的可用性，多表的数据汇总需要开发层面上轮库实现，也带来了开发上的复杂性，为此我们考虑使用 Mycat。

为什么选择 Mycat？主要从两方面考虑：

解决当前痛点，Mycat 支持 MySQL 集群，可以作为 Proxy 使用，解决了跨库数据查询问题。
再次 Mycat 可以很好的支撑读写分离，基于 MySQL 主从复制状态的高级读写分离控制机制。
比如 Slave_behind_master<100 则开启，而一旦检测到主从同步出错或者延时过长，则自动排除 readHost，防止程序读到很久的旧数据。
为未来的系统扩展提供很好的延展性。受限于 DB 服务器本身物理资源，单个数据库的连接数不可能跟随基于容器技术的应用服务器一样理论上可无限添加。
Mycat 的链接复用技术可以很好的解决连接数过大问题，如下图，另外 Mycat 可以支持多种类型数据库，Oracle，PG 等。

作为一个业务操作和管理系统，对一些数据有多样化的查询和数据钻取汇总需求，即使基于 Mycat 的 MySQL 数据库已经不能很好支持了，先后引入了 ES，Druid 支撑 OLAP 相关业务需求。

系统业务架构优化

随着大数据和 AI 相关技术的飞速发展及日趋成熟，如何运用大数据相关技术，将大数据更好的和采购业务融合，2017 年以后预测补货系统融入采购平台，作为转型智能采购的核心，提炼和完善符合当前业务的预测模型。

基于库存，销售，日销等数据匹配相关预测模型，对未来销量，库存数量，采购数量，调拨数量等等做精准预测，并且模型基于机器学习进行自我优化。

同时还提供采购时效分析，实际销售和预测监控，采购需求预测跟踪，订单数据透析，并基于安全库存产生的预警主动提示。

第三阶段：架构拆分&平台化期

随着前两阶段的实施完毕，采购平台在系统架构和业务架构上基本处于一个相对完善的阶段。

如何更好的支撑业务的飞速发展，同时提供极致的的稳定性，安全性，业务一致性。第三阶段系统按平台化拆分为采购前台和采购中台。

采购前台基于移动端和 PC 端提供更加丰富的功能和更加人性化的用户体验，核心围绕用户。

基于大数据平台和 AI 相关技术：

实现门店端业务操作自动化，满足不同类型门店的日常不同类型要货需求，降低人工补货的繁琐工作，更好的满足日常销售。
实现中心仓间自动调拨。根据要货仓优先级，要货仓-寻源仓优先级，进行要货仓和寻源仓之间调拨数量的自动匹配，用寻源仓的库存满足要货仓的库存，实现中心仓质检库存的动态平衡。
通过销售数据共享，库存共享，预测销量数据共享等等，打通和供应商的数据壁垒实现预测协同，生产协同，订单协同。