【.com原创文章】在“智慧零售发展”战略驱动下，2018年苏宁新开门店超过8000家，各类门店总数已突破1.1万家在线下形成了“两主两辅多专”的智慧零售事业群。同时，打造了以苏宁超市、苏宁拼购为代表的线上平台。由此形成了线上多平台、线下场景多业态的互联网化，不断营造出跨越线上线下全场景的消费环境和空间。随之而来的是各种业务业态的加入带来的业务环节的多元化，适应行业快速发展带来的业务需求的多重变化……总之，一切都在“变”，作为自营采购平台作为采购的核心系统，如何适应这些变化？下面将介绍我们如何通过采购平台发展的三个阶段，积极“拥抱”变化，走出了自己独特的架构演进之路。第一阶段：系统建设&功能完善阶段采购平台基于2006年推出的SAP-R3采购管理模块构建。SAP-R3作为苏宁信息化进程中的重要里程碑，为苏宁的快速发展做出了巨大贡献，但随着多种业务的快速发展，已经无法满足业务的多变性和支持新业态的发展。就采购管理而言，SAP-R3与商品计划、选品等前期管理环节没有打通，无法在此基础上开展采购业务。另一方面，SAP-R3中采购和财务相关的业务是紧密耦合的，牵一发而动全身。无法支持各种业态新业务的快速部署，存在操作复杂、培训学习成本高等问题。基于以上问题，2015年开始构建基于Java的自主研发采购系统。方向已定，困难显而易见。作为一个运行了9年多的系统，SAP-R3已经有很多业务在上面运行。同时与大量外部系统相关，系统关系错综复杂。切换到新系统时，首要考虑的是保持业务的连续性，平滑的过渡将对外部系统的影响降到最低。对我们来说，这无异于“给行驶中的汽车换轮胎”。综合考虑各种情况，最终确定了新系统的切换方案：第一个新系统提供各种订单创建和管理功能，提供更好的服务体验。SAP-R3系统继续承担调度功能，双系统并行。逐渐切换。如上图所示，R3用于管理采购业务、订单调度、核算库存。现有系统架构、存货结构、存货核算均无变化。风险相对可控，投资资源相对较小。虽然只是一小步，但为了保证业务的稳定，还是值得的！方案确定后，开始新系统的框架搭建，考虑系统的可扩展性和稳定性，将模块功能独立出来，类似微服务的概念，部署业务模块采购、退厂、转移、原型&缺陷产品、采购需求作为独立的应用，减少相互耦合。同时部署资源能力体系，为各业务系统提供统一的公共服务、主数据服务、权限服务，减少代码重复。系统结构如下图所示：系统搭建完成后，随着系统的顺利运行，第一步的工作就告一段落了。2016年，将启动结构转型第二步：去SAP的转移，以采购平台为核心调度，真正承担责任。物流和库存的调度！如果说转型第一步是边开车边换“轮胎”，那么转型第二步就是整个环节的核心调整，就像边开车边换“引擎”。保证业务无感知切换仍然是首要任务。切换过程采用双链路并行措施：先导+链路切换。一旦发现试点项目新链路功能出现问题，可第一时间切换至老链路，保障业务正常开展。此外，作为核心调度系统，如何保证数据流转、溯源、安全的闭环也是必须考虑的问题。在原有系统的基础上，增设操作日志系统，方便业务操作数据的追溯。第二阶段：功能暴增&业务爆发期***阶段主要是系统建设和功能迁移。2017年后，系统重心将转向提升用户体验，支持新业务的快速发展。主要优化完善系统功能架构、数据存储架构、业务架构：优化系统功能架构，提升功能的丰富性和体验性，加上对新业务业态的支持，增加了很多新的切入点。本身逻辑非常复杂，与外围系统的交互也很多。此外，项目周期短。前期是在已有功能的基础上做一套新的。虽然对现有功能的影响降低了，但是运维的复杂度却呈几何级数增长。有时涉及单个创建和共享逻辑的修改往往需要修改近十几个地方。开发很容易错过，测试也很惨。.系统功能的架构优化提上日程。针对以上情况和系统特点，我们采用了一种技术方案：服务原子化和功能积木。一些基础服务，简单来说就是将订单创建逻辑分解为基础服务，在基础服务的基础上组合新的功能，如下图所示：基础服务层提供独立的基础功能来保持原子性，而第二层服务组合层，主要考虑一些业务功能的实现。虽然功能入口不同，但是在业务逻辑上有很多一致的地方。为了方便业务流程层的使用，将与业务密切相关且具有先后顺序的原子服务耦合在一起。业务流程层根据业务需求将原子服务和服务组合构建成一套完整的逻辑。分层的好处是可以实现新业务的快速迭代，同时也涉及到一些节点的变化。只需要在基础服务层或者组合层进行改动，不会有漏改的可能。系统存储架构优化在系统建设初期，考虑到业务数据量级，采用了分库+分表的方案。后来的实践证明，这不是一个好的解决方案，增加了系统运维的复杂度，每次发布都要改很多地方，极易出错。数据库的动态扩展也带来了极大的复杂性。经过技术内部讨论，我们果断将分库+分表改为只分库分模块。按模块分库，可以保证每个分库上的数据量级相差不大。一旦量级达到需要再次拆分，数据库可以按组动态扩容。目前公司自研的持久层组件DAL支持多路由，代码层不需要改动，只需要调整数据库路由即可。先根据子库字段的value值和子库组的区间路由到准确的子库组，再根据子库字段的value值路由到子库，从而实现理论上完美的数据存储。分库解决了数据存储的问题，同时带来了数据使用上的不便。要充分发挥分库的性能，最好的办法就是每次都把分库的字段作为条件传入。这意味着一次只能操作单张表，极大地限制了业务的可用性。多张表的数据聚合，在开发层面需要通过轮库来实现，这也带来了开发的复杂度。为此，我们考虑使用Mycat。为什么选择迈猫？主要从两个方面考虑：针对目前的痛点，Mycat支持MySQL集群，可以作为代理，解决了跨库数据查询的问题。再次，Mycat基于MySQL主从复制状态先进的读写分离控制机制，可以很好的支持读写分离。例如Slave_behind_master<100，则开启，一旦检测到主从同步错误或延时过长，readHost会自动排除，防止程序读取长期旧数据。为以后的系统扩展提供良好的可扩展性。受限于DB服务器本身的物理资源，作为基于容器技术的应用服务器，理论上无法增加单个数据库的连接数。Mycat的链路复用技术可以解决连接过多的问题，如下图所示。另外，Mycat可以支持各种类型的数据库，如Oracle、PG。作为业务运营管理系统，对某些数据有多种多样的查询和数据钻取汇总需求。即使基于Mycat的MySQL数据库已经不能很好的支持，ES也相继推出，Druid支持OLAP相关的业务需求。系统业务架构优化随着大数据和人工智能相关技术的快速发展和成熟，如何利用大数据相关技术更好地将大数据与采购业务相结合。2017年以后，预测补货系统将作为转型集成到采购平台中。智能采购的核心是细化和完善符合当前业务的预测模型。基于库存、销量、日销量等数据匹配相关预测模型，对未来的销量、库存、采购、调拨等进行准确预测，并基于机器学习进行模型自优化。同时，还提供采购时效分析、实际销售及预测监控、采购需求预测跟踪、订单数据透析、基于安全库存的主动预警。第三阶段：架构拆分&平台化期随着前两个阶段的完成，采购平台在系统架构和业务架构上基本处于比较完善的阶段。如何更好的支持业务的快速发展，同时提供最好的稳定性、安全性和业务一致性。第三阶段，系统按平台分为采购前台和采购中台。采购前台基于移动端和PC端，以用户为中心，提供更丰富的功能和更人性化的用户体验。基于大数据平台和AI相关技术：实现门店端业务运营自动化，满足不同品类门店对不同品类商品的日常需求，减少人工补货的繁琐工作，更好满足日常销售.实现中央仓库之间的自动分配。根据需求仓库的优先级，需求仓库-源仓库的优先级，进行需求仓库与源仓库调拨数量的自动匹配，并利用源仓库的库存来满足所需仓库的库存，实现中央仓库的质量。检查库存动态平衡。通过销售数据共享、库存共享、预测销售数据共享等，打通与供应商的数据壁垒，实现预测协同、生产协同、订单协同。除了快速响应采购前台的需求，采购中心将更加注重功能的稳定和完善。作为调度的核心，需要以数据为核心，保证业务的一致性和时效性，提供更全面的监控手段。在现有业务逻辑复杂的情况下，可以搭建积木，实现快速响应。服务原子化后，更多的逻辑在于流程控制，将服务控制层细化为逻辑“引擎”。比如状态机引擎就是基于当前文档的整个生命周期中有很多状态和很多变化触发条件。对各个环节的文档状态进行统一管理，保证文档状态的有序性和一致性。另外，作为调度中心，如何及时发现问题是最重要的，全链路的监控非常有必要！通过业务类型和单据编号，记录每个阶段的单据状态，对收集到的数据进行收集和串通，从而使单据的整个生命周期处于监控之中，发现任何节点出现问题并进行处理第一时间，确保文件流转的及时性。总结纵观系统架构的演进，没有绝对的理论。没有解决所有系统架构问题的“灵丹妙药”，适合自己的才是最好的。没有一站式解决方案。随着业务的发展，新技术层出不穷。再好的解决方案也经不起时间的考验。适应变化才是最好的解决办法！作者：徐磊简介：苏宁科技集团供应区块链平台研发中心采购中心开发负责人。2011年加入苏??宁后，先后主导SCS苏宁供应链体系、售后服务体系、采购平台等系统的建设和迭代优化。目前负责采购中心、服务市场的开发和管理，以及相关系统架构的演进和优化。【原创稿件，合作网站转载请注明原作者和出处为.com】
