王海亚：淘宝交易系统演进之路

淘宝的交易系统承载了购物车、下单、订单管理等多项淘宝的重要业务，随着淘宝业务量的不断上升，交易系统也随之几经改造。InfoQ此次专访了阿里巴巴架构师王海亚，另外作为ArchSummit深圳2014大会《电商，各走各的路》专题的讲师，王海亚将会分享淘宝交易平台的架构演变及并行化实践。以下为专访全文：

\

InfoQ：淘宝的交易系统，主要承载了哪些业务？

\

\

王海亚：从用户视角来看，交易承担了购物车、下单、订单管理这些功能；从功能视角来看，交易系统包括做业务规则和服务整合的交易平台以及支撑交易功能的底层服务，服务包括商品、优惠、库存、订单、物流等，业务规则主要是确定在不同的购买场景如何使用底层服务的不同功能，比如什么样的购买要走付款减库存，什么样的购买要走预售模式的价格体系和支付体系，什么样的购买要限制使用积分等等。

\

\

InfoQ：请您简单介绍下交易系统的架构演进过程。

\

\

王海亚：个人把交易系统的演化分成三个阶段，第一个阶段是单应用阶段，那个阶段淘宝的业务比较简单，业务量也比较少，交易系统相对还是很简单的，当时的交易系统只有一个应用，囊括了商品、优惠、物流、订单等功能，一个小的开发团队就能够完成交易系统的开发维护工作。

\

随着承载的业务越来越多，交易系统变得越来越复杂，需要投入越来越多的开发来维护这个系统。人员规模上去之后，内部沟通的成本、代码管理的越来越高，大家都针对一个代码库做更新，很难保证非常好的功能模块设计，经过持续的代码累积，满足业务需求并行开发越来越难。后来提出了服务化改造，从原来的单一应用中逐步做功能剥离，拆分出多个系统，每个子系统负责不同的功能，由不同的团队维护。交易系统的架构进入第二个阶段，交易系统采用分布式架构，存在多个后台服务系统，多个前端应用。商品、优惠、库存等功能逐步沉淀成纯粹的后台服务系统，原来的交易系统作为前端应用存在。由于组织结构的原因，当时是存在几个交易前端应用，比如说当时的商城也就是后来的天猫，无线团队等等，因为前端内容的差异，都有自己独立的前端应用。

\

服务化改造之后，从某种程度上缓解了第一代架构的缺陷，但是新的架构在落地过程中还是存在一些问题，比较突出的有两个问题，一是由于功能是从原有单核应用中剥离出来时，缺乏一个明确的功能边界定义，对业务规则和功能的识别没有统一的标准，导致业务规则和功能存在紧耦合，同一个业务的业务规则一部分在前端应用中，一部分在后端服务系统中，业务规则变化又比较快，任何一次规则变化都要涉及到多个团队做配合实施，沟通协调的成本比较大；另外一个问题是由于多个前端应用，前端应用做的比较重，业务逻辑都要在多个前端应用中重复实现，除了开发的人力浪费之外，也引发了很多由于落地节奏不一致导致的业务问题，即使耗费大量精力做沟通协调也无法完全避免此类问题。

\

在新的系统架构中，对业务规则和功能做了明确的识别，通过集中式的业务规则控制以及功能定制化机制，实现业务规则和功能的完全解耦，多数情况下业务规则变更不会引发后台服务系统的变更，后台服务系统的功能增加也能做到对前端应用的透明。另外在前端应用中引入新的编程框架，通过框架做纯粹的服务整合就能组织出要给用户披露的信息。前端做轻之后，针对不同终端提供统一的业务服务，或者针对不同终端根据单页需要披露的内容来做不同服务的整合，成本都降低很多。

\

\

InfoQ：没有改造之前的交易系统，大概遇到了哪些问题？

\

\

王海亚：问题主要可以分成三类，第一类问题是业务快速落地很难，由于交易的业务规则变更很快，通过casebycase代码修改，系统中功能与功能之间的耦合越来越多，系统维护成本越来越高。另外业务规则散布在多个前端应用和后端服务系统中，经常由于各个系统的规则不一致或者上线节奏不一致导致业务故障。第二个问题是系统接入的成本很高，由于业务的需要，会引入越来越多新的服务系统提供对应的功能，这些服务都是在一个前端系统中做服务的整合，一个点的不稳定或者性能瓶颈，都会影响整个系统的稳定及用户体验，想通过小成本的尝试来做业务创新的验证成本非常高。第三类问题是前端应用比较重，业务逻辑主要存在于前端应用中，前端应用的页面逻辑和后台逻辑职责边界又不是特别清晰，导致前端应用的开发成本非常大，另外又存在多个前端应用，业务逻辑的一致性很难保证。

\

\

InfoQ：新的交易系统是如何解决老系统的问题的？

\

\

王海亚：总结来说，可以从7个点来讲。

\

第一，通过服务治理，把业务规则从原有功能中剥离，明确各个服务所提供功能的完备性及独立性，从系统边界上确保功能之间无耦合。

\

第二，通过集中式的业务规则管控，保证交易全链路的业务规则统一及业务规则灵活可配置。

\

第三，通过标准化的交易框架及组件化设计，保证服务在交易平台快速接入。

\

第四，通过异步并行及容错，提升系统响应速度，减少单点服务故障导致的整体不稳定。

\

第五，通过开关及预案机制，保证代码的兼容性发布，业务降级容错。

\

第六，通过流量管控，防止雪崩，保证在正常情况或者某个服务集群能力波动时，整个交易系统不被压垮。

\

第七，通过在前端应用中做前后端解耦，通过约定的数据模型，前端开发只负责页面展示和交互，实现前端、后端的并行开发，也使得不同终端的自适应可以以较低成本实现。

\

\

InfoQ：新的交易系统是如何应对交易洪峰的？

\

\

王海亚：由于交易的调用链路比较长，从Web服务器到执行链路中的各个服务系统，包括缓存、DB等存储系统，请求都是以队列的方式被处理。各个系统如果没有处理好容量控制，就会导致请求的堆积，对外呈现的就是响应时长增加。

\

在处理链路比较长的情况下，这种异常会被放大，链路后面的一个点发生堆积，前面的各个点也会逐步出现堆积。页面应用又是一个用户强交互类型的应用，如果用户发现慢就会刷屏，而后面的系统无法感知接下来要处理的请求是否是有效的请求，这种情况下可能会导致整个网站的瘫痪。我们目前是在前后端应用中都引入流量管控机制，主动拒绝超出自己处理能力之外的请求，保证每个应用都不会被压垮，有多少能力就能把多少能力提供出来。

\

另外在前端应用处理流控时，主动引导用户到低成本/静态化的页面上，增强用户体验，也能提高网站其它部分的曝光率。整个流量管控体系，除了应用框架的能力之外，还有一些配套的机制，比如自动化压测系统、容量计算公式、自动化扩容/下线等，整个一套体系，确保我们轻松应对交易洪峰。

\

\

ArchSummit全球架构师峰会即将于7月18-19日在深圳举行，此次会议重点解析九个当前最受关注的领域，包括：SNS、 移动互联网、 金融、 大数据、 智能硬件、 游戏、 云计算、自动化运维、电商等专题。目前正在火热报名中，感兴趣的读者可以访问网站主页了解更多信息。