凡客历程分享——应对规模和复杂性挑战

1、凡客历程分享应对规模和复杂性挑战2011年4月23日，主题为云计算技术沙龙一一大规模互联网架构实战的第九期TUP活动在中国科学院计算技术研究所一层报告厅举行，本次沙龙活动主要涉及基于MySQL的B2C电商系统前端数据层架构、应对规模和复杂性挑战、Hadooop未来走向等 话题。在此次活动中，来自凡客诚品项目管理与架构总监栾义来发表了凡客的历程分享：应 对规模和复杂性挑战演讲，在此次演讲中，他带来了三方面的内容，第一，为了应对访问 规模的增长，除了常见的读写分离、纵向分拆外，在各系统的细节中还应该注意哪些方面； 第二，面对解耦逻辑复杂度的挑战，如何解耦和抽象电子商务各子系统，以快速应对业务变化；

2、第三，关于实用主义的技术思考。凡客诚品项目管理与架构总监栾义来以下是栾义来演讲实录:栾义来：我的PPT也一些人会比较失望，这里面涉及到技术细节比较少，几乎没有。因为电子商务的事情从我个人观点来讲，我觉得不是一个特技术的事情。他是分阶段的，其实很多数据库的方案，大家反反复复在很多场合听过很多遍了。比如说MySQL的方案套到Oracle上不会有太大差别，这些东西大家在有些场合听得差不多了。我的 PPT 里面更多讲的是一些技术和非技术之间都相关的事情，这些事情是你刚入 行的时候体会不到， 或者是你不觉得是那样。 当你逐渐做电子商务这件事情的时候你才会有 所体会，觉得他的确是那样一件事情。我大概分几个

3、部分，首先对凡客做一个介绍，然后是电子商务大概技术的一些阶段 的发展。 然后是关于规模访问和逻辑浮躁一些问题的大概解决。 最后这个可能是非技术的东 西，很多人对于凡客的成功是有很多疑问的，有些很好奇，我简单跟大家分享一下。我自我介绍一下，我是 08 年初加入凡客一直到现在，在技术部门从事管理和架构 的事情。 我之前在金山和一些其他企业做过。 我先简单跟大家介绍一下凡客是什么， 凡客这 个事情在很多人眼中对凡客不是特别清楚， 凡客是一家什么样的厂商。 凡客在我们眼里首先 是一个服装品牌， 他首先是一个我们称为快时尚自助品牌的服装、 服饰的互联网商城， 这是 这件事情本质。 比如说麦包包也好， 你

4、看其他的也好， 你要去明白他们首先是要干什么事情， 他干这件事情决定了他们要采用什么样的技术的解决方案。 凡客的正式发布时间是在 07 年 10 月 18 日发布，到现在三年半的时间，他去年营业额 20 亿，网上可以查到。目前日均 PV 是 8000-1 万之间，这个数量级相当于不大不小门户的访问。目前的日订单量在 15 万 左右，整个系统对订单处理峰值超过这个。 目前凡客整个架构体系是在 Windows 架构上面， 外部就是 SP 的 MAC 和 Cache （音译）应用。整个后端包括 ERP 和后端运营系统部分也 采用了大量的 Winform 的界面，整个处理不是多么高的复杂的系统。目前我

5、们整体的服务 器超过 500 台，整个服务器增长速度还是挺快。 据我所知， 很多 B2C 企业服务器其实基本 上是在当当这个级别是 1000-2000 ，阿里巴巴是一万的级别。服务器是怎么分布的，仔细 一看也很简单，他们大部分是分担浏览，刚才简朝阳讲的那部分， 80% 的部分是分担纸图 （音译）的。还有服务器就是应对交易流程处理， 还有服务器就是内部系统使用。 其实你到 任何一个点上看一眼跟现场没有太大区别。电子商务技术发展的几个阶段我这里总结了一下，我认为现在大部分的 PC 电商要经历技术发展的阶段。很多人 都觉得电商的技术是怎么怎么样，现在电商里面很多人用了 Windows 架构，真正 J

6、ava 不 是太多这个，并不是电商企业会怎么样，有很多历史原因造成。所以我们选择 Windows 由于最初选型造成的，包括你了解很多电商，当然现在冒出电商有些采用 Java 架构，但是 Windows 和 Java 之间对电商来说不是很简单的东西，因为最终来讲对我们的困惑是上市 前授权的问题。这个问题在电商领域里面，他其实不太考虑这个事情。对于电子商务来讲面临两个挑战， 前端来讲我们称为是大规模的 Web 访问，他的互 联网系统跟你的 SNS ，跟你认为的门户没有什么区别，他要应对的是一个浏览压力。他应 对不是交易压力，交易很多你企业就赚翻了。一天 15 万单，一天 15 万笔的交易，他应对

7、基本上是跟其他互联网企业一样， 应对一个互联访问压力。 门户有门户特点， 电商有电商特 点，他们之间区别主要是浏览数据变动性特点。 资讯来讲是不变的， 发一个新闻稿是不变的。 电子商务还有一种企业， 对于 SNS 来讲他是需要实时的。 其实电商是介于实时和静态之间， 最终你会发现你做技术架构的时候你是融合了纯静态架构和实时架构中间状态的东西。对于电商很多挑战是在后端，前端架构本身是有非常多的成熟方案，大家讨论互联 网架构很长时间了， 在网上很多文章， 你随便拿一篇过来做一下， 大概这个问题基本可以解 决。但是对于你真正的解决发现是你的后端， 我们后端是普通用户看得到的， 那永远是一个 商城。真

8、正这个订单从下达到最终交付到用户里面经过无数个步骤。 最终电子商务的竞争到 一定规模之后是一个完全后端的竞争，已经跟前端无关了。他的竞争最终到一定规模以后， 可能到京东这个规模你会发现他们竞争完全是后端竞争。 他的商城前端已经变成再普通不过 的事情，他的竞争完全是供应链、物流、 仓储的竞争，你一个订单下来之后多长时间送到用 户，以及你整个订单处理流程里面跟用户每一个接触点， 你的用户体验做的是否好， 是这样 的竞争。对于你技术挑战来讲，你挑战方向是有所变化的。下面我们说技术发展阶段，这是我个人一些观察，因为我发现很多电子商务企业永 远逃不出一些阶段性的发展， 很多时候你会发现其实电商企业很多时

9、候是很草根的。 坦白讲 凡客最初发展的时候不能说他是多么优秀的， 最初发展是很艰难的。 包括我最近观察一些创 业企业，他们还是在经历那个阶段， 是很草根的。 很多人可能看不上， 这个阶段特点就是生 存，表现就是你没有钱， 你召不到人。 不是说他们不想把系统做好， 而系他们根本召不到人， 很多人不愿意去很多人觉得这个企业发展不错才会去。 创业的原始时期， 很多时候就是人少 事多， 简单代码三台服务器。 这个代码写的水平跟大学毕业两年的基本水平差不多。 代码简 单堆砌蛮多。三台服务器就是一台 Web 、一台服务器和其他一台系统就跑起来了。他们要 渡过非常艰难的时间，当你解决了生存，论证了你生存可行

10、性之后。电商进入第二阶段高速发展期，基本上在电商创业快的半年后开始，慢的一年后开 始，高速发展期对技术的发展来讲面临一个问题就是你的系统改良和升级的问题。 尤其说在 这个阶段当你融到了钱的时候可以做一些事情， 但是这个时候你的矛盾出来了。 这时候是公 司要求快步前进的时候， 公司对于技术系统唯一的要求就是不要拖业务的后退， 他没有任何 其他的要求。 这是非常实际的一个问题， 这跟很多人业务的技术， 我们称为完美性是矛盾的。 所以这时候对于技术的压力主要来自于你业务模式快速变化和你想做系统升级之间的矛盾， 这个矛盾不仅来自于技术本身代码升级的矛盾， 还有项目技术和公司需求的矛盾， 这是综合 事情

11、，你要把握这个节奏，否则给公司将带来很大的问题。第三个阶段称为规模制胜期，当你在公司业务模式相对比较成熟，你的竞争门槛建 立之后， 你的电子商务进入到你要以一个规模制胜， 基本上京东、 凡客以及当当这几个企业 是在这个阶段， 他已经论证完了商业模式的成功， 并且经历了高速发展，融到很多钱， 这要 建立一个不可逾越的规模门槛。 这时候对于很多企业的技术来讲， 进入第三个时间就是技术 的重构期， 这个时期你的技术会经历一个质的飞跃。 这时候你整个公司驱动会变成， 这里我 写的是一个商品，没有写产品， 我怕大家混淆，这里商品就是我卖的东西。 这个时期对于技 术来讲，就是把握好这个时期， 公司有钱有人

12、，并且公司希望你把技术的架构打实，为公司 的长治久安和未来得高速竞争建立一个非常优良基础。 这时候把握好， 就是真正的技术要做 一个大调整和大改进的时期。如果一个企业经历了这个时期，当他进入亚马逊这样的水平的时候，可能中国的企 业除了淘宝比较激进，其他的电子商务基本上没有进入这个阶段。当你进入这个阶段之后， 发现真正变成技术驱动期。 亚马逊说自己是技术型企业的时候你会发现技术决定了一切， 这 个时候其实技术的角色才真正从核心变成从驱动。你的技术创新成为核心竞争力。我说这四个时期并不是告诉大家，你每一个企业要经历这四个时期，当你实际投入 一个企业， 特别是投入一个真正的创业型的电子商务企业的时候

13、， 你很难逾越这四个期， 你 要面临很多实际的问题，业务挑战、人的挑战、时间的挑战、钱的挑战。我在后面会讲具体技术架构的东西，这是我们做技术或者是架构过程中，我们在方 法论上需要思考的问题。 你要想清楚技术在整个公司中定位的问题。 在相当长的时间内其实 你会发现一个问题就是业务驱动技术， 这件事情怎么理解呢？基本上是业务人员追在你屁股 上，让你赶紧做完这个系统，他们要发表。你在这个困境的时候发现自己很痛苦， 既想做完 美的系统， 公司不给你那么长时间。 我们说你一定经历这个阶段之后才会达到技术驱动业务 这样一个阶段。 如果你一开始定位就想说业务驱动技术的话， 这个基本上就是太美好、 太理 想化

14、的事情。第二个事情就是在一个公司的技术架构里面，你永远就是以服务业务为第一宗旨， 同时我们追求实用主义，你一切技术架构是为了解决问题而服务，解决问题就是为了更快、 成本更低来解决问题服务， 除了这两个问题其他不要追求。 只有这样才可以和公司的利益目 标达成一致。第三个我们称为永久追求安全第一、完美第二，这也是我们领导在很早之前就给技 术下的一个目标。 你任何创新和完美性追求一定是建立在安全第一。 安全这个词有几个方面 含义， 不是说你网站多么安全， 会不会被黑客攻击， 而是理论和技术系统就是保障业务的基 础上做的。 电子商务的系统基本上会分为规模复杂度和逻辑复杂度， 这是两种完全思维模式 的东

15、西，需要完全分别不同对待，不是简单的对待。再一个就是不理解生意，无法做系统。电商行业是一个特别明显的一个行业，你可 能做其他的时候角度不一样， 其实凡客本质上是一个零售， 所有电商是一个卖东西的。 卖东 西就是做生意， 你说你在网上卖东西和线下卖东西有区别吗， 没有区别。 你在网上卖东西也 没有比线下卖东西高级多少，很多在传统零售业做很多年的人比网上卖东西的人聪明很多。 比如说这个事情本身是一个生意， 如果你不理解生意本身， 你是无法规划系统， 拟规画系统定是跟生意本质是脱节的。 当你在做电子商务这件事情的时候首先要理解电子商务商业模 式本身你要做什么事情，你是满足什么样的理由。营销，这个意思

16、是这样的，任何一个企业都有一些驱动力。这里并不是说技术，其 实电子商务至少从目前的自有品牌电子商务发展来讲，他首先的驱动力来自于营销和产品。 比如说决定你这个事情成功与否的核心竞争力首先来自于营销和产品。 然后会过渡到产品和 技术，最后会过渡到技术为王。后面我会大概分几个步骤来大概说一下凡客走过的一些路， 我的 PPT 里面并没有向 大家展示未来会怎么样， 我只是告诉大家凡客曾经怎么样。 因为未来怎么样其实大家没有异 议，因为你要真正做系统的时候很多阶段你是跳不过的， 我也特别希望大家可能会少走一些 弯路，去做一些直接就进入到另外一个层次。凡客从 07 年发展到现在做了三四年的时间，当你面对应

17、对大规模放吨时候，对于 电子商务来讲首先第一个挑战来自于数据库， 电子商务就是一个数据访问。 属于你把数据库 搞定，基本上搞定电子商务的 70 、80% 的事情。这也是为什么很多电子商务可能我们不说 名字，他用小型机和 Oracle 扛了好几年。他在不停请了全国最牛的 Oracle 的专家不停优 化他的 Oracle 和小型机，他初期发展非常多年，后来放弃了Oracle 转向 MySQL 这种分布式架构的东西。电子商务如果你搞定数据库基本上就搞定他80% 业务。07 年的时候当时做的非常差，做前端、后端两个独立数据库，还用两个双向复制， 当时双向复制技术不成熟，我们在 08 年初很短的几个月内

18、就取消这种东西， 因为这个东西 非常痛苦。其实整个 08 年我们凡客基本上是在一台集中数据库上处理， 08 年你访问凡客 就是一台数据库。 08 年大家可能不记得凡客是什么样了， 因为他也没有那么多。 我们在 07 年底取消了两个独立数据库之后， 我们一下子发现我们的处理简单化了， 你再也不要考虑数 据库之间调用的问题， 你会发现一个数据库很美好。 你也没有精力搞一个负责架构， 那时候 大家都在忙着写代码，都在催着这个系统做起来。09 年的时候凡客经历了一个数据库的初期阶段， 读写分离和横向扩展以及一个纵向 拆分的事情。 这个事情很简单， 你随便找一篇文章会介绍很详细读写分离怎么做， 基本上这

19、 些事情搞定，请一个 EPA 这个事情搞定。当你把前台是指网站，后台可以理解为下完订单 之后所有系统的处理， 当你把前台指数和后台指数做完之后你的瓶颈也就没有了。 你横向浏 览和扩展能力， 这时候也蛮简单， 就是这样处理了。 当然你内部订单交易流程当时也是在集 中在可读数据库上， 所有修改在可读数据库上， 你所有只读的访问都已经被分散到各个的只 读数据库。 09 年我们完善了高可用东西。 2010 年我们凡客进行了纵向拆分，可能很多人 已经对我们比较熟悉了， 成为了我们的用户。 我们逻辑进行纵向拆分， 主要是为了分散中心 数据库数据复制压力。其实数据复制这件事情搞来搞去一定会出现瓶颈，不管是

20、MySQL 、 Oracle ，如果你一味的依赖于数据库复制，当你发展到一定规模之后他总会遇到瓶颈。基 本上就是因为你复制延迟， 当你主数据库下面需要复制的机器越来越多， 并且呈树状发展的 时候肯定会从下级数据库复制到下下级数据库， 但是你这个过程中也会面临一些问题， 你机 房一定要分拆出去。 比如你有些子系统发展非常庞大， 一定要拆出去。 数据库复制变得越来 越庞杂， 也会变得越来越脆弱。 单独依赖于数据库复制会遇到瓶颈的， 这其实也代表你的企 业发展也蛮不错。我们在 2010 年进行了这样的纵向拆分，把用户数据库、订单数据库、产品数据库 拆分出来独立让它发展。 核心数据库只用来处理核心的订

21、单处理流程， 很多比如说产品的修 改，很多用户修改之类， 放到子系统当中让他自己发展。 我们所有查询都是使用各个系统自 己的查询数据库。 你会发现当电子商务发展到一定阶段之后， 除了对数据读取这个事情， 除 了用户浏览压力之外， 还有一个压力就是你内部系统的访问。 什么意思？就是当你业务发展 到一定程度之后，你内部所有部门，你财务、 BI 部门，已经严重依赖于他的查询。你发现 这个系统出现问题很大一部分都来自于内部查询，有 N 个表。这时候你只能把查询扔出去， 否则你的系统很快会宕掉， 莫名发现这个系统慢了， 是某个人提交一个查询， 可能是财务部 门要查一个去年的什么数。我们允许我们的外围业务

22、系统数据库独立发展， 规模复杂之后， 要把你的外围系统， 你的配送系统甚至是你的仓储系统、 客服管理系统， 这些东西你只能把外围业务数据库剥离 出来，放到他外围系统允许的地方发展。一定要把你核心的表规划好，其他的就不要管了， 也管不过来。 下面说数据复制的逻辑复杂， 刚才说到了。 我们 WMS 系统数据库功能性剥离， 子系统复杂度增加不会影响到整体的负载。因为技术这件事发现很难控制到统一流程当中， 你一定要把他放到个子系统让他独立发展， 这个事情才做的比较好。 然后到一个系统、 一个 流程里面无论怎么优化系统都优化不好，可能优化你是没有办法了。我们面对数据库复制的瓶颈以后，我们还是有一个主数据

23、库下面分出几个子系统数 据库， 然后各自完成各自复制， 然后再增加。 我们将来可能会取消掉主数据库，会完全按照 一个字系统的星状连接扩展。应对问题的时候我们有两种思路，一种就是拿钱买时间，另一种思路就是拿时间换钱。什么叫拿钱买时间，其实很多事情你是可以用钱来解决的。随便举个例子，他不用无F5 ，他自己用 Linux 搞一个负载均衡可以解决这个事情，有些公司就买 F5 ，当你用 Linux 做的时候就瞧不起做 F5 的，觉得他们很低级。电子商务在我们眼里如果你的企业是高速发展的话，你要优先考虑拿钱买时间，你 大概买一个 F5 设备，然后处理大概也就三天的时间节可以解决你的问题。你去请个高手整 一

24、个 Linux 集群做负载，前景蛮好，但是需要很长时间，表面上节约几十万，公司角度上 来讲你是赔了，这个帐是不对的。大家能用钱买的买一些设备，你去用一些 CDN 的服务， 把机器放到好的机房里面。这些事情搞定之后也能解决你相当一部分的问题。再一个就是我们在下面有一些比较细节的东西，其实你会发现整个系统里面大概你 只要让你的系统具有横向扩展能力，这个事情好办了，我们有 F5 ，这个事情就跑起来了。 你有多少访问没有关系，我们加机器就可以了，机器很便宜的。你让你的 WEB 服务器首先 做成 Sesson 无关，现在电子商务越来越多加入 SNS ，把一个事情搞得很复杂。其实电子 商务就是纯购物，特别

25、简单，浏览、购买，没了。浏览是完全跟 Sesson 特别没有关系的 事情。购买可能多少有一些关系，国脉需要一个购物车之类的，最重要一点我们直接用 COOKIE 了。很多企业现在都改成服务端购物车，服务端里面你购物车存在你一个周期的 一个地方。一方面提高体验，购物流程里面你发现商务车完全不需要 Sesson ，跟它无关。数据库这个问题我说的电子商务行业，不是指所有电子商务行业，我说的是凡客这 样的电子商务， 因为淘宝是另外一件事情，是我们无法比的。 你会发现他有几个特点， 他们 基本上他的商品数据很少，特别是对自有品牌建设，商品数据很少。凡客发展到现在， 他的 整个发展也没有到 100 万 SQ

26、 。才几十万产品数据， 比如说你的用户量， 当你用户量到 1000 万的时候，你的生意已经非常不错了。因为整个 2010 年凡客用户量才 1000 万。有时候 你会发现这个事情，几十万的 SQ ，几十万商品数，几百万用户量这是多么小的数据。你各 种各样稀奇古怪查询产生各种各样的锁导致你的性能急剧下降。你要解决这个锁其中大部 分，你的性能一下子上去了。我们要理性对待面向对象和存储过程。凡客至今也使用大量的存储过程，我们从第 一天开始就没有告诉大家说你不要用存储过程。 因为存储过程在很多时候解决很多问题的非 常有效的一个方案。 当然我们在内部的时候， 你整个面向对象也做了很多 API ，我们基本上

27、 是大的对象，不是小的对象。基本上还是大的对象，我们需要对子系统进行这样的划分。在我们整个技术逻辑当中我们是以结构类型是第一位的。让你的业务内部数据保留 子系统， 总体一个原则就是让消费者访问的数据库尽量的轻， 只要沿着这个思路走下去， 你 就可以解决用户体验的问题。 你会发现这个事情来自两个方面， 一个是消费者访问， 特别简 单，我刚才说的浏览、 购买，是非常单纯的行为。 其实大部分的行为都是你内部系统在做的， 当你把消费者访问数据库剥离足够的轻， 任何外围系统干扰减少最低的时候发现这个事情特 别简单，电子商务就是卖东西这个事情特别简单。当然还有一个，当你在应对大规模访问的时候有一些系统稳定

28、性的追求，来自很多 方面， 来自网络稳定性、 数据库稳定性。 我们基本上把握两个原则，第一我们需要消除任何 单点故障。 不光是网络上单点故障， 还有来自你呼叫中心里的单点故障， 只要你有这个单点 故障一定要消除掉。 为什么？因为你电子商务每一秒都是钱， 电子商务宕机一个小时， 损失 多少钱这个帐可以算出来的。 很多时候特别是对电商来讲你需要非常全面的技术系统监控报 警系统。有时候你会发现你如果通过技术系统的监控去推导出你的技术发生问题已经晚了。 那时候基本上你公司损失已经造成的时候才会反映到你的技术系统监控当中。 当然你也可以 把技术系统监控指标设的非常低， CPU 超过 20 就马上报警，你

29、也受不了天天给你报。基 本上你除了技术系统监控之外还要格外重视你的业务监控， 如果按照一个正常访问， 他在一 个正常时间点每一分钟至少有一张订单。 如果你发现有一段时间有两分钟之内整个公司没有 一张订单， 不用问你的系统一定哪里有问题。 这个问题不一定哪里猜得到， 各数据库有一个 峰值，可能有各种各样问题。但是所有业务系统来的报警是最准确，而且是预先报警。我下面说一下我们认为的业务复杂度，大家在外面看电子商务行业的话，大家认为 比较简单，就是一个商城。其实在整个系统里边他是有很多很多系统组成的。拿前端来讲， 商城是完成互联网销售的一个系统，除了商城以外你会发现在整个系统里面还有很多系统， 比如

30、说通用促销系统， 电子商务做完之后每天他在不停做促销， 模式不停发生变化。 基本上 电子商务在初期是靠促销驱动的， 而你促销模式在不停的变， 你需要一个系统来解决你促销 驱动的办法。我们还需要有一个市场营销支撑系统，基于 ROI 市场推广提供支撑。解决我 哪些应该花钱，哪些渠道不应该花钱，一定要有一套 ROI 系统的数据分析的东西。还有我 们网站联盟系统，在电商里面很大部分是以 CPS ，按照效果分成方式来做营销推广。你为 了满足你按照 CPS 系统做推广发现需要有一套很完善提供给你 CPS 合作伙伴这样一个平 台，可以查到从我这边广告效果怎么样， 可以分到多少钱。 我们还需要有一个日志和用户

31、行 为分析，这个系统主要是解决告诉我们用户从哪里来的， 后来去了哪里，为什么消失了。他 整个流程衰减率是多少，我哪些需要优化。在你的后端里面其实电子商务系一个特别复杂的系统，特别对自有品牌像凡客这样 的电商， 他要比纯渠道电商还要复杂。 因为凡客还包括一个服装公司， 产品设计和制作公司。 你会发现他里面有很多， 其实还有很多子系统。 凡客有一个很大的呼叫中心， 他呼叫中心规 模应该在所有电商里面是最大， 他完成电话销售和退换货， 我这里写了一个退换货干预， 是 一个流程。 我们需要有 WMS 仓储系统， 通俗一点就是未来进货和仓储管理还有补货， 就是 提高这个效率。 还有配送监控系统， 就是为

32、了解决如何最快送达这样的还有供应商采购流程 系统销售预测、 补货、 生产监控、 合同管理。 产品生命周期管理， 从设计管理到量产、 改进、 下架这样的过程， 还需要非常复杂的财务结算系统， 把帐算清楚， 应该给我的合作伙伴分多 少钱，给供应商结多少款，这个系统听起来很复杂，他是传统的ERP，跟互联网无关，但是你必须要解决的。还有 BI 系统是通过数据驱动等等这样的东西。这里应对逻辑复杂度，这个命题很难，如果我们讲表面的东西，我要做SOA ，子系统抽象是很虚的。 任何一个人都知道要这样做， 但是你把这个事情落地其实很难， 特别是你 面对这么复杂的电子商务系统要把一个 SOA 系统落地不是那么简单

33、， 你要有很多很多业务， 他是一个经验系统。 你首先是一个业务专家才可以搞， 如果米只是一个技术专家这个事情基 本不靠谱，这个事情你想都别想。凡客也在走 SOA 之路， 也在阶段当中， 我们首先会按照业务自制原罪进行划分子系 统。业务资质可以理解为有一定业务边界的子系统。 业务边界可以按照自己的理解去做， 退 换货是一个子系统，可以把它拿出来作为 SOA 处理。我们在 SOA 内部保留了传统架构，我们在外层把他做了划分。 这里面有一个原则就是拒绝分布式事物。 所有一旦涉及到跨系统 事物，我们回用数据库及方式消除。我 SOA 背后并不是对对一个单独数据库。我们会把订 单、用户、产品作为子系统发展

34、出来。我们在解决逻辑复杂度的时候会发现，尤其是解决一些问题的时候发现，其实我们 通常有一个问题是没有技术解决不了的问题， 无非是问题高低的问题。 其实你很多问题从人、 流程、 工具软件角度思考和努力，有时候不需要技术参与。你稍微改变一下流程， 技术就不 需要解决了，技术解决的复杂度被大大降低。 很多问题是伪问题， 不是真正的问题。这个问 题要真正做的时候才可以思考。你需要考虑你的技术成本 ROI ，投入产出的问题。你一定 要搞清楚 B2C 变化的系统是怎么样的， B2C 系统本身是布置变的，有些东西是每天都在变 化，不变东西做好之后他变换周期很长， 每年调整一次。 举个例子，你商城购物流程变化

35、很 少。但是有一些业务是每天都在变化， 比如我营销推广模式每天在变。 还有一个东西会变就 是你的订单处理会变， 我管理精细化和我公司业务部门成长， 我每天都在修改我订单处理流 程。原来我有一个减货、 出库就完了，中间没有任何监控，因为他一天处理几百单不需要监 控。当你随着企业规模复杂之后，今天加一个环节，每天加一个环节，客户不停要求你，订 单状态不停在增加。 订单这个主线来看， 电子商务是以订单为中心的任务处理， 他是个工作 流。对于我们的营销推广来讲，我们可能要抽出一个模型出来，我需要在内部做抽象， 我把来源监控定义为 Source ，我把我所有营销推广渠道进行一个抽象化，我把 CPS 作为

36、 一类，门户作为一类，大渠道下面再分。新浪门户做页面，页面每一个广告位作为一个 Source 值，还跟你每一期的广告素材形成一个唯一的 ID 。当你把整个模型抽象出来之后， 会发现不管你的营销推广和你的媒体投放如何变化，你统统不用管，让他自己定义就可以。比如我们的订单处理，我们的流程，如果看成是一个订单处理的任务队列的话，你 在后面， 如果你写这样一个核心的系统的话， 你会发现你增加任何的一个订单状态也是非常 简单的事情， 你只需要增加一个任务队列就可以了。 因为你的任务队列你已经抽象好了， 你 的任务队列允许批处理， 允许分析不同的人， 允许监控你每一个任务分配了谁， 你的任务队 列处理的效率怎么样。 这个队列处理完了要交付给下面哪个队列。 你会发现订单流程无论如 何变化他是一样的。他是增加一波人处理这样的事情，首先请求一批订单任务然后拿过来， 然后分配给不同人处理，订单任务发生改变，整个批处理完了交付下一个环节。你的客户、 仓库、配送也是这样的。比如我的仓储系统，你做的时候发现里面很大挑战，你原来有