2016年5月28日，华为开发者汇南京站在安德门黑马路演中心圆满落幕。本次沙龙议题增加到六个，时间安排上也从之前的半天扩展到全天。讲师有来自华为、苏宁、途牛的多位好手，议题涵盖”通讯即服务“、”内源开发“、”探索性测试“、”容器技术”、“电商平台迁移”、“订单架构优化”。
来自苏宁易购IT总部高级架构师王一硼给大家带来题为《苏宁易购O2O电商平台的变迁之路》的演讲，他把苏宁早期传统IT架构到互联网架构的变迁做了一个回顾，并将自己在移动互联网架构上的经验做了分享。其中举到一个苏宁易购大促的例子，让大家对架构师工作所要了解的知识面有了充分的理解。
现场实录：
王一硼：大家好，我今天钻进了一个华为的专场，都是华为的粉。我叫王一硼，现在在苏宁易购消费者研发平台，主要从事架构工作，涉及到跟架构相关的工作比较多。比如说架构优化，性能优化，网站的稳定性等等这些相关的工作。今天我给大家带来的主题是苏宁异购O2O电商平台的变迁之路。今天这个演讲主题会给大家介绍一个传统企业怎么去改变它的IT架构，来适应互联网时代的发展，有一个借鉴和方法论。
我们言归正传，我将会在三个方面为大家阐述一下。第一个是架构演变。苏宁早期的架构是由Commerce+SAP这套架构来提供线上的电商服务的。这套架构有什么优势呢，它是套件的，对电商基本的功能是能够快速定制开发的。我记得在2004年时候主要推的，快速的实现很多线上的部署。随着业务的发展，这套架构已经不能满足我们业务的需求了，随着业务量的增加，我们访问量越来越大，这套架构它的扩展性，它的能力已经不能满足我们线上的需求。
有哪些问题呢，这里列了一下，比如说它的(02：07)。举个例子，苏宁在前几年的时候发布一个版本，因为它早期是Commerce的套件，那个套件可以要达到1G，下面一个1G的代码量，开发人员查代码都很困难，所以发布的时间非常长，基本是一个月迭代一次到两次的周期。这种效率是无法满足互联网的短平快的发展需求。第二个系统的维护性差，Commerce内部集合了很多的功能，比如像订单、会员、一些基本的促销、商品等等一些功能。它想改一个服务，他买的商业的版本，套件的东西，涉及到里面的一些技术要去制定一些IBM的什么，维护成本特别高。举个例子，苏宁现在想拿这个Commerce开发易购上面一个知名的服务，就是拍卖，你可以想象这是完全无法做到的，所以这个问题很严重。
第二个它是一个整个的大包，没办法进行一个垂直化拆分。因为成本高，基本你买的一套套件，都要买IBM的整合套件，扩展性差。还有大促期间经常会出问题，经常系统持续提供的一些核心稳定会挂掉，所以这套系统已经无法满足我们业务的发展了。
苏宁好的一些业务，一些主流的业务架构，还有符合我们自身业务发展的，对我们的架构进行了自动化拆分。苏宁做自动化拆分是怎么做的呢，首先会对我们系统进行前中后三个平台的划分。前台基本都是一些展示类的处理，这样前端可以敏捷化开发，小团队作战。比如说苏宁是四端融合，哪四端呢，PC端，POS端，APP端，还有门店端，这四端融合，每一个端的业务需求展示都不一样。所以我们在前台相当于四个结构的，所以每一端它的展示可以快速的迭代。中台我们是大中台的服务，主要提供一些基础服务能力，比如上面提供一些商品信息的查询，提供一些价格的查询，这些我们进行一个中台化的处理，保证对外部提供一些稳定的服务。后台是一些数据的管理，我们有一些大数据平台，还有前台、中台产生一些数据进行分析处理，来为前中台进行一些数据的支持。
做这个SO化，大家都知道做SO化最主要的就是一个基础服务。因为现在是面向服务了，不是像之前我是面向的套件开发的方案。苏宁在做SO化，它在基础服务上做了很多的研发。它都做了哪些工作呢?我大概的讲一下，由于时间关系不可能讲那么细。做服务化关键的就是要服务化框架。大家都知道现在业界比较有名的服务化框架(06：26)，是开源的。当然每个公司都有自己的，为什么苏宁要作ISO这套服务框架呢，其实一些早期的架构大家都会用ESP，ESP的问题是它是集中式的，会有一个集中的代理点，代理点如果流量很大的话，传输的压力是很大的。新的服务框架都是点对点的，我从一端到另一端，不会有一个中间的路由的过程，所以它减少了这个问题。
苏宁要做服务框架，当时也讨论了很多问题，我是用开源的，还是用自己的，其实最后还是用自己的研发的。为什么呢，其实服务化里面最重要的要知道它有一个管理，就是我服务治理的问题。(07：16)可能治理有一套服务治理，但是真正产生数据，比如某个借口的访问量是多少，我怎么控制它的流量，这些都是要经过我们二次定制化开发的，或者我要跟周边的基础组件进行一些交互的，一样还是要进行开发的。比如说我们要有一个调量监控，APM，这种文化我们能够要嵌入到服务化框架里面去看看每个东西的响应时间状态，这些信息我们必须要定制这一块IF框架。
数据层我们有自己的数据层框架，现在苏宁的数据库基本全部迁移到MySQL存储的方案。我会有一个中间层，中间层提供一个分库分表的处理，动态数据迁移。比如在一个老的机器，从DB2，或者从原来一个老架构的方案上可以进行一个动态数据处理，或者动态扩容的。还有一个(08：33)，这个很关键，很多开发人员写SQL的时候并不了解SQL的时候性能，你为了避免这些产生的事故，我们都会进行一些控制，有SQL怎么支持，或者管理SQL，这是中间件。
分布式缓存，互联网公司大家都知道缓存很关键，每次大促，抢购，都是靠缓冲来支撑过去的。苏宁在分布式缓存是基于Redis的一个集群上面进行改造，还有一些分级的处理，分级缓存，或者是热点数据缓存。举个例子，苏宁的商店信息等一些重点信息，因为数据量很大，要快速的提供给用户，可能会对某一些数据进行存储，分级缓存。这样靠Redis的内存是放不下的，所以我们自己研发了一个方案，可以在热点上进行内存，有些可以在磁盘上取。Redis有一些磁盘的存储方案，但是性能是很差的，所以我们进行一个改造。还有一些分布式的文件系统，苏宁的一些静态资源，图片啊，还有苏宁云，都是及上集成商。还有自己的私有云，私有云提供了苏宁快速的部署，快速的扩容，这样一些功能。还有一些大数据平台，对我们后端数据处理，对前端进行一些提供。还有一些持续集成平台，这是我们发布、降级一般都需要人为的发布，手工的发布。苏宁在这方面研发了自己的持续发布平台，开发人员在这方面发布的成本大大降低。我们还有一个全链路的监控，刚才说过了ATM，还有对每个节点等的一些监控。
这是我们RSF的一些架构图，是二期的一个角度，现在已经改变了。但是方案都差不多，其实都一样，一个服务交付到一个提供端，IT数据的架构。关键的问题是对数据的查询，因为每个服务分发和调度的一些数据表进行一些采集和控制，进行管理。大致就是这些功能，大家看一下(图)。这是苏宁的私有云，提供持续集成、动态部署这些功能。界面，比如部署一套环境的话是这样做的。还有监控刚才也说过了，从端到端的，整体链路的监控。
刚才讲的是传统架构或者说发展一个互联网公司架构的一些概括。下面我再强调一下，因为现在已经进入了移动互联网时代，移动互联网时代和以前的互联网时代还有一些区别，我们可能在这方面碰到了一些问题，解决了一些问题。第一个，现在劫持是很严重的，像阿里的做全端的DNS，百度最早也做的全端的DNS。苏宁做反劫持的时候是怎么做的，它在AP端是有一个相关模块的。首先劫持分两部分，第一个是DNS劫持，第二个是内容劫持。DNS劫持我们通过APP端里面的模块，自动的会判断查找那个localDNS，苏宁有一个自己的APPDNSserver的服务。它会判断你这个分配的IP第一个对不对，不对我就给你一个正确的IP。第二个我能提供一个最优的全体节点链路的查找，这样可以减少链路的访问端，提高一些性能，这是我们反劫持做的。
苏宁内容劫持，虽然我们已经在做了，估计苏宁也会在互联网当中做到全端的内容APS。其实内容劫持有几方面，第一个是在PC端，在PC端没有办法(14：13)。移动端有两个方案，你可以把你的请求进行一些非APP化，因为在移动端APP这种请求根本不是移动端的问题，可以进行一些自己协议的处理，或者是APS化。这样内容劫持无非就是标记你的域名，他是标记不到的，可能就劫持不了了。
苏宁在内容智能分发上，现在大家都知道你访问每一个手机，型号都不一样的，图片大小合适肯定都不一样。第一是图片大和小的问题，传递一个大图片的话，数据大，性能也不是很好。苏宁这块在资源的配置上会进行一些预热，预热之后我会自动的分发，做成不同的格式，当APP发起的时候，判断你APP的手机型号，我会给你分发不同的东西。
还有一个是移动端，APP大家都知道，它跟PC端有点不一样的是，APP端请求数是有控制的，不像PC浏览器一样，早期IE可能有，现在谷歌等浏览器在这方面是很好的，但是移动端是有控制的。在这方面我们做了一个独立接入，对后端系统进行一些请求的合并，同时本地带一些缓存，我们有一级缓存和二级缓存。第一个就是介绍域名和查询，第二个发请求合并，可以满足我APP，尽量控制那个请求数，保证APP性能，这是我们做的一定的优化。我觉得其中的技术主要是ngx+lua的方式，lua大可能是一个携程，携程在这方面性能是很好的。
做了这些事情，怎么能够保证这套架构真正能满足我们的业务需求呢。其实大促才是见证我们系统能力的关键。苏宁是怎么做大促保障的呢，第一个我们会有自己的系统巡检，我们会有自己的系统巡检工具。系统巡检工具会在大促之前，比如前两个礼拜做专门的系统巡检，测各项指标都会进行判断，用自动化工具来判断。同时进行(17：25)，来判断这个系统是不是稳定。第二个我们要分析整个大促的核心业务链，我会通过用户的访问模型，分析出，比如说我估计这个大促从那条链路能够进来。举个例子，我们从首页，整个要经过这些系统。每个都是小单元的系统，每个系统是不是能够承载这些能力，我会找到一些系统短板，进行一些优化和扩容。比如我们可能在双十一之前进行一些小的促销的时候，在流量引入的时候，发现我购物车容量是不够的，通过我们的私有云平台可以自动化。
还有很关键的就是容量评估，做大促的话，业务肯定会给你一个指标，我今天要做一个大促，相当于日常访问量的10倍、20倍，上百倍。这个业务指标就是我们要保证这个系统是不是能承载一些请求量，这个就是做容量评估。首先我要知道我的系统能够承载的量是多少，现在系统在的水位是多少。这个怎么做呢，我们通过一些压测的方案。压测现在比较流行的是，一个是引流压测，苏宁有自己的引流压测的方案，我们会在每个系统上，把流量引入到我们的生产，或者是同类型的(19：31)环节，进行一个定时放大或者同时放大的测试，看看是不是能够真正满足业务的需求。这个引流压测有什么优点呢，第一个它是真实的用户流量，不是通过测试伪造的，完全是相当于同一个用户，可能访问一次，并发的访问十多次或者上百次的请求。当然大部分主要是在读层，写商品的话不可能把用户同时写，我们下一个订单，下一百个订单，肯定是不行的，在引流压测的时候有一些控制。这是我们自研的一套引流压测平台，现在已经提升到web平台上去了。它的体系就是我在系统抓包，把一个相关的请求进行IP放大。早期网易有一套(20：29)，我们当时也拿过来研究过，发现不能满足我们的业务需求。某些域名直接打到我们的生产环节，这是我们整个研发的内部结构，主要是(20：58)，性能也比较高，进行一个测试。在IP层有(21：05)，三台机器最大的承载能力是在五千KPS，超过五千的话会有一些丢包。但是从我们这么多经验来看，三台机器很少能超过五千的KPS，我说的是虚拟环境，不是实体。
还有一个是写上去的压测，写上去的压测我们用自己的压测工具和平台。因为开元和商业的是不能完全满足我们需求的，内部协议是不一样的，要进行一些接口级的压测评估，从前端请求各方面的压测，我们有自己的研发的压测平台来进行处理。还有个关键的，因为你在大促当天数据是准备好的，不能进行任何改变。你不能说现在发现问题，我来改动。怎么办呢，我们每个要进行一些应急预案的处理，比如预先我们要考虑到这个系统假设会出现某些问题，比如我碰到了DNS攻击，碰到了大量黄牛软件的刷单，这些情况我们要怎么样去处理。当然我们可以通过测试工具模拟测试，考虑一些应急预案。首先我们会跟系统进行一个分级，比如一级、二级、三级的系统，对不同的系统会有不同的降级方案，比如购物车里面某一个功能进行降级，它可能是次级服务，不影响我整个下单的流程。为了保证整个系统的正常，我们会进行一些控制，或者我进行一些流控。同时我们还有现场决策，判断这个时候是不是一定要触发这个预案。
还有什么都不可控了，我们在最后一道图，会有一个流控平台，每一个系统都会接入流控，对每个系统请求的状态会进行一个判定。大家都看过小米、阿里都有流动平台，自己在抢单的时候比较忙或者什么，其实就是触发了规则。我们苏宁也一样，也有流控平台，通过我们在前端数据收集之后，判定是否能够触发，会推出前端的控制。同时我们会进行针对触发流控的用户，他的一些行为，我们会分析他的页面访问轨迹，他是不是从某些页面进的，我来判定他是不是一些黄牛行为，防止一些误伤。因为一些黄牛直接就刷订单的接口，刷重点的一些对他有利益的接口，这是我们的流控。这是我们在双十一时候解决一些顶点峰值的时候控制，我们有效的控制流量的高峰，削峰的时候，判定大量的黄牛来刷，保障系统是稳定的。
这是我演讲的全部内容，时间有限，我就讲这些。
提问：在线测试除了传统有一些被动的测试，比如性能指标，或者是磁盘的问题，被动测试，你的在线测试还有哪些保证我系统是正常的?
嘉宾：在线刚才提到了，我们有自己的监控平台，监控平台要了解一下API，API这个领域是整个调用链。因为SO是完全提供服务的，我压测一个系统，可能不会只对这个系统产生一些问题，可能会对后端有。比如我压测我的购物车，购物车可能会调不同的服务等等。是不是会给库存带来很大的压力，我们会有自己监控的APM平台，会判定这个指标，当它达到多少值的时候，尤其达到60%，我这时候就预警了，它的请求的时间不长的时候，我已经预警。等等一些判定的指标，我们每个系统都会进行控制的。现场写流量主要还是一个工具，像我刚才说的用户流量大部分都是读，你只要把写引进来的话，你下一个单，下十个单，我买十个商品肯定是不同意的。所以写的话是模拟一些用户的。为什么我们要自研一些工具呢，我们内部的一些协议是不同的，不可能用RLO的协议，肯定跟你外部的APP的协议是不一样的。你用你的开源工具肯定是不支持的，还有一些测试的案例等等我会有收集管理。所以在这方面自研了一套方案。
提问：你们自研的RCF跟Double，跟他们比较的话有什么优势，或者说RCF有没有借鉴Double的一些设计思想?
嘉宾：我觉得做服务框架最主要的就是三个方面，第一个就是服务的消费者，第二个是服务的提供商，第三个就是服务的管理和控制，就是调用。这三个方面是基本的元素，基本上任何一个服务框架都会有，但问题为什么要自研呢，它在数据流转过程中产生一些数据和控制。举个例子，像我刚才说的，我现在想去判定某个系统的响应时间，比如说我从购物车调我的库存服务，库存服务的一个响应时间是超过多长，超过多少秒，或者调用量是多少。我完全用Double的话，我可能调一个接口，或者写一个二次开发，这个分析我们是要通过自研处理的。你可能要了解一下为什么阿里不用Double，他用HLF，他其实内部嵌了很多框架在里面，比如它的ACF就嵌了ATF监控的数据，这些数据一样要抽出来的。如果只是一些基本的服务控制和管理的话，可能能满足你的需求。但是如果你有一些特定需求的时候，可能就不行了。
提问：因为这是一个很大的系统，有分布式部署的，调用的时候是通过RSF，有可能一项动作会涉及到多个模块一块去协同，会涉及到一个分布式事务的问题。
嘉宾：分布式事务我们尽量不去用分布式事务来处理，现在互联网模式都用异步的方案，或者一些补偿的方案。举个例子，我库存的一些信息要去查后端的，我可能会发一些PO的消息，一些方式进行通知。当我发现前面已经进行了一些失败的话，我可能再发一个进行删除处理。因为有些情况互联网公司没必要做到完全的一致性，部分的一致性就可以了。
记者：就是基于补偿的。
嘉宾：对，基于补偿的方式。
记者：假设我生成了一条数据，接下来我会补偿它，对不对?
嘉宾：对。
记者：假设这中间有一个时间段，这段时间假设我又操作了这个数据的话，会不会产生一种问题，就是我在补偿之前操作了这个数据。
嘉宾：我们会有一个控制，在应用系统上进行一些处理方案，这是属于应用系统里面内部的设计，肯定要控制这些关键点。我只是举了一个例子，因为不可能讲特别细，你要想讲特别细的话，可能要拿一个真正的系统的架构方案，这样会讲一些细节性的东西。我今天主要展示一下一个互联网企业要做的IT变革，有哪些东西要改变。
提问：咱们苏宁这边的分布式文件系统是哪一个?
嘉宾：也是自研的，具体我这个也不太清楚，好像是原来一个华为的人过来搞的。
提问：刚才咱们说到流控，是在你刚才说的同步之前，还是在应用层之前?
嘉宾：流控我们有两层，第一层会有一个应用防火墙对总体的流控，第二个会每个对系统有一个策略流控。流控无非就是我超过每分钟访问多少次，bug多少次，这是跟(31：25)有点相似的。在应用防火墙前端大致做了一下，做了一个NG大量的，前端是进行控制的。同样发现一些不对的时候，会进行一些丢弃或者一些处理。对于每个系统的时候，我们也会判定每个系统，有很多策略，比如说它的线程数，每个应用的线程数最大是多少，响应时间是多少，或者堵塞的情况下会进行一些控制和处理，一些策略。可能会自动化分析，同时后面会分析用户行为轨迹，防止误杀。现在很多流控误杀的情况还是比较大的，所以在这方面要做一些细节。
提问：了解苏宁(32：32)的应用。
嘉宾：刚才我也提到了苏宁在DB中间站在会实现，我也在主推。还有刚才的引流压测，这个都是做很多性能测试的。我个人还是比较推崇GO，因为我觉得JAVA这两年发展太快了，尤其在携程这块做的基本没有什么推进，被甲骨文收购了，几乎天天跟谷歌打仗，不是一个IT人要做的事情。GO我觉得它现在在1.5到1.6的稳定性是很好的，而且它现在贡献非常大，我觉得它有点像JAVA1.5之后的发展趋势。像Docker夜袭够实现的，所以可以建议大家去研讨，研究一下，这个还是比较好的。
提问：我是去年因为装修在你们苏宁易购上采购了一个电器，因为我在南宁，电器分配的时候是在山东那边，对客户来讲要快，第二个是价格上面。后来山东的商家就讲，他说我暂时没有这个产品，又从其他调度。我想问一下，像你们在数据分配上面，哪个路线在哪里。
嘉宾：苏宁这块涉及到库存的问题，我会根据你的手机APP查你当地的库存，或者根据你的收货地址进行一个判定，这是一个。第二个我不你刚才说的是西店还是自营的，自营的是这套规律，西店的话就不一样了，西店的话就是商家那一块，可能就涉及的比较复杂了。自营我们是就近原则，根据你的IP地址的信息，或者你收货的信息进行控制。这也是我们B2C和C2C的区别，在这方面性能是要有很大提升的，我们也做了一些处理。
提问：这里面有一点，苏宁易购跟淘宝上面有一点区别，作为客户来讲你肯定就是认准苏宁电器，你作为一个统家。但是在你的后台也好，你的所有的库存也好，你应该有一个总的调度调配的。
嘉宾：这个涉及到管理层的事情，不是技术上能处理的事情。
提问：技术上也可以做。
嘉宾：技术上也可以做，你要知道跟后端打通很多的事情。像淘宝也一样，有些服务，像他调银行，银行挂了，不保证你质量，我也说支付宝有问题，这些有时候是管理上的事情。
提问：我看你们缓存用Redis，你们在Redis上需求开发了哪些功能?
嘉宾：Redis有一个好处，就是它的性能很好，性能是非常高效的，单击到两三万简单的命令是没有问题的。它有最大的问题就是存储，内存是很贵的，你不可能买几百G的内存。第二存量量大的时候性能也会下降，这是一个问题。苏宁有很多的数据量比较大的时候，又要使用到缓存，这种怎么解决。我们会在技术上进行一个绑定，比如我会有一个热点数据内存去Redis，非热我可能会读硬盘。完全靠Redis，毕竟有一套存储方案，但是那个存储方案你可以去研究一下，会要很大的性能。所以这方面我也会改造，你可以看一下京东的Redis，他在这方面也有一些处理。
主持人：如果没有其他问题的话，我们就掌声谢谢王一硼老师。
(结束)
