在“智慧零售大开发”的战略驱动下，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 支持多次路由，代码层无需改动，只需要将数据库路由做调整。
