当当网系统分级与海量信息动态发布实践

 

     

摘要：当当网各种大中小型促销活动常年不断，且活动的业务模式不尽相同，因此要求系统具备很强的伸缩性。本文结合当当网多年实战经验，讲述如何制定的系统伸缩性的设计原则和硬件常备策略，来应对各场景下的流量暴涨。

当当网自成立以来，内部技术体系的发展已经有15年左右的历史了。系统架构也经历了从高度集成的软件向分布式、低耦合、SOA化系统的演进过程，形成全面支持网上零售业各种业态模式的系统架构，每天支撑着千万级的PV访问，承载了超过100亿元人民币的年营业额，2013年双11峰值流量达到日常的10倍。

作为一个典型的自营与开放平台相结合的网上零售电子商务平台，当当网网上购物流程由多达上百个大小系统共同实现。当当网最终服务于消费者，良好的用户体验、钱物准确是立足的根本，因此对系统稳定性、可靠性、准确性有非常严格的要求。任何时候都能保证线上系统的稳定运行，是我们工作的第一优先级。电商系统的运行峰值通常出现在各类促销、营销活动期间，以及大量集中收订的订单带来很大的生产和配送压力时。

除了参加每年的双11和双12大促、每年的10月店庆、业内重要的庆典、两次开学季图书大促、换季服装大促、常规的新品和尾品大促以外，当当网每个月至少会有一次公司级别大促，而各种中小型大促常年不断。各种促销活动均可以闪购、秒杀、大量SKU促销等模式实现。网站流量的来源除了新老用户的直接登录以外，还包括多种站外引流方式如网址导航、联盟、搜索引擎、各种线上线下媒介、短信、邮件、微信等通道。

因流量来源的不同，相应用户的浏览、购物模式也大有不同。如很多促销落地页是当当网的“馆”，或者专题页，那么我们可以在活动之前做非常有针对性的准备；有时用户已提前准备好了购物清单，如双11这样的促销中，订单转化率会比平时高，体现在订单收订和卖场流量不会成比例上涨——如订单收订上涨6倍，卖场流量可能只会涨3~4倍；而一些外部引流方式会带来大量无效、垃圾流量，所以订单转化率会比正常流量低。

有的活动流量会对首页有较大影响；有的活动会对购物车有较大影响，如闪购类的限时购买或复杂的促销逻辑；有的活动会对当当网的仓储、配送系统有较大影响，如当当网配送的订单；有的活动会对开放平台有较大影响，如商家订单。

因此，摸清业务模式和活动特点，是设计和运维高峰值电商系统，即高伸缩性系统的重中之重。但从另一个角度来说，在没有动态弹性部署的前提下，过度的设计和服务器部署是一种浪费，特别是硬件非常有限的寿命会带来每年巨大的成本摊销。

当当网根据业务发展速度和业务运营规律，结合多年的经验，制定的系统伸缩性的设计原则和硬件常备策略使各流程能够直接应对日常5倍业务量的上涨。通过增加服务器的方式，能够应对10倍业务量上涨。而如果要应对10倍以上的上涨，则需要提前做有针对性的系统优化。但无论当前承受的业务量是否超过了设计范围，都不能影响设计范围内业务量的正常处理。

设计和部署大流量、高并发系统的技术方案选择比较多，业内有很多成功经验和案例。但根据我们的经验，设计高峰值的网上零售业电商应用系统通常要面对以下几大难点。

1. 应用架构复杂，业务发展快，迭代速度快，各系统之间盘根错节，历史包袱重。不仅有牵一发而动全身的风险，更有边缘case出错影响主流程处理、耗尽过多资源的隐患。
2. 从前台到后台的业务流程长，用例多。在能承受的最大峰值上，存在短板效应。设计实现时要面面俱到。
3. 通常促销活动的持续时间短而集中，前期推广活动已经启动，在活动期间，短暂的系统不可用，也会带来惨重的销售损失与负面影响，没有亡羊补牢的机会。要确保系统的稳定性，平时的工作就要做足。

针对这几大难点，有以下几大应对策略。

1. 基于SOA架构理念，降低系统耦合性，接口定义清晰明确，保证独立子系统的健壮性高，降低故障跨系统扩散风险，从而将伸缩性的困难逐步分解到各个系统。
2. 对系统进行分级，集中力量，突出重点系统。当当网从卖场到交易流程均属于一级系统，这部分系统直接关乎用户体验和订单量。在系统稳定性和可靠性等指标上，设计标准高于后台系统。
3. 优先考虑用异步处理代替同步处理，做好系统异常的降级方案，保证有限的合格服务。

在描述电商平台峰值系统的设计之前，通过图1可简单了解当当网电商平台的几大组成系统：卖场系统，促销、会员系统，商品管理系统，交易系统，订单管理系统，仓储与调拨系统，物流与配送系统，客服与退换货系统等。

图1  当当网电商平台架构

系统分级

对于电商网站，用户体验是第一位的，系统稳定运行是保证用户良好体验的基础。在资源有限的条件下，采取对系统进行级别划分的方式，对高级别系统保持重点关注，在设计、部署、监控等方面确保高级别系统具备良好的伸缩性、健壮性和敏感度，能够应对电商业务中不确定的极限峰值冲击。

当当网基于可能对用户产生影响的程度与敏感度，将所有应用系统分为三级，简单描述如表1。

表1  应用系统等级划分标准

依此标准，当当网的一级系统主要包括卖场系统、商品详情、价格系统、库存系统、促销系统、购物车、交易系统、支付系统、会员系统等。

二级系统则包括商品信息系统、订单系统、ERP、仓储系统、物流与干线运输系统等。

三级系统主要是结算系统、报表系统，以及运营、活动管理类系统。

其中一级系统基本可分为两类，第一类为面向用户访问的前端页面，第二类为购买流程所涉及的系统。一级系统的关键指标是可用性，在设计和部署时都要高标准严要求，要求具备完善的容错降级机制，日常保持较低的系统运行负载，配置高级别的监控告警流程，出现问题在要求的SLA标准内修复与解决。这两类系统的核心业务功能定位不同，采用的技术也不同，前端页面系统主要使用PHP语言，购买流程则主要由Java语言实现。

前端页面系统是电商业务的流量入口，需解决的核心问题是保证大流量高并发情况下的快速展示可用，这方面业界已有较为成熟的解决方案，如CDN、缓存、静态化、异步加载、与依赖的数据源解耦、同机部署、数据库读写分离等。通过这样的设计使前端无状态页面应用可以水平扩展，增加Web服务器即可提升系统能力。

为充分发挥系统资源潜力、提高性能，我们引入HHVM对PHP代码进行优化加速，经过性能测试验证，取得了显著效果，性能提升超过100%。现在当当网前端页面系统具备支撑10倍流量冲击的能力，面对超出极限的流量峰值，我们也有预案，主要采取延长缓存时效、本地静态化方式，屏蔽峰值流量对后端系统的冲击，并具备容错机制，在后端非关键服务失效时优雅展示等。卖场系统作为生成各种活动专题页面的工厂，支持通过配置将页面组件静态化，以满足更高访问量的要求。

购买流程是电商业务流程中至关重要的环节，一旦出现问题，将使前面的引流、促销、搜索、推荐等营销成果付诸东流，因此购物车、交易系统和支付系统必须确保用户购买结算过程的高效稳定，并保证数据持久化的准确性和一致性。

购物车与交易系统逻辑复杂，依赖服务众多，其中交易流程的实现依赖超过100个服务。我们梳理出核心业务流程，再根据与核心业务流程的关系，区分出对服务的依赖性强弱。弱依赖服务如积分、礼券、收藏夹等，通过较好的容错和降级机制，在业务量达到峰值时，可通过服务降级维持核心业务流程的稳定运行。对于强依赖服务中数据变化较少的配置查询类服务，则通过缓存数据来降低服务依赖关系，牺牲部分数据的及时性换取系统的健壮性。

交易型系统的业务，成功率是关键指标，可能因为分布式服务集群中部分实例异常或网络问题导致调用强依赖的服务失败，需要发起重试，为兼顾用户体验和减少对系统资源的占用，采用设置较短超时时间及重试其他服务节点方式更为合理。经过优化，购买流程的系统可用性指标达到了99.99%。

二级系统多数为后台订单与履约系统。在流量漏斗模型下，在一级系统内形成订单后，订单流转到二级系统，二级系统面对的峰值压力要小得多。

二级系统多采用异步方式进行系统交互，对于超出处理能力的业务数据，异步机制削峰填谷，使系统得以在可控的压力下运行。系统资源占用维持在较高水位，既能充分利用系统资源，又可以保证较高的处理效能。当然，异步机制带来的延迟问题也必须控制在合理范围之内，在业务量骤增时可以容忍一定程度延迟。如果平时就经常出现延迟，则需要进行优化，或者重新进行容量规划，提高系统整体的吞吐能力。2014年为应对双11及未来业务发展，当当网对订单系统数据库进行了扩容，规模达到之前的5倍，其他部分系统也进一步分库分表，使之具备承载更高业务峰值的能力。

系统分级是根据不同系统的特点，结合公司业务战略关注点进行的差异化处理。电商业务链贯穿多个系统，每一个环节都不容忽视。一级系统固然是核心优化的重点，二三级别系统的技术指标要求也同样严格。

我们对每个系统的可用性都有严格要求，并将监控系统列为一级系统，时刻关注木桶理论中最短的那块板子，我们的目标是打造一套性能均衡，没有明显短板，日常能够应对5倍业务峰值压力的电商系统平台。

解耦与SOA实践

经过多年实践，当当网逐步完成系统架构的SOA化改造，并通过SOA化，实现了服务解耦与高内聚，简化了架构复杂度，这是主流零售型电商平台通常选择的道路。基于分布式的服务使系统具备更强的伸缩性和扩展性，系统瓶颈更易定位和优化，满足业务快速增长的需要。

SOA即面向服务的架构，在业界并没有统一的标准，但有一些公认的设计原则：标准合约、松散耦合、服务抽象、可复用性、服务自治、无状态性、可发现性、可组合性。

在实际应用过程中，根据系统情况以其中部分原则为侧重点，不求全责备，简单实用为上。

2012年起，当当网启动一系列重点项目，首先对开放平台进行重构，使开放平台成为搭建在PIM、库存、价格、促销、订单、TMS等主业务系统之上一套具备更灵活的扩展性的业务平台。

这次重构是当当网近年的重大架构调整之一，之后各主业务系统陆续实现业务平台化，支持多商家甚至是平台级跨商家的业务模式。开放平台将原有独立管理的商家商品信息、订单流程迁移至PIM系统和订单系统进行统一管理，充分发挥服务的可复用性，减少重复逻辑的多点实现带来的开发和维护成本。

商品信息是电商业务系统中的核心主数据，是促销、价格、库存、礼券、搜索等系统的基础数据来源。PIM系统作为商品主数据系统，承担着管理商品基础数据、关系、品牌、类目和状态等信息的职能，商品数据量在千万级别。

PIM系统的SOA建设经过了两个阶段。第一阶段主要是实现服务化，因服务设计粒度过细，发布的服务达到数百个，其他系统要完成一个业务功能可能需要调用多个PIM服务，增加了服务使用方的逻辑复杂度，也带来了更多的网络交互开销，不能称为SOA的最佳实践。

为此，又进行了第二阶段改造，将第一阶段实现的服务定义为基础服务，根据业务需要将其组合，提供粗粒度的对外服务，解决了之前的问题。粗粒度服务能够提供独立的业务功能，可能同时依赖于多个系统的基础服务，当服务使用方因业务需要调用多个粗粒度服务时，可能会对同一个基础服务发起多次访问，产生叠加的系统压力。我们经过分析认为，底层服务资源的消耗能够简化上层应用逻辑，对于系统架构层次的合理性更为有益，只要提高底层基础服务的性能，上层服务能力将更具弹性。

遵循SOA的系统解耦有时会增加系统资源开销，甚至降低部分服务性能指标，但可使系统架构更为清晰，增加服务复用性，具备更强的业务扩展性，提高开发测试效率，降低开发运维的人力成本，及时响应业务创新，使IT系统重现活力。

通过上述系统架构治理，当当网以很少的临时性系统准备顺利度过2013年双11大促。

海量动态信息流的快速发布

当当网打造综合品类电商平台，开放商家入驻，随之而来的是商品数据量迅速突破千万。商品信息是电商业务流程前端的重要数据，是进行营销活动、生成订单的基础。商品信息在前台有多种展示页面，大规模营销活动期间运营人员需要进行大量操作设置，价格、库存等也会更为频繁地更新。目前库存日更新量峰值超过1500万SKU的变化；价格日更新数据量达500万以上SKU，极限峰值超过1000万，每秒可能超过1万。数据同步及时性、一致性指标关乎用户体验和营销活动执行效率，如此大量的数据，在各业务系统之间高效稳定传输，对系统架构提出了很大的挑战。

当当网的商品数据有多个来源，自营实物商品来源于ERP系统，电子书来源于数字业务系统，商家商品来源于开放平台，最终这些商品的数据都由主业务系统中的PIM、库存系统、价格系统集中统一管理，再发布到搜索系统、推荐系统、前端页面展示等系统。为了对商品信息中的关键数据同步时效进行监控，当当网建立了啄木鸟监控系统，覆盖了近20个信息流路径数百个节点，对超出同步时限的环节自动报警，以便及时处理，避免发生严重的延迟。

商品的关键数据包括商品基本信息、库存和价格，库存和价格都依赖于商品基本信息，对于不同类型的数据，根据应用场景区别对待。平台化之后，每个商品都归属于一个商家，以商家ID为维度进行散列，将商品基本信息保存在数据库中，支持水平扩展，可以满足商品数据不断增长的需要。对于历史版本的商品信息，则迁移至历史版本库，作为订单交易快照供用户查询。库存数据在前端展示只关注是否有货，并不需要将每一次库存变化同步，在库存变为0或从0变为正整数时触发状态同步，交易下单时实时查询当前库存即可，此种变数量为状态的方式极大地减少了同步数据量，提高了数据一致性。

价格属于高度敏感的数据，对于手机专享价等类型，业务运营有设置生效时间、失效时间的要求，为保证前端按照时间动态展示，我们将生效时间段数据也发布到前端系统，由使用方判断当前有效价格。图2中给出了主要信息流。

图2  主要信息流示例

即便已经对不同类型的商品信息数据流进行了差异化处理，仍然不能排除短时间内会发生大量数据造成系统同步阻塞，影响正常业务运营操作的及时发布。极端情况下，超出系统处理能力还可能导致系统崩溃。为解决此类问题，我们采用批量、异步、分流、限流等手段进行处理。

批量、批次操作

限制API调用频次的同时，我们提供批量API供商家对商品信息进行更新，批量更新方式减少了各环节交互次数，提高了系统吞吐量，更好地贴合营销活动中批量处理的需求。在系统内部，批量方式能够有效降低系统资源开销，并能对频繁更新的商品数据进行合并处理，提高处理速度，使数据更新及时准确。

增加异步处理，减少同步处理

信息流同步经过多个系统，每个系统处理逻辑和吞吐能力不同，采用同步机制可能导致上游系统将下游系统拖垮，因此采用异步机制最为稳妥。异步方式有两点好处：一方面起到缓冲的作用，下游系统依据自身能力控制处理数据量，避免遭受超负荷的冲击，保证系统稳定运行；另一方面实现系统隔离解耦，一旦下游系统出现异常，上游系统仍然能正常处理数据，不至于引发连锁反应。

分流

不同的信息对处理时效的要求也不同，库存、价格、商品上下架状态同步及时性要求很高，而商品基本信息，如名称、副标题、详情则相对较低。拆分不同的同步路径，对及时性要求高的数据配置更多的系统资源，既保障了敏感数据的及时性，又避免了数据积压相互干扰。同理，针对三种不同的数据来源渠道（ERP、数字业务系统、开放平台），也可通过分流方式保证自营实物、电子书和商家商品信息的及时同步。

限流

多数的商品数据来源于商家，商家会通过一些第三方系统与当当网开放平台对接，调用API进行数据同步。一些不合理的同步机制设置会频繁发起大量的数据同步请求，而多数请求属于无效数据，这类数据难以识别，会浪费大量的系统资源，干扰有效数据的处理。我们在开放平台对每个商家调用API的频次进行限制，根据商家商品数量合理分配，有效地抑制了无效数据的泛滥。

随着多年双11和集中促销模式的考验，电商系统的峰值设计理念和实践已经慢慢趋于成熟，但仍然是所有电商类公司技术团队的最重要任务之一。

当当网技术团队经过多年的沉淀，积累了大量处理电商业务峰值的经验。通过深入分析应用场景，对系统进行分级，SOA化完成系统解耦，并采用多种技术手段实现海量数据的高效处理发布，不断提升系统吞吐能力，确保为用户提供稳定友好的购物服务体验，充分体现技术力量在产业中的重要作用。

作者李震平，当当网技术部副总裁，负责电子商务平台的研发与团队管理工作。从2006年起加入电商行业，有多年实际研发与架构设计经验。

史海峰，当当网架构师，负责电商平台架构设计、技术规范制定和技术预研推广，参与重点项目的方案设计。