从苏宁十年技术演进，看架构意识转变的关键一步

架构师 架构 孙迁 苏宁 ArchSummit

双11狂欢结束后，又是一轮长期的技术复盘时间，这个阶段往往是互联网电商酝酿新一轮架构演进的契机。演进实践中不仅需要解决大促遗留下的问题，还需要判断新的设计是否能够满足未来发展的需要。如何朝着合适的架构演进以减少未来意想不到的坑和教训，这往往是不少架构师需要深思熟虑的问题。

2016年12月2日-3日，ArchSummit全球架构师峰会将在北京国际会议中心举行。本次大会设置了《电商专题：系统架构如何应对业务爆发式增长》和《阿里双11技术架构突破》专题来深入解读双11等大促背后的技术故事，其中邀请了苏宁云商IT总部总监孙迁老师前来分享《高交易量下的订单系统架构演进及实践》，我们借此机会采访了孙迁老师，他为我们带来有关苏宁应对大促的技术策略以及线上线下架构的设计思想，希望可以为大家带来启发，如果读者想了解更多苏宁云商发展背后各个阶段面临的问题与解决方案，欢迎报名参加ArchSummit北京站并与孙迁老师进一步交流。

受访嘉宾介绍：

孙迁，苏宁云商IT总部总监，拥有十多年IT系统规划及研发工作，其中包括多年互联网平台的建设和研发管理经验。前期主要负责企业内部内控系统的建设以及包括企业集成总线、短信平台、监控平台、以及基础技术组件的研发工作。后续负责支撑销售的核心交易系统的研发工作，其中包括购物车、订单、价格、库存、会员、促销、寻源等系统。在高并发及大数据系统设计、运维及研发管理方面有丰富的经验。

InfoQ：能否简单回顾自己的工作经历，从苏宁云商近十年的演变过程中您如何看待未来短期乃至长期电商技术的发展？

孙迁：十多年前作为刚踏出大学校园的毕业生加入苏宁，在这十多年中，有幸亲身经历了苏宁的信息化历程。从我个人经历来看，主要经历了以下三个阶段：

1. 负责内控系统研发，使我对业务运作和管理方面有了很深入的积累；

2. 负责监控体系、服务治理、核心技术组件以及基础平台研发，这个过程中具备了坚实的技术能力以及持续治理和优化方面的能力；

3. 负责核心业务交易链路研发，这个阶段对业务和技术的广度有了很大的延伸。

科学技术是第一生产力，技术的发展很大程度上推动了业务的演进，同时业务的演进进一步促进技术往更高的层面发展，但是技术服务于业务的本质不会变化，电商行业的技术发展同样类似。

InfoQ：能否简单概括苏宁十年架构演进内容？

孙迁：苏宁核心系统的架构大概经历了四次演进，大致的演进过程如下：

1. 线下连锁店架构
   如下图，销售前端POS直连后端ERP，之间通过专线连接，这个阶段的架构分前后端，前端负责展示及打印发票等部分必要的功能，后端ERP实现了核心交易逻辑，此阶段的架构满足了线下的快速开店。
   

2. 线上初期架构
   总体架构演变成了线下POS，线上WCS，后端ERP的架构。此阶段实现了线上业务的快速上线，满足了短期内的线上业务发展。但是后续如何保证系统的稳定性和扩展性成了很大的问题。
   

3. 前台、中台、后台分离架构
   将核心逻辑从ERP中剥离，构建了中台系统，其中包括订单、库存、会员等系统，一方面为ERP系统减压，同时实现了多端协调、逻辑整合和一定层度上的快速扩展的目标。前中后化改造的本质没有调整核心逻辑，仅仅是做了系统上的拆分，目标是提升系统扩展性及系统稳定性，业务复杂度没有本质的改变，在交易过程中还需考虑复杂的后端业务逻辑，一定层度上导致了系统的不高效。
   

4. 平台化架构
   平台化架构主要是将自营店铺化，同时考虑自营和商户交易核心逻辑一致性，将自营业务核心逻辑后置，彻底的将后端管理与前端交易剥离，从而简化前端交易逻辑，极大程度上提升了核心交易链路的扩展性和性能；同时前端WCS系统及后端各履约系统系统也进一步的拆分和重构，目标是提升整体系统的扩展性及性能，ERP仅仅保存财务部分的内容。
   

InfoQ：特别地，实体店的存在给系统架构演进带来怎样的影响？

孙迁：这是苏宁最大的特色所在，虽然实体店及线上店最终的本质都是为了销售而存在，但是实体店的运作方式和线上的运作方式还是有很大的不同之处。如何更好地利用目前的资源，做到最大程度的融合是苏宁面临和要解决的问题，而且基本上是没有任何参考案例的，只能持续地摸索，不断地总结，才能探寻出适合自己的路。

在业务方案及架构设计上必须要深入考虑这些特点，关注各种可能区分及融合的场景，需要我们比任何一个单一渠道的同行考虑地更多，从而设计出适合自身业务发展的系统架构。在交易链路上的各个环节，比如库存、价格、寻源、促销、会员、购物车及订单都和同行有一定的差异，这些差异会给系统设计带来更多的输入同时引入更多的可变因素，从而对架构设计提出了更高的要求。

为了应对渠道差异下的融合，同时为了更好地发挥线上线下的综合能力，最终实现1+1>2的目标，单一渠道的分析思维不利于苏宁发展，这么多年我们也在持续地摸索和总结，任何业务场景的分析都需要考虑到融合的特点。

InfoQ：能否简单介绍苏宁云商目前的核心交易系统，这套系统如何满足多种业务形态的需求，在接下来的发展中还会有哪些调整和优化？

孙迁：苏宁整体业务系统主要分为前台、中台和后台三大部分，三个部分各司其职。

• 中台主要负责核心交易系统及所依赖的核心业务系统的构建工作，其中包括但不限于库存、价格、寻源、促销、会员、购物车及订单系统，基本上所有的业务都是运行在这些系统之上；

• 前台则以这些系统提供的服务构建各种各样的炫酷的产品。

这种松耦合的架构设计思路一方面可以尽可能地保证各个系统能够快速应对自身业务的变化和新产品的快速发展，同时在错综复杂的业务场景下给系统性能及扩展能力提供了相对稳定的基础。

就像通用处理器和专用处理器的区别，上述描述的中台各系统构建出来了一个通用处理器，可以更好地适应业务的变化，但是也带来了一些问题：比如特定场景下可能不是太高效。

举个例子：我们在实现爆款抢购等高并发业务时采用了这种基础业务组件和系统来构建，后面遇到了极大的性能问题，基本上很难保证此产品的使用及推广。后续的架构选型更倾向于一个简单而高效的专用处理器的设计理念，交易过程中的处理过程是完全不同的一条系统链路去支撑的，这条链路上的处理单元相对简单，只做和其相关联的必要的业务校验逻辑及链路，去掉了很多无关的通用业务校验和链路，甚至在逻辑部署上也是完全独立的，但是这样差异化的设计不代表会带来差异化的用户体验。

其实问题的关键就是如何正确识别、选择及设计“通用处理器”和“专用处理器”，在后续的发展过程中我们主要也会从以上方面去持续优化，以设计出可以更快速的应对业务变化且更高效的组件或者系统。

InfoQ：苏宁云商计划依靠数据做哪些决策，如何做到？能否从开发和用户体验两方面谈谈目前大数据给苏宁云商带来了哪些影响和变化？

孙迁： 这是个很大的话题，从用户行为、销售预测、商品采购、库存调拨、智能定价、定向推广、促销规划、货架摆放、运输路线等各个环节都会依赖大量的数据分析以提升各个环节的运作效率，这里举两个例子：

• 拿个简单的“千人千面”例子来讲，不同的人登陆易购后看到不同的内容，这里面关联的数据包括但不限于用户行为、购物车、收藏夹、订单等数据，综合分析出了更适合或者用户更喜欢的商品或者服务，这样一方面简化了用户的选择过程，同时带来转化率的提升；

• 另外我们上线了综合业务决策平台，内部称呼为“诸葛”，这个以大数据为支撑的平台可以极大地减少定价失误，同时完善仓库覆盖以及对促销分析及促销建议等功能，给业务应对市场的快速变化提供了极大的数据支持和驱动。

InfoQ：关于库存方面，在线上和线下的库存分配平时是如何安排的，在大促时如何调整？是否存在动态调配方案来解决库存分配不均的情况？

孙迁：苏宁各销售渠道的库存是共享的，尤其随着O2O的进一步探索和演进，对要求共享库存的场景越来越多，如果连库存都不能共享的话，则很难做到各渠道的融合。

具体的技术实现分两种类型，一种是数据上完全共享，另一种是动态调拨，这两种方式在苏宁当前都存在。

拿动态调拨来说，基本实现原理是为不同渠道设置不同的预警阈值，超过阈值则触发自动调拨操作。如何能更高效地进行调拨及如何能尽量减少调拨导致的渠道无货或者货物卖不出去的情况，这些需要结合着商品特性、销量预测以及仓库分布及辐射能力等情况去综合分析，而不是单一地靠静态库存数量来进行调拨，这样的话势必会出现各种问题。经过了多年的优化和积累，目前苏宁在库存这方面基本不会存在库存分配不均或者单渠道无货的情况发生。

InfoQ：能否为大家总结苏宁云商大促时容易出现哪些系统瓶颈，能否进一步地谈谈针对意想不到的大流量时，你们大促当日会有哪些应急手段？

孙迁：在高流量场景下，任何一个细微的问题或者瓶颈都有可能会引发巨大的故障。故我们从包括但不限于物理层面的链路流量、负载设备及机器计算能力等，到中间件层面的各种参数设置、应用层面的性能状况以及业务系统层面等都会存在各种瓶颈和异常。

应对不同层面、不同场景的瓶颈处理方式既相同也不同，whatever，一套完整的监控体系是所有业务及系统稳定运行的根基，避免完全不清楚系统运行状况的场景发生。目前我们在物理层、中间件层、应用层及业务层等各个层面都进行了大量的运行时数据采集，以及具备实时数据分析的功能，任何一点异常情况都会被立即发现并触发不同的处理预案，定期会对系统的运维状况进行巡检及总结，同时在新系统上线前会进行多轮的功能、性能以及线上实际引流及放大回放测试等工作，绝大部分的问题都会在系统上线前被发现并解决。

严格来讲所有的系统设计在一定程度上都会有一个上限，或者面临各种“意想不到”的场景。比如网络蜂拥或者其它超出了系统设计容量的场景，这个时候常见的处理方式会采用业务降级，极端情况下会采用流控等策略去处理。简单来讲就是牺牲一部分业务或者用户体验来减少对系统性能的消耗，从而保证核心链路的稳定。

随着能力的提升，各种“意想不到”的场景往往会变成“假设存在”的场景被考虑，比如流量蜂拥，机器宕机，业务异常等。目前我们总结了几千条异常场景，同时都会有对应的应急预案。一切的一切都是以快速恢复服务，减少对用户的影响为最终目标，而不是当问题发生时再去思考如何解决问题，这样会显著加长问题的处理时间，会对业务及用户带来很大的伤害。

InfoQ：大促高并发下如何快速定位到错误发生点并解决？针对系统问题，能否介绍运维人员大促常用的预备方案？特别地，哪些预备方案是你们最关注并反复演练的？

孙迁：快速定位错误发生点的前提是要有完善的监控体系，这样在事前或者事中可以快速发现异常，同时必须要持续积累和完善各种应急预案，知道异常发生时如何快速应对，这样两方面结合才能更快速解决问题。

我们其实没有常用和非常用的应急预案例，往往概率越高的问题越会被重视，随后慢慢演变成一个常态，也就无应急和非应急之分了。

给系统带来最大的不稳定因素还是来自于各种偏门的场景，尤其是没有预料到的场景。一切影响核心链路稳定的场景基本上我们都有反复演练，比如关键及非关键业务系统宕机等场景。

InfoQ：您在ArchSummit演讲中将会提到“架构设计意识的转变”，优秀的架构师应该具备怎样的架构意识？能否结合自己十多年研发经验提前为大家分享这个体会？

孙迁：经历了这么多年的业务及系统设计经历，让我体会最深刻的一点是在不同时期及能力下对于问题处理的思路和逻辑的不同。

对于一个架构师来讲，除了应该具备坚实的技术基础，另一个非常重要的方面是需要拥抱业务，同时对业务演进及外界环境变化具备极其敏锐的分析能力，这样才能更好地洞察及适应业务的变化，同时才能设计出更适合支撑业务及考虑到后续业务变化的架构。

我经常会对我的团队成员尤其是新加入团队的成员打这样一个比喻：农民兄弟知道种瓜得瓜种豆得豆，同时明白什么季节应该种瓜什么季节应该种豆，我们需要搞清楚的不仅仅是瓜和豆对刨地深浅的不同要求，同时要理解和知道为什么种瓜为什么种豆。做一个全面的技术农民，而不是专业刨地的技术农民，这仅仅是意识转变的第一步，也是最至关重要的一步！

同时我觉得架构没有严格的对与不对，只有合适与不合适，结合业务发展需要考虑多方面因素，这样才能可以很大程度上避免设计不足或者过度设计。

InfoQ：感谢孙迁老师接受我们的采访，期待您在ArchSummit全球架构师峰会分享的《高交易量下的订单系统架构演进及实践》。