站长资源网站运营

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

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

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

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

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

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

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

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

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

基于SOA架构理念，降低系统耦合性，接口定义清晰明确，保证独立子系统的健壮性高，降低故障跨系统扩散风险，从而将伸缩性的困难逐步分解到各个系统。
对系统进行分级，集中力量，突出重点系统。当当网从卖场到交易流程均属于一级系统，这部分系统直接关乎用户体验和订单量。在系统稳定性和可靠性等指标上，设计标准高于后台系统。
优先考虑用异步处理代替同步处理，做好系统异常的降级方案，保证有限的合格服务。
在描述电商平台峰值系统的设计之前，通过下图可简单了解当当网电商平台的几大组成系统：卖场系统，促销、会员系统，商品管理系统，交易系统，订单管理系统，仓储与调拨系统，物流与配送系统，客服与退换货系统等。

系统分级

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

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

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

二级系统则包括商品信息系统、订单系统、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中给出了主要信息流。

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

批量、批次操作

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

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

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

分流

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

限流

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

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

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

促销系统重构

如今大规模促销已经成为大大小小的电商平台及入驻商家运营的常态。随着业务的复杂化、运营的精细化，以及品类、平台、渠道的不断丰富，各种新的促销形式也层出不穷，贯穿从商品展示、搜索、购买、支付等整个流程，电商对于精细化、精准化促销运营的需求也越来越强烈。

一次促销活动几十万商品，一天之内几十个、上百个促销活动已是家常便饭，至于入驻商家的常态促销更是不胜枚举。双十一期间，电商平台和商家更是会使出浑身解数，火力全开，无品不促销。

促销规则支持分时段设置，多个活动能够叠加，促销系统中的数据量甚至会超过商品信息系统，而且促销内容会根据执行效果快速调整，这些都对促销系统提出了更高的要求，促销系统越强大，促销活动才能玩得越疯狂。

我们在重构前面临的状况，是促销模型比较陈旧、扩展性差，促销系统成熟度低、与其他系统耦合严重，新增一个促销类型可能牵动从单品展示、搜索、推荐、购物车、交易、订单、退换货、库存、价格、促销自身等一系列产品线的变更。因此，促销系统的重构势在必行，数据模型与运营的贴合度决定的扩展性、灵活性，系统解耦和更强大的数据处理能力，是核心改进点。

最基本的促销模型很简单，如下图：

在当当，有一些“类促销”业务，从广义上可以归入促销范畴，但业务与数据均不属于促销系统，在设计中，我们考虑将这类业务逐渐回收；另外，促销系统能不能承担一些营销的功能？带着这两点考虑，在促销基础上进一步抽象出活动模型。

什么是活动？我们认为任何一个有时间范围的事件/动作均可称为活动，活动则抽象为三要素组成：基础信息、维度（条件）、工具（动作）

例如，在11月1日10:00-12:00在第一会议室开双十一准备会，讨论双十一各系统需要准备的事项，需要各系统负责人参加；那么这个活动的基础信息包括时间（11月1日10:00-12:00）、主题（双十一准备会），维度包括地点（第一会议室）、与会人员（各系统负责人），工具（动作）包括议题以及讨论本身。

那么推而广之，理论上，只要有相应的工具对接，可以用这个极简的活动模型，去管理任何一类活动，这样模型就变为了两层：

实际业务中我们遇到过的一些关于促销计算单元的头疼问题。买了一堆商品，到底哪几个应该作为一组计算条件和优惠，在促销叠加的场景这一点显得更为复杂。所以我们引入作用域来定义这个计算单元的范围。例如常规的限时抢促销，每个SKU有自己的价格，那么SKU就是这个促销的计算单元，也就是促销的作用域；例如第二件5折，可能会按SPU来做，你买一个红的一个蓝的，还是能享受促销，那么SPU成为了这个促销的计算单元；诸如此类，现有及未来可扩展的还有店铺、品类、品牌等等。简言之，这个作用域成为促销计算引擎进行计算单元分组的依据。于是模型又变成了这样：

举个例子，我们要在11月11日11:00-12:00针对IT技术类图书进行满200元减100元促销，购买过此类图书的客户每本书每人限购一册。那么这个活动的基础信息包括时间（11月11日11:00-12:00）、主题（程序猿光棍节福利）；维度包括商品品类（IT技术）、用户范围（购买过此类图书的客户）；工具是满额减促销、以金额满200元为条件、减100元为优惠，此外还有限购策略为限购1本，作用域为参与活动的所有商品；

可能这里会引发困扰，基础信息的时间为何不能算做时间维度？维度也定义了一些限制条件，那和促销工具模型里的条件有什么区别？时间之所以不归入维度，是基于前面对活动的定义，时间范围是必须的，而维度是可选的；促销模型中的条件只对于促销工具有效和有意义，而维度则有更广泛的普适性，例如平台、渠道、地区、用户、商品等，与工具是什么并无关系。

基础模型定型之后，我们开始着手解耦方面的设计：

首先是系统交互解耦，将直读DB和存储冗余促销数据的系统修改为调用服务及监听MQ；然后是逻辑回收，包括将促销校验与促销计算提取为交易服务，将原先由购物车、交易系统自行处理的促销逻辑回收；从业务上，将促销工具的属性进行提取，诸如类型枚举、促销标签、限购策略、库存策略等，以期外围系统尽量少的关注促销类型，通过促销ID拿到所需信息直接使用；未来则关注于业务层面的梳理与整合，逐步回收适用于活动模型的其他“类促销”业务。

系统解耦后，促销系统需要提供各系统所需要的服务，必须具备更强大的数据处理能力和更好的性能表现。应用架构实现上，从前端页面到后端逻辑，尽量避免有逻辑与促销类型直接绑定，全部以插件化方式与促销模型对接，完全根据促销类型的配置进行组装。针对不同维度、条件、优惠、促销属性，定制页面模板及业务逻辑，使得新增一种促销类型（在已有维度、条件、优惠下）仅需配置即可完成。

促销系统的查询服务需要同时为多个系统提供数据，对TPS要求很高，同时促销的时效性又要求很高的实时性。我们采用的方式是在数据库前加Redis缓存，提高响应速度，同时监听MQ，根据事件清理相应的缓存数据。

这种设计方案也有一些可能的坑，例如Redis缓存虽然减轻了DB压力，但对于计算密集型应用并未减轻应用服务器压力，IO没有节省还增加了序列化的开销；事件驱动清理缓存在读写分离场景下，有可能比主从同步更快，造成缓存数据错误。这也是具体应用中需要注意的地方。

促销系统重构上线后，使多渠道（终端）、多区域化营销成为简单易行的配置操作，显著提高了当当运营能力，当当双十一呈现出更多的想象空间。

交易系统重构

交易系统是客户购物流程中最重要的环节，主要任务是完成购物车中商品信息获取、拆单、促销计算、配货计算、运费计算、非现金支付的使用以及生成订单等操作，聚合各方面业务逻辑，计算非常复杂，而且响应速度影响购买转化率，一旦出现故障，直接影响营业收入，可谓电商最为敏感的核心系统，决定对其进行重构需要极大的魄力。

当当原有交易系统采用.NET技术框架，运行多年，很好的支撑了购买流程，但是弊端逐渐显露。首先是技术体系属于微软系，每年要花费大量成本购买服务；其次是随着业务需求的不断叠加，其结构及可维护性逐年下降，尤其是众多小版本结算的存在，使得功能扩展异常艰难。

基于以上因素，交易系统团队在2014年底启动重构项目，2015年10月底新老版本完成切换。此次重构耗费约1500人天，重构代码17万行，全部切换至Java开源技术架构，为公司节约大量成本，并进行了架构优化，整体性能平均提升25%。

交易系统业务主流程图如下：

交易系统重构引入了许多业界成熟的技术实现方案，主要有以下几点：

1. 集中化配置

集中化配置方式，一点配置，所有实例可见，更易于管理，而且配置修改后，通过热加载方式，立刻生效，快速便捷。而原有交易系统修改配置后，必须重启系统才能生效。

2. 页面缓存技术

用户请求一次交易结算页面，会调用各种后端服务，而由于逻辑的复杂性，每次服务调用都会调用订单计算大流程，导致页面刷新缓慢。新交易系统将大流程计算结果进行缓存，在一次页面请求范围内，后续调用直接用缓存结果，极大提高了页面的刷新速度。

3. 小版本合并

由于历史原因，交易系统存在很多版本的结算逻辑。最常用的是统一结算，还有一些特殊类型的结算，如秒杀、一键下单、补发货等等，逻辑与统一结算稍有不同，统称为小版本结算。因小版本结算与统一结算大部分逻辑相同，因此新交易系统将二者合到了一起，共享基础逻辑，而不同的逻辑则单独处理，极大提高了可维护性。

4. 灰度发布、无缝切换

借助了Nginx在运行状态下可以reload配置，而基本不影响对外提供服务的能力。每个Nginx负载两台应用服务器，灰度发布时，将Nginx配置更改为只负载一台应用服务器，即可对另一台进行部署。用户请求不会导向正在部署中的服务器，从而不影响用户下单。

5. 并行比对

交易系统重构后，尽管进行了大量的测试，仍不能放心部署上线。因为交易系统的计算都和金钱有关，必须慎之又慎，我们提出了线上并行比对方案，根据老交易系统比对新交易，保证其逻辑正确。原理如下：

1） 用户请求到达老交易系统

2） 根据条件将部分请求数据复制，发送至调用mock服务的新交易系统

3） 新老交易同时计算，结果存入各自的数据库，但只有老交易结果对用户公开

4） 对新老计算结果进行比对

这样，既实现了比对目的，又不会影响线上环境。

6. 分流

比对之后，新交易系统也不能立即全面上线，那样可能有巨大风险。我们开发了分流功能，按照用户id来分流，正式分流前，先使用测试白名单中的用户进行预验证。预验证通过后，再按比例由低至高逐步切换。

7. Web服务器按需伸缩

基于前面所讲的灰度发布技术，新交易系统很容易做到按需伸缩。正常情况下，每个Nginx负载两台应用服务器。双十一需要扩容时，将待扩服务器ip地址加入Nginx配置，重新reload，该Nginx就可负载更多台应用服务器了。

交易系统上线后为备战双十一，确保万无一失，利用老交易系统还未下线的条件进行了线上压测。为达到最准确的测试效果，且不影响正常系统运行，进行了以下的准备：

1. 测试环境、数据与生产环境一致

在准备测试环境方面，为了保证测试结果更接近真实结果，本次测试使用线上环境，通过大量测试账号对线上的真实促销商品进行测试，这样也对新交易系统所依赖的各系统服务做了检验。

2. 线上业务运行保障

测试阶段线上的请求切到老交易系统，压测请求发送到新交易系统，使测试和生产业务进行分离，保证了各自服务器资源的独立性。在应用服务器层面使测试过程不会影响到线上正常交易。

3. 拦截订单回收库存

由于使用线上环境测试，需要对测试订单进行拦截，避免进入生产流程，并回收占用的库存，使商品不会耗尽库存，采用的方法是在自动审单系统中将测试账户加入黑名单，测试订单提交后会被拦截，然后取消订单释放库存。为防止测试过程占用了商品的全部库存而影响线上销售，测试商品池基数很大，并且过滤掉了库存数量较少的商品，在执行测试过程中控制每个商品的使用次数，保证可销售库存占用在安全范围内。

4. 恶意用户策略控制

因为在交易下单过程中包含恶意用户判定的策略，会对用户进行隔离，禁止连续大量下单，线上压测时根据实际情况短时间内调整了安全级别，保证订单成功率。

经过多轮线上压测，新交易系统的高可用性得到验证，得到了实际性能指标，并根据双十一流量估算进行了扩容部署，将以崭新的面貌为广大客户提供稳定可靠便捷的网购服务。