电商峰值系统架构设计--转载
1.1 系统架构设计目录
摘要：双11来临之际，《程序员》以“电商峰值系统架构设计”为主题，力邀京东、当当、小米、1号店、海尔商城、唯品会、蘑菇街、麦包包等电商企业，及商派、基调网络等服务公司，分享电商峰值系统架构设计的最佳技术实践。
自2009年11月11日,淘宝商城（现名天猫）拉开网购狂欢节的序幕，各大电商的促销浪潮此起彼伏。此时的电商大战不仅是价格之争,更是技术的较量。如何设计电商峰值系统来更好地满足用户蜂拥而至的访问，如何在海量数据处理中实时发现有效信息并转化为商机，成为众多电商企业密切关注的问题。
值2014年双11即将来临之际，《程序员》杂志以“电商峰值系统架构设计”为主题，力邀京东、当当、小米、1号店、海尔商城、唯品会、蘑菇街、麦包包等国内知名电商企业，以及商派、基调网络等相关服务公司，分享电商峰值系统架构设计的最佳技术实践。让读者切身感受，这场购物狂欢背后的技术狂欢。
（4）京东峰值系统设计
（5）“米粉节”背后的故事——小米网抢购系统开发实践
（7）唯品会峰值系统的架构演变
（8）1号店电商峰值与流式计算
（9）如何在双11中创造99.99%的可用性——蘑菇街在大型促销活动中的稳定性实践
（10）履单流程的弹性架构——麦包包峰值架构实践
（11）电商峰值监控经验谈
文章来源：http://www.csdn.net/article/2014-11-04/2822459
摘要：随着电商促销规模越来越大，竞争点已不仅是价格，而延生到背后的技术：如何设计峰值系统来应对爆发流量，如何实时发现有效信息转化为商机，成为关键点。本文结合快稳炫三字诀，讲述电商峰值系统架构设计的最佳实践。
2009年11月11日，淘宝商城“光棍节”开启了网购促销全新规模的序幕，随后各大电商的促销浪潮此起彼伏且规模越来越大。在用户畅享购物狂欢的背后，电商系统承受着严峻的考验。电商大战已不仅是价格之争，更是后台和技术的较量。大型促销活动带来的是流量暴涨，在高访问量的冲击下，电商系统会受到以下挑战：瞬间访问量可能是*时的几十倍；网络带宽被占满，用户响应很慢；机器负载高甚至宕机；数据库压力过大导致服务不可用。
时间就是金钱，效率就是生命。如何设计电商峰值系统来更好地满足用户蜂拥而至的访问，如何在海量数据处理中实时发现有效信息并转化为商机，成为众多电商架构师都在认真思考的问题。针对峰值现象，各家电商陆续推出了自己的解决方案。设计良好的系统架构犹如电商*台的发动引擎，需要拥有非凡的动力系统以满足极致的用户体验和强劲的峰值承载力。
本期《程序员》杂志在基于海尔电商技术沙龙第九期研讨内容的基础上，组织了京东、当当、小米、一号店、海尔商城、唯品会、蘑菇街、麦包包等国内知名电商企业，以及商派、听云等相关服务公司，进行了电商峰值系统架构设计的最佳技术实践专题分享。
纵观上述各家电商峰值系统的架构设计，由于电商规模、商业模式以及技术选型的不同，其技术方案多彩多样、百花齐放，着实令人兴奋，全面展现了互联网技术开放和创新的特征。下面从这些架构设计方案中，抽象和总结出其共性相通的核心思路，进行一些概述。核心思路集中表现为：采用分而治之的思想，大系统小做，小系统大做。浓缩一下就是三个字：快、稳、炫。
快——天下武功，唯快不破
快的目标是确保用户端快速流畅的体验。概括来说，可以通过以下技术手段实现快的目标。
对前端页面的处理
· 将有效期较长的静态页面通过CDN（Content Delivery Network，内容分发网络）缓存到离用户最*的服务节点上。
· 将有效期较短或者需要对失效时间做最大限度控制的静态页面，通过类似于Memcache的高速缓存系统或类似于Squid的反向代理系统缓存在服务端。
· 将混合型页面（如商品单页）进行动静分离，静态数据（如商品介绍等）缓存在本地，动态数据（如可用库存和促销价格等）异步进行加载。
对后端数据的处理
· 数据库SQL慢查询优化。例如，重构相关索引，对where子句进行优化等。
· 数据库读写分离。例如，MySQL的Master/Slave结构。
· 数据库分库分表。这是减轻单个数据库服务器压力的有效手段，不过同时也会带来系统的复杂性，是鱼和熊掌之间的关系。
对网络传输的处理
· 执行负载均衡，第四层交换按实现分类，分为硬件实现和软件实现。通过硬件实现一般都由专业的硬件厂商作为商业解决方案提供，如F5等，这些产品非常昂贵，但能够提供非常优秀的性能和很灵活的管理能力。通过软件实现，如LVS等，虽然性能比专业硬件稍差，但软件实现配置起来更灵活。
稳——不管风吹浪打，胜似闲庭信步
稳的目标是确保系统端稳定可靠的服务。无论在任何情况下，都要做到尽可能不宕机、不出错。要做到这一点，可以在以下几个方面做文章。
系统解耦
拆分业务模块和功能模块，使得每个模块都做到高度内聚，然后用SOA，通过严格定义模块之间的服务接口，做到模块间的松散耦合。在一个模块发生问题时尽可能不影响其他模块的执行，尤其不能影响关键业务的执行。同时，可以对单个模块进行横向扩展，尤其是对关键的业务模块，以确保关键业务一定不能受影响。需要注意的是，模块划分的粒度应进行权衡，过细的粒度虽然可以带来更多的灵活性，但也会带来编程的复杂性。
有损服务
根据CAP（Consistency一致性，Availability可用性，Partition Tolerance分区容忍性）理论，三者不可得兼。对于电商*台，其中多数应用并不需要很强的一致性，因此合理的方式是用牺牲部分一致性来换取较高的可用性。有损服务（服务降级）就是一种提高系统稳定性和可用性的有效实践。在电商系统中，要优先保证类目浏览、产品单页和订单流程能够执行。
数据库减负
我们知道数据库是所有节点中最不容易扩展的，复杂的SQL查询条件会导致数据库负担过重，此时可用增加应用计算中间服务器的方式，通过高效简洁的SQL查询，应用计算中间服务器一次性地从数据库中取出最小全集的数据行，然后在内存中利用算法剔除冗余数据，以应用算法的复杂度换数据库负担的方式。
炫——运筹于帷幄之中，决胜于千里之外
炫的目标是确保业务端实时高效的调度。从日志收集和实时计算入手，通过对用户行为数据的可视化（图1），及时发现问题和洞察商机，调度应用系统，对用户多样化和个性化的需求进行智能引导。
图1 用户行为数据可视化
审视当下畅想未来，随着云计算的兴起和成熟以及智能移动设备的普及，电子商务与这两者深度结合，必将引起一场激动人心的变革。各种设备上的在线商城将是主流的商业模式，目前分类式的购物体验*台将演变成一个高度集成以用户为中心的全流程价值交互体验云*台。该云*台有四大核心组成部分，环环相扣形成一个闭环（图2）。
图2 全流程价值交互体验云*台
通过云屏（TouchApp），打造流连忘返的体验；通过云网（DataLink），提供随时随地的服务；通过云芯（FansTree），进行细致入微的洞察；通过云播（Broadcast），推送引人入胜的营销。
最后，请你放下手中的所有工作，找个阳光明媚安静的地方，泡杯香浓的咖啡，细细品味本期各大电商为你带来的最佳技术实践。
文章来源：http://www.csdn.net/article/2014-11-11/2822572
摘要：双11这样的场景要求电商对系统进行合理的峰值架构设计，以保证业务的顺利开展。那么一个能够应对短时间流量暴涨的电商系统，在同时考虑成本因素的情况下，具体会遇到哪些瓶颈，主要需要解决哪些层面的技术障碍呢?
*年来，随着电子商务交易额在社会消费品零售总额中占比的不断提升，电子商务越来越成为传统企业不可忽视的销售渠道之一，甚至很多具备前瞻性眼光的传统企业，已开始了利用电子商务手段改造其线下业务的探索。
但是，传统企业在执行电子商务项目的过程中，特别是在应对峰值方面，由于对互联网峰值架构的不熟悉，经常出现一些认识上的误区，造成系统上线后出现不稳定甚至连续宕机的情况，不但在经济上造成损失，而且对企业的品牌也造成了伤害。
作为电子商务技术与服务提供商，商派已执行了*千个传统企业的电商项目，收获了很多的经验与教训。下面我们就传统企业电商峰值系统的设计与维护过程中常见的问题进行探讨。
在一个典型的电商系统中，核心对象主要有三个：会员、商品和订单。整个系统主要是为消费者服务，运营模型以流量与用户量为核心，流量以导入新客户为主，用户量代表着老客户的贡献。无论是大规模进行新客户获取还是老客户营销，都会给系统带来极大的压力，其中特别是限时抢购、秒杀等营销方式尤为明显，这就要求我们对系统进行合理的峰值架构设计，以保证业务的顺利开展。那么一个能够应对业务峰值的电商系统，在同时考虑成本因素的情况下，具体会遇到哪些瓶颈，主要需要解决哪些层面的技术障碍呢？
大规模查询优化
对会员与商品的大规模查询是一个常见的场景。例如，在一个秒杀系统中，在开放购买的时间点附*，会产生大量的基于会员和商品的查询请求，通常情况下，比*时的请求量会多数十倍甚至百倍，同时访问带宽也会相应大幅增加。在我们以往的运维实践中，曾经出现过由于带宽预估不足造成无法访问的情况。
应对类似的大规模查询业务，只依靠数据库的能力是远远不足的，因此，我们需要用到大量的缓存架构，将峰值的访问压力由磁盘转向内存。一般来说，商品的主数据、会员的登录，系统的Session、页面都可以采用Memcache、Redis、Varnish等KV架构进行缓存。另外，某些动态数据在特定业务场景下也可以进行缓存。例如，由于库存量在下单前只用于控制前台是否可售展示，对一致性要求不高，只要求保证最终一致性，因此也可以在此场景下使用内存进行缓存。
商品搜索和基于属性的面包屑导航等场景，在峰值下对数据库的压力也非常明显。由于该业务不具备高命中率的特征，所以缓存解决方案不适用。我们通常需要使用搜索引擎去解决，一般常见的搜索引擎解决方案有Sphinx、Lucene等。前台的应用服务器需要设计成无状态的可水*扩展架构，这样在高负载下只要通过简单地增加应用服务器即可通过负载均衡设备线性扩展前端的负载能力。
分布式架构设计
一个完整的电商系统，分为前台交易系统与后台作业系统，前后台共库是传统企业在设计电商项目时的一个常见做法。但这个做法引发了上线后的诸多麻烦。在前台交易系统处于峰值情况下，数据库本身已存在很大的压力，此时如果后台作业系统产生大规模的查询或写入请求，则很容易造成数据库无法响应。我们在很多客户案例中发现，如果前后台共库，正常非峰值情况下，每日订单数只要超过2000单，就会不同程度地出现前后台互相干扰，数据库成为主要瓶颈。此时，客户不得不在系统高峰时停止在后台作业系统上的操作，这给业务造成了很大伤害，发货延时、客服水*下降、统计不准确等情况成了家常便饭。实际上，从架构上来说，前台交易系统与后台作业系统服务的用户对象不同，前者是消费者，后者是企业内部员工，完全可以进行系统分离，两者之间采用消息队列进行异步订单传输，以隔离互相之间的影响。
当然，对于交易系统，我们也要根据业务特征进行分布式设计，提升业务扩展性、应对高负载。例如对商品货架系统、会员系统、核心交易系统、资金系统、日志系统等以高内聚、低耦合的原则进行分离，以分别根据不同的访问特征进行优化。
根据分布式架构的CAP理论，Consistency（一致性）、 Availability（可用性）和Partition tolerance（分区容忍性）最多只能同时满足两点。对于一个峰值系统而言，分布式（分区）设计是必然的，可用性也是基础要求，因此，我们只能放弃一致性要求，只达到最终一致性。不过，在一个电商系统的架构设计中，最容易出现的问题是滥用CAP原则。例如在交易过程中，后台的供应能力（库存）是至关重要的，在交易生成过程必须要保证严格一致性，而不是最终一致性，这就要求我们以事务的方式来解决。否则，虽然在架构实践中很容易达到从容应对峰值访问的目的，但超卖等伤害业务的现象必然会出现。
在分布式系统设计中，必然要求我们采用面向服务的体系结构（SOA）。但需要在设计中注意几点。第一，在峰值系统中，每一个多余字节的传输都意味着对系统的极大开销，以每日1000万PV为例，假设这是每个请求都需要调用的服务，每新增一个字节，就意味着会新增10MB的流量。第二，千万不要直接使用自己企业内部IT原来部署的服务。这是因为企业内部原有的SOA服务不是为互联网峰值系统所设计的。我们曾经有一个客户，在电商网站上使用了企业内部IT提供的客户验证服务，看上去只是一个简单查询，结果甫一上线，直接导致该服务崩溃，进而引发整个内部IT SOA体系的下线，对内部系统造成的影响用了好几天才得以消除，更不用说对线上系统的影响了，严重伤害了企业的形象。第三，幂等原则。假设所有的服务调用都是不可靠的，所以重试是常态，因此对于重复的API写入操作应进行判重处理。
前台交易系统的数据库架构
对于一个典型的前台交易系统而言，对数据库的读写比例差距很大，读操作远大于写操作，此时除了通过前面提到的缓存及搜索方面的优化以外，一般还会对数据库的架构进行优化。
以MySQL为例，可以采用主从读写分离的方式进行调优。也就是，部署一主多从的MySQL实例，应用层写操作只发生在主实例上，读操作只发生在从实例上，此时通过调整从实例的数量，可以很大程度地缓解对数据库的查询压力。
在使用主从读写分离的MySQL架构中，比较常见的是在峰值时出现写入操作拥堵，其后果可能是系统不响应或主从复制延迟。主从复制延迟在前台很难立即发现，直到有用户发现注册或下单问题时，通过排查才能发现。所以对一个主从读写分离系统，必须做好主从复制延迟的监控。
如果出现了复制延迟等性能问题，我们就应该着力分析瓶颈到底在哪里。除了对配置参数和硬件进行调优以外，一般在架构上存在几种处理方法。第一，水*切分，常见的情况是对订单归档，对于一个电商系统而言，商品和用户是核心，订单数据从某种意义上来说只是日志而已，当然也有一些系统层面的水*切分方案。第二，热点隔离，如在秒杀情况下，很可能只有一到两个商品参与，我们完全可以将对相关商品的库存写入等操作与其他商品隔离开来。当然这在应用层上要做的工作比较多。第三，异步写入。对于事务要求不严格的写入，如一些日志的写入，可以采用先写入队列，然后再以一定速率写入数据库的方法降解压力。第四，报表等只读类应用可以独立调用一个专用的从库。
服务降级
在设计峰值系统时必须考虑当系统压力剧增时，需要根据业务与流量情况，对某些服务或页面进行有策略的降级，以释放服务器资源保证核心业务的运行。服务降级一般有业务层降级和系统层降级两种。
业务层降级，指的是对除核心主流程以外的功能，根据系统压力情况进行有策略的关闭，从而达成服务降级的目的。例如，停止某些运算复杂的促销配置、关闭某些页面的访问或写入操作等。一般对于前台交易系统来说，业务层降级点的优先级排序是根据对转化率的影响进行的。而对于后台作业系统，以商派的ERP为例，在峰值时会采用关闭数据条数显示、实时报表查询等非主业务流程的模块或功能，全力保障订单处理作业的顺利运转。
系统层降级，指的是通过对操作系统、Web服务器、数据库等系统架构层面的配置进行调整，从而达成服务降级的目的。一般的方法有访问限流、写入限制、异步延迟持久化等。总体来说，系统层降级对用户体验的影响会比业务层降级大很多，但在执行上比较简单，实现成本较低。注意，服务降级方案可能会在不同程度上影响用户体验、交易系统的转化率及业务处理流程，因此，开发运维方需要事先与业务方或客户方做好充分的沟通并经审核同意后，再进行控制点的埋点与开发，同时还应写入峰值情况应对预案。
监控与运维
一个成功运行的电子商务峰值系统，三分靠研发，七分靠运维。而一个完善的监控系统则是运维的眼睛。通过监控到的指标变化，运维人员可以对系统资源进行人工或自动化调整，可以产生告警通知进行故障处理，也可以及时作出服务降级决策。常见的监控系统分为三类：系统性能监控、用户体验监控和业务实时监控。
系统性能监控，主要是对下列指标进行监控：服务器指标，如CPU、内存、磁盘等；数据库指标，如QPS、主从复制延时、进程、慢查询等。另外，根据采用的架构不同，还有消息队列堆积监控等。通过对这一系列系统指标进行监控，可以发现运行健康状态出现问题的服务与服务器，同时也可以评估系统的繁忙程度，以供及时处理。对于服务器指标监控，一般可以选用Nagios、Cacti进行，数据库监控可以使用相关数据库提供的监控工具或自行结合Nagios和Cacti进行少量的二次开发。
用户体验监控，主要是对业务关键流程进行监控，如对页面访问、用户登录流程、下单流程等流程的可用性进行监控，监控可以由Last mile最终客户模拟或由各地IDC机房部署的测试脚本发起。用户体验监控对于及时发现一些从系统监控层上无法发现的问题或尚未列入监控的指标异常具有重大意义，如系统Bug、之前提到的主动同步延迟等。可以结合当前使用的监控工具进行一定程度的二次开发，市场上也有一些第三方提供的云服务可供选择。
业务实时监控，主要是指对业务数据进行监控，如PV、UV、转化率、下单量、支付量、发货量和仓内作业效率数据，在给业务提供相关决策的同时，也可以用于辅助判断系统问题。业务实时监控一般分为入侵型与非入侵型两种。入侵型需要在程序的各个流程节点上进行埋点，相关动作被触发后，通过消息队列推送给监控界面进行展示；非入侵型一般通过分析网络流量，匹配出相应的请求进行内容分析，从而判断出相关目标事件的发生并进行统计与展示监控界面。入侵型监控系统一般需要进行定制开发，但实现逻辑简单，技术难度较高；非入侵型监控系统开发难度较高，但部署配置简单，同时由于无需在目标系统上进行二次开发，对目标系统不会产生任何压力。
除了以上所讨论的常见问题，在设计一个电商峰值系统的过程中，还有很多问题需要解决，如缓存的更新机制、可靠的消息队列设计、自动化运维体系的建设等。但最关键的是要求我们电商系统架构师同时在技术和业务上达到精通的程度，才能设计出一个性能优良、成本合理的电商峰值系统。
作者徐唤春，上海商派软件有限公司技术副总裁。有20余年的软件行业经验，初期从事专家系统、无线寻呼系统、电力行业系统的研究，并承担多个重大项目的设计与研发工作。
文章来源：http://www.csdn.net/article/2014-11-11/2822574
摘要：当当网各种大中小型促销活动常年不断，且活动的业务模式不尽相同，因此要求系统具备很强的伸缩性。本文结合当当网多年实战经验，讲述如何制定的系统伸缩性的设计原则和硬件常备策略，来应对各场景下的流量暴涨。
当当网自成立以来，内部技术体系的发展已经有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年起加入电商行业，有多年实际研发与架构设计经验。
史海峰，当当网架构师，负责电商*台架构设计、技术规范制定和技术预研推广，参与重点项目的方案设计。
摘要：高流量、高并发情况下，如何保证整个系统的可靠性和稳定性，是众多电商企业研发团队都在思考的问题。为了尽量缓解峰值带来的压力，京东峰值系统的设计主要从性能提升、流量控制、灾备降级、压测预案四个角度来进行。
有别于社交网络、搜索和游戏等网站，电商网站的用户流量具有操作性强、随时令变化等特点。在欧美国家，Black Friday和Cyber Monday标志着节假日消费的高峰。影响电商流量峰值的主要因素是抢购、促销和恶意攻击，尤其是京东618店庆和双11等大规模的促销活动。高流量、高并发情况下，如何保证整个系统的可靠性和稳定性，是众多电商企业研发团队都在思考的问题。
京东电商系统的设计是围绕系统稳定性、可靠性、高并发和可扩展性为核心开展的。如何在峰值来临时，保证用户有*滑流畅的体验，且系统不会出现异常呢？我们先来看看京东系统的一些特点（图1）。
图1 系统架构庞大复杂
京东的业务种类繁多，涉及SKU几千万种，这使得系统庞大，外部需要对接供应商、消费者和第三方商家三大板块。内部系统包括了商品供应链中除商品设计和生产外的几乎所有环节，包括登录、交易、后台、供应链、仓配、客服等。所有这些涉及大小系统几千个，造就了一个极其复杂庞大的体系。除此之外，京东系统交互强，各个功能模块之间关联性强，牵一发而动全身，做任何修改都需要慎之又慎。因此，一切优化方案都以保持系统稳定为前提。
为了在复杂的系统基础之上，尽量缓解峰值带来的压力，京东峰值系统的设计主要从性能提升、流量控制、灾备降级、压测预案四个角度来进行。
性能提升
切分业务系统
我们先将整个业务体系拆分为几个相对独立的子系统如SSO、交易*台、POP*台、订单下传系统、WMS和仓储配送（图2）。每个子系统又可细分为若干部分，逐级简化，直至可操作可优化的层级。例如，交易*台包括价格、购物车、结算、支付和订单中心等；网站系统包括首页、登录、列表频道、单品和搜索等。接下来，针对每个功能模块的关键部分进行切分，有针对性地做性能优化。
图2 业务切分方案
例如，交易的秒杀系统，原来是根植于普通交易系统之内的，缺点非常明显。当流量突然增大时，不仅会导致秒杀系统反应迟钝，而且会影响普通交易系统的正常运作。于是我们将其与其他业务系统物理分开，成为相对独立的子系统。并且针对秒杀的特性，减少对后台存储的依赖。同时优化中间层存储机制，使得相对热点分散部署。甚至支持单一SKU多点部署，从而大大提升了秒杀系统的吞吐量和可靠性。
分布式
分布式的交易系统是电商的未来。分布式系统解决两大难题：提高用户体验和增强容错能力。由于分布式系统设计时就会留有相当的流量增长空间，所以当一处数据中心饱和时，可以将其余的流量切入其他相对宽松的数据中心去，从而达到互为备份、互相支持的目的。与此同时，由于为提供用户就*服务，所以减少了网络延时，页面反应速度加快了。举一个例子，Google搜索是全球服务，欧亚美各地都有不同的IP提供服务。当其中的某一个IP出现故障时，Google能够从容地将其服务切换至最*的IP，继续搜索服务。对于电商来说，情况更复杂一些，需要同步的数据要求更精确，数据量较大，对延时的容忍度更低，建设周期也就更长。京东正在此方面着力改进，从只读的系统入手，一步一步实现系统的分布式。
API服务化
在各个系统中，总是有很多相同的组件。前端的负载均衡自不必说，中间件的处理就是非常典型的例子。如何高效统一地管理这些组件，API服务化是我们的答案。最好由一个训练有素的团队集中管理这些组件并对外提供接口服务，将软件的使用复杂性隐藏起来，调用的是简单利索的API。让专业人员去处理复杂逻辑，确保系统的可用性和扩展性，既能大大降低出错概率，又能实现规模效益。
Redis是我们常用的缓存组件。过去都是由各个业务实现团队进行分别维护，专业性不强，使用多有不当之处。后来我们进行了集中管理，统一定制开发新功能和升级，并通过API服务化提供给各级用户。这样不仅丰富了应用场景，还提升了性能和可靠性。
架构，代码优化
一个合理的电商系统架构是与一家公司的研发水*和技术管理水*密不可分的，这直接决定了可支撑峰值流量的多少和未来能达到的高度。选取适合自身发展的框架，既能充分发挥其效能，又可节约资源。代码优化也能提高效能，例如对于SQL语句的优化，能更好地利用索引；Java/C++逻辑的优化，减少了不必要的循环和复杂的操作；算法优化，使之更高效；功能实现逻辑的优化，变得更简洁和清晰；等等。但代码优化终究不能冲破极限，难以追求极致，适可为止为宜。
系统虚拟弹性化
当磁盘I/O不是瓶颈时，解决系统水*扩展就会变得容易许多。可以通过ZooKeeper或类ZooKeeper将软件栈有机地串联起来，并配以有效的性能监管。当事务处理成为瓶颈时，利用当今流行的虚拟化技术（如LXC或VM）可以在没有人为干预的状况下自动进行弹性扩展。
摘要：今年4月的“米粉节”对小米网来说意义非凡，是其彻底重构后迎来的一次全面压力测试，涉及网站前端、后台系统、仓储物流、售后等各环节。高并发的负载能力、稳定性、准确性等已不是问题，灵活性与可运营性成为关键。
2014年的米粉节
2014年4月9日凌晨，我和同事们对小米网的抢购系统做了最后的检查与演练。几个小时后，小米网今年开年来最重要的一次大型活动“米粉节”就要开始了。
这次米粉节活动，是小米电商的成人礼，是一次重要的考试。小米网从网站前端、后台系统、仓储物流、售后等各个环节，都将接受一次全面的压力测试。
10点整，一波流量高峰即将到来，几百万用户将准点挤入小米网的服务器。而首先迎接压力冲击的，就是挡在最前面的抢购系统。
而这个抢购系统是重新开发、刚刚上线不久的，这是它第一次接受这样严峻的考验。
系统能不能顶住压力？能不能顺畅正确地执行业务逻辑？这些问题不到抢购高峰那一刻，谁都不能百分百确定。
9点50分，流量已经爬升得很高了；10点整，抢购系统自动开启，购物车中已经顺利加入了抢购商品。
一两分钟后，热门的抢购商品已经售罄自动停止抢购。抢购系统抗住了压力。
我长舒一口气，之前积累的压力都消散了。我坐到角落的沙发里，默默回想抢购系统所经历的那些惊心动魄的故事。这可真是一场很少人有机会经历的探险呢。
抢购系统是怎样诞生的
时间回到2011年底。小米公司在这一年8月16日首次发布了手机，立刻引起了市场轰动。随后，在一天多的时间内预约了30万台。之后的几个月，这30万台小米手机通过排号的方式依次发货，到当年年底全部发完。
然后便是开放购买。最初的开放购买直接在小米的商城系统上进行，但我们那时候完全低估了“抢购”的威力。瞬间爆发的*常几十倍流量迅速淹没了小米网商城服务器，数据库死锁、网页刷新超时，用户购买体验非常差。
市场需求不等人，一周后又要进行下一轮开放抢购。一场风暴就等在前方，而我们只有一周的时间了，整个开发部都承担着巨大的压力。
小米网可以采用的常规优化手段并不太多，增加带宽、服务器、寻找代码中的瓶颈点优化代码。但是，小米公司只是一家刚刚成立一年多的小公司，没有那么多的服务器和带宽。而且，如果代码中有瓶颈点，即使能增加一两倍的服务器和带宽，也一样会被瞬间爆发的几十倍负载所冲垮。而要优化商城的代码，时间上已没有可能。电商网站很复杂，说不定某个不起眼的次要功能，在高负载情况下就会成为瓶颈点拖垮整个网站。
这时开发组面临一个选择，是继续在现有商城上优化，还是单独搞一套抢购系统？我们决定冒险一试，我和几个同事一起突击开发一套独立的抢购系统，希望能够绝境逢生。
摆在我们面前的是一道似乎无解的难题，它要达到的目标如下：
· 只有一周时间，一周内完成设计、开发、测试、上线；
· 失败的代价无法承受，系统必须顺畅运行；
· 抢购结果必须可靠；
· 面对海量用户的并发抢购，商品不能卖超；
· 一个用户只能抢一台手机；
· 用户体验尽量好些。
设计方案就是多个限制条件下求得的解。时间、可靠性、成本，这是我们面临的限制条件。要在那么短的时间内解决难题，必须选择最简单可靠的技术，必须是经过足够验证的技术，解决方案必须是最简单的。
在高并发情况下，影响系统性能的一个关键因素是：数据的一致性要求。在前面所列的目标中，有两项是关于数据一致性的：商品剩余数量、用户是否已经抢购成功。如果要保证严格的数据一致性，那么在集群中需要一个中心服务器来存储和操作这个值。这会造成性能的单点瓶颈。
在分布式系统设计中，有一个CAP原理。“一致性、可用性、分区容忍性”三个要素最多只能同时实现两点，不可能三者兼顾。我们要面对极端的爆发流量负载，分区容忍性和可用性会非常重要，因此决定牺牲数据的强一致性要求。
做出这个重要的决定后，剩下的设计决定就自然而然地产生了：
1. 技术上要选择最可靠的，因为团队用PHP的居多，所以系统使用PHP开发；
2. 抢资格过程要最简化，用户只需点一个抢购按钮，返回结果表示抢购成功或者已经售罄；
3. 对抢购请求的处理尽量简化，将I/O操作控制到最少，减少每个请求的时间；
4. 尽量去除性能单点，将压力分散，整体性能可以线性扩展；
5. 放弃数据强一致性要求，通过异步的方式处理数据。
最后的系统原理见后面的第一版抢购系统原理图（图1）。
图1 第一版抢购系统原理图
系统基本原理：在PHP服务器上，通过一个文件来表示商品是否售罄。如果文件存在即表示已经售罄。PHP程序接收用户抢购请求后，查看用户是否预约以及是否抢购过，然后检查售罄标志文件是否存在。对预约用户，如果未售罄并且用户未抢购成功过，即返回抢购成功的结果，并记录一条日志。日志通过异步的方式传输到中心控制节点，完成记数等操作。
最后，抢购成功用户的列表异步导入商场系统，抢购成功的用户在接下来的几个小时内下单即可。这样，流量高峰完全被抢购系统挡住，商城系统不需要面对高流量。
在这个分布式系统的设计中，对持久化数据的处理是影响性能的重要因素。我们没有选择传统关系型数据库，而是选用了Redis服务器。选用Redis基于下面几个理由。
1. 首先需要保存的数据是典型的Key/Value对形式，每个UID对应一个字符串数据。传统数据库的复杂功能用不上，用KV库正合适。
2. Redis的数据是in-memory的，可以极大提高查询效率。
3. Redis具有足够用的主从复制机制，以及灵活设定的持久化操作配置。这两点正好是我们需要的。
在整个系统中，最频繁的I/O操作，就是PHP对Redis的读写操作。如果处理不好，Redis服务器将成为系统的性能瓶颈。
系统中对Redis的操作包含三种类型的操作：查询是否有预约、是否抢购成功、写入抢购成功状态。为了提升整体的处理能力，可采用读写分离方式。
所有的读操作通过从库完成，所有的写操作只通过控制端一个进程写入主库。
在PHP对Redis服务器的读操作中，需要注意的是连接数的影响。如果PHP是通过短连接访问Redis服务器的，则在高峰时有可能堵塞Redis服务器，造成雪崩效应。这一问题可以通过增加Redis从库的数量来解决。
而对于Redis的写操作，在我们的系统中并没有压力。因为系统是通过异步方式，收集PHP产生的日志，由一个管理端的进程来顺序写入Redis主库。
另一个需要注意的点是Redis的持久化配置。用户的预约信息全部存储在Redis的进程内存中，它向磁盘保存一次，就会造成一次等待。严重的话会导致抢购高峰时系统前端无法响应。因此要尽量避免持久化操作。我们的做法是，所有用于读取的从库完全关闭持久化，一个用于备份的从库打开持久化配置。同时使用日志作为应急恢复的保险措施。
整个系统使用了大约30台服务器，其中包括20台PHP服务器，以及10台Redis服务器。在接下来的抢购中，它顺利地抗住了压力。回想起当时的场景，真是非常的惊心动魄。
第二版抢购系统
经过了两年多的发展，小米网已经越来越成熟。公司准备在2014年4月举办一次盛大的“米粉节”活动。这次持续一整天的购物狂欢节是小米网电商的一次成人礼。商城前端、库存、物流、售后等环节都将经历一次考验。
对于抢购系统来说，最大的不同就是一天要经历多轮抢购冲击，而且有多种不同商品参与抢购。我们之前的抢购系统，是按照一周一次抢购来设计及优化的，根本无法支撑米粉节复杂的活动。而且经过一年多的修修补补，第一版抢购系统积累了很多的问题，正好趁此机会对它进行彻底重构。
第二版系统主要关注系统的灵活性与可运营性（图2）。对于高并发的负载能力，稳定性、准确性这些要求，已经是基础性的最低要求了。我希望将这个系统做得可灵活配置，支持各种商品各种条件组合，并且为将来的扩展打下良好的基础。
图2 第二版系统总体结构图
在这一版中，抢购系统与商城系统依然隔离，两个系统之间通过约定的数据结构交互，信息传递精简。通过抢购系统确定一个用户抢得购买资格后，用户自动在商城系统中将商品加入购物车。
在之前第一版抢购系统中，我们后来使用Go语言开发了部分模块，积累了一定的经验。因此第二版系统的核心部分，我们决定使用Go语言进行开发。
我们可以让Go程序常驻内存运行，各种配置以及状态信息都可以保存在内存中，减少I/O操作开销。对于商品数量信息，可以在进程内进行操作。不同商品可以分别保存到不同的服务器的Go进程中，以此来分散压力，提升处理速度。
系统服务端主要分为两层架构，即HTTP服务层和业务处理层。HTTP服务层用于维持用户的访问请求，业务处理层则用于进行具体的逻辑判断。两层之间的数据交互通过消息队列来实现。
HTTP服务层主要功能如下：
1. 进行基本的URL正确性校验；
2. 对恶意访问的用户进行过滤，拦截黄牛；
3. 提供用户验证码；
4. 将正常访问用户数据放入相应商品队列中；
5. 等待业务处理层返回的处理结果。
业务处理层主要功能如下：
1. 接收商品队列中的数据；
2. 对用户请求进行处理；
3. 将请求结果放入相应的返回队列中。
用户的抢购请求通过消息队列，依次进入业务处理层的Go进程里，然后顺序地处理请求，将抢购结果返回给前面的HTTP服务层。
商品剩余数量等信息，根据商品编号分别保存在业务层特定的服务器进程中。我们选择保证商品数据的一致性，放弃了数据的分区容忍性。
这两个模块用于抢购过程中的请求处理，系统中还有相应的策略控制模块，以及防刷和系统管理模块等（图3）。
图3 第二版系统详细结构图
在第二版抢购系统的开发过程中，我们遇到了HTTP层Go程序内存消耗过多的问题。
由于HTTP层主要用于维持住用户的访问请求，每个请求中的数据都会占用一定的内存空间，当大量的用户进行访问时就会导致内存使用量不断上涨。当内存占用量达到一定程度（50%）时，Go中的GC机制会越来越慢，但仍然会有大量的用户进行访问，导致出现“雪崩”效应，内存不断上涨，最终机器内存的使用率会达到90%以上甚至99%，导致服务不可用。
在Go语言原生的HTTP包中会为每个请求分配8KB的内存，用于读缓存和写缓存。而在我们的服务场景中只有GET请求，服务需要的信息都包含在HTTP Header中，并没有Body，实际上不需要如此大的内存进行存储。
为了避免读写缓存的频繁申请和销毁，HTTP包建立了一个缓存池，但其长度只有4，因此在大量连接创建时，会大量申请内存，创建新对象。而当大量连接释放时，又会导致很多对象内存无法回收到缓存池，增加了GC的压力。
HTTP协议是构建在TCP协议之上的，Go的原生HTTP模块中是没有提供直接的接口关闭底层TCP连接的，而HTTP 1.1中对连接状态默认使用keep-alive方式。这样，在客户端多次请求服务端时，可以复用一个TCP连接，避免频繁建立和断开连接，导致服务端一直等待读取下一个请求而不释放连接。但同样在我们的服务场景中不存在TCP连接复用的需求。当一个用户完成一个请求后，希望能够尽快关闭连接。keep-alive方式导致已完成处理的用户连接不能尽快关闭，连接无法释放，导致连接数不断增加，对服务端的内存和带宽都有影响。
通过上面的分析，我们的解决办法如下。
1. 在无法优化Go语言中GC机制时，要避免“雪崩效应”就要尽量避免服务占用的内存超过限制（50%），在处于这个限制内时，GC可以有效进行。可通过增加服务器的方式来分散内存压力，并尽力优化服务占用的内存大小。同时Go 1.3也对其GC做了一定优化。
2. 我们为抢购这个特定服务场景定制了新的HTTP包，将TCP连接读缓存大小改为1KB。
3. 在定制的HTTP包中，将缓存池的大小改为100万，避免读写缓存的频繁申请和销毁。
4. 当每个请求处理完成后，通过设置Response的Header中Connection为close来主动关闭连接。
通过这样的改进，我们的HTTP前端服务器最大稳定连接数可以超过一百万。
第二版抢购系统顺利完成了米粉节的考验。
总结
技术方案需要依托具体的问题而存在。脱离了应用场景，无论多么酷炫的技术都失去了价值。抢购系统面临的现实问题复杂多变，我们也依然在不断地摸索改进
摘要：本文重点介绍了海尔电商*台的架构方案，也用不少篇幅阐述面临的场景和挑战，以及在架构方案决策过程中的关注点。其实作为一个优秀的电商*台，提供极致的用户体验、让技术最大化地创造价值，才是架构的终极目标。
多数电商*台都会经历相似的过程，流量和业绩每年以几倍至十几倍的速度增长，每年都要接受几次大规模、全方位的系统检阅，例如双11、周年庆等购物狂欢节，期间流量和订单可能是日常的十几倍甚至几十倍，产生的峰值对*台形成极其强烈的冲击，对电商*台的架构带来巨大的考验。因此，对电商*台的规划和架构工作不仅要高瞻远瞩，而且要细致入微，否则将导致*台无法满足高速增长的业务发展，细微处的失误也可能造成严重后果，不仅影响业务指标的实现，还可能导致对系统进行重新架构，劳时费力又伤钱。
从2012年开始，海尔进入了网络化发展阶段，企业*台化、用户个性化和员工创客化的“三化”做法为电商的蓬勃发展提供了很好的土壤，也是海尔在面对互联网转型时的一个重点。海尔电商*台在发展过程中也同样经历了上述的问题。下面就抛砖引玉，为大家分享海尔电商*台应对电商峰值的架构设计经验。
站在巨人肩膀上的SOA架构
随着电商业务开展和业绩增长，系统结构和逻辑变得越来越复杂。为应对业务规模和复杂性的增长，需要将系统按照细分专业领域拆分；为应对流量和交易的增长，需要将网站进行大量子站拆分。这种状况下，SOA在保持清晰的系统结构和良好的逻辑组织方面提供了有力保障，为业务优化调整及新业务的开展带来巨大收益。
通过服务封装和严格分离，为电商*台实现高伸缩性打下坚实基础。实现高伸缩性的主要工作集中在服务内部，对客户端影响的评估和改造工作也变得非常清晰。这将大大降低了实现高伸缩性的难度、工作量和实施周期。
Dubbo是阿里提供的一个优秀的开源服务框架，在高并发情况下具有优秀的性能表现，海尔电商的SOA架构全面基于Dubbo服务框架。关于Dubbo框架的详细介绍可以参考GitHub上的Dubbo项目文档。下面对Dubbo框架工作机制进行简单介绍。
如图1所示，每个服务提供者启动时都会注册到注册中心，并且通过长连接与注册中心保持心跳检测。这样注册中心就拥有一份完整、可用的服务提供者清单，某个服务提供者下线或由于故障中断，注册中心都能感知到并从清单中删除这个提供者。消费者启动时从注册中心获得服务提供者清单，并与提供者建立长连接，后续直接调用服务提供者，不再经过注册中心，避免注册中心成为瓶颈。每个消费者同样与注册中心保持长连接，这样有新的提供者注册或者某个提供者下线，都由注册中心通知到每个消费者。消费者在调用服务提供者时支持各种负载均衡和故障容错策略。监控中心则负责运行状态统计，例如每分钟的调用次数和*均耗时等。
图1 Dubbo服务部署架构示意图
Dubbo框架不仅实现了高性能、高可用性，而且使用方便，扩展性非常好。海尔电商所有服务都基于Dubbo框架开发，图2是系统整体SOA架构情况。
图2 海尔电商SOA架构示意图
鱼与熊掌兼得的产品服务架构
面临的挑战
产品的检索和展示在电商*台中具有举足轻重的地位，贯穿用户浏览、购物整个过程，以及订单交付全流程。产品服务需要为整个*台提供数据请求和检索服务，而各品类的产品差异性非常大，这给产品服务设计带来了巨大的挑战。
· 负载权重高。电商*台中几乎每一个前台页面都与产品展示和检索相关，产品服务的负载在整个*台中占比非常高，对产品服务的请求量可能达到整站流量的几倍、几十倍。在电商活动高峰期间，核心系统中首当其冲的便是产品服务。因此，产品服务的设计必须满足高可用性，并且实现良好的性能和高伸缩性。
· 产品差异性大。不同品类的产品具有不同维度的属性和规格参数，产品结构的设计必须具备足够的通用性和灵活性，才能良好地满足电商*台多品类运营的要求，以及在*台、品类扩展时可以提供快速的响应支持。
· 全方位检索、排序。让用户方便快捷地在大量产品中找到自己满意的产品，是电商*台用户体验和信息架构中非常关键的一点。除了关键词搜索、按类目检索浏览之外，还需要提供按常用属性进行检索。在深入优化用户体验时，可能会提出更复杂的检索处理逻辑，例如组合属性检索，自动根据检索结果反过滤掉无结果的类目和属性，展示符合各个属性条件的商品个数，以及实时地结合大数据分析结果添加更多自动化、智能化的策略等。
将页面或者部分页面的静态化是一种非常有效的优化方式，可以极大地降低对后台服务和数据的请求。但静态化带来的最大弊端就是服务端丧失了控制力，使得一些深入的自动化、智能化策略难以应用。因此，我们希望通过提升服务端的性能和伸缩性，来避免静态化的方案。
性能和伸缩性是电商*台的关键指标。为了保障系统性能和伸缩性，不少时候我们需要牺牲或者完全拒绝某些功能，或者降低系统的灵活性和扩展性等。在产品服务架构设计阶段，我们努力思考和研究着一种可以鱼和熊掌兼得的解决方案。
解决方案
如图3所示，在数据库层允许复杂的产品存储结构设计，以细粒度、深度优化的关系模型充分实现产品数据模型的通用性、可扩展性。在数据模型设计时完全不用关心客户端检索查找的复杂性和性能问题。
图3 产品服务逻辑架构示意图
产品查询引擎将复杂的数据存储模型封装成一个简单的逻辑模型。这个逻辑模型实现的效果，完全等同于产品的所有属性都存储在同一张数据库表中，逻辑模型的每个属性对应数据库表中的一个字段。在这个逻辑模型的基础上实现了一个简洁的DSL，供客户端进行检索查询。客户端工作在逻辑模型和DSL之上，检索查询简单、灵活，同样完全不用关心产品数据存储模型的复杂性和性能问题。
产品查询语言DSL
产品查询语言DSL的语法类似SQL中的where条件语法，任何一个开发人员都很容易掌握。客户端将DSL表达式传给服务端，即可得到满足条件的产品列表及相关属性数据（图4）。
图4 查询语言DSL工作原理
DSL还支持中文语法，更方便使用，尤其对于业务人员进行复杂的后台检索查询，或者为前台页面及栏位设置产品展示的过滤条件等情况。
产品查询引擎
图5描述了查询引擎的核心组件及关键的执行流、数据流。编译器基于Antlr开发，职责是将DSL表达式编译为语法树，并完成一系列编译优化操作。执行引擎使用语法树逐个对产品进行匹配，得到符合条件的产品列表。智能排序引擎基于产品综合竞争力评估模型，为结果集进行排序，实现最大化提升转换率的目的。结果构造器则根据客户端在调用服务时指定的要求，将客户端所需属性加载到结果集中。
图5 查询引擎工作机制
在服务启动时将产品数据缓存到内存中，通过订阅MQ消息队列，在数据发生变化时刷新有变化的数据。
产品服务架构
产品服务分不同集群进行部署，面向Web应用和其他服务的集群在运行期间几乎不会产生数据库请求，因此不管网站访问量和交易量多高，数据库都不会产生压力瓶颈。在系统峰值期间，只需为Web和服务添加服务器即可，实现了高伸缩目标。
效果
· 性能：最高峰值2.6亿次/天，*均耗时60毫秒/次，后续对编译器和执行引擎进行优化，性能还有更大的提升空间。
· 伸缩性：在一定条件下接*线性伸缩，所有使用产品服务的地方无须出于性能和系统压力原因额外设计其他方案，直接调用产品服务即可。
· 通用性：不会因为电商*台性能和伸缩性要求而受到任何限制，可以像开发内部管理系统PDM一样设计产品数据模型，并且直接用于其他在线服务和前台Web应用，尽可能达到通用灵活的目的。
· 扩展性：通过逻辑模型屏蔽了底层的数据模型，将数据模型的优化、扩展工作量以及影响范围降低到最小限度，提升了电商*台中产品服务的可维护性和扩展性。
以查询引擎为核心的产品服务是一个鱼与熊掌兼得的架构设计案例，通用性、扩展性、伸缩性等在电商*台中相互制约、矛盾的一组核心架构目标全部得到满足。
摘要：在唯品会，用户来得越早，越能买到又便宜又好的东西，所以在大促一开始会涌入大量用户，形成系统流量峰值。本文总结了唯品会419时日志*台遇到的问题和解决方案，同时根据实践经验，整理了在面对峰值前要做的准备。
唯品会每年最大力度的促销活动在4月19日，就是419（For One Night），意在告诉唯品会用户只有这一晚有这么大的折扣力度（本文中用“大促”就指代419）。唯品会是一个闪购网站，用户来得越早，越能买到又便宜又好的东西，所以在大促的一开始，会涌入大量用户，形成系统流量峰值。
本文总结了唯品会419时日志*台遇到的问题和解决方案，同时根据实践经验，整理了在面对峰值前要做的准备。
2013年419
唯品会的日志*台，包括消息中间件、计算和数据可视化。前两者和峰值系统相关度更大一些。在2013年419时，我们使用Flume来收集日志，RabbitMQ作为传输日志的消息中间件，用Storm和Redis进行计算，然后通过脚本将Redis的数据写入MySQL，前端从MySQL中获取数据做数据可视化。架构如图1所示。
图1 2013年日志*台架构
在这次419之前，我们对这个系统并不是很有信心。一个原因是刚开始做这块内容，很多工具都不够成熟。另一个原因是在大促之前，我们还在开发新功能，既没有稳定运行一段时间，也没有做容量规划之类的事情。
最后的结果确实如此，4月19日0点，大量用户进入唯品会购物，系统计算开始出现延迟，最初是1分钟，后面逐渐扩大到10分钟，最后由于雪崩效应，整个集群垮了。在分布式系统中，“雪崩效应”指的是系统中一个小问题会逐渐扩大，最后造成整个集群宕机。前面这个例子，一开始的计算延迟是1分钟，这在可以接受的范围内，但因为这个延迟，系统需要付出更多的代价去计算，如此恶性循环，数据延迟会越来越大，最后导致整个集群宕机。
在大促之后，我们进行了全面分析，发现这个系统的瓶颈在于RabbitMQ和Storm。
作为整个*台输送数据的管道，RabbitMQ的性能直接决定了后端消费数据系统的消费能力。整个*台就像是大炮，大炮发射再快，输送炮弹的速度跟不上都没用。这次大促中，RabbitMQ的性能出了问题。我们需要处理的日志量是每秒15万条左右，而我们使用RabbitMQ的环境下，每一台RabbitMQ服务器大约能达1.2万条日志每秒，由4台机器组成RabbitMQ集群，所以当流量暴涨时，RabbitMQ服务器负载会变得很高，而produce/consume速度变慢。在当时的情况下，我们并不能判断这个Queue的堵塞是由于下游的Storm消费得慢，还是RabbitMQ本身慢造成。
再看Storm。在分析Storm出问题的原因之前，先先介绍一下使用Storm计算的内容：一是根据用户访问日志计算PV/UV；二是根据Nginx日志计算各个域的访问量、响应时间和4xx/5xx数。由于Storm在各个计算节点之间无法共享数据（不像Spark有broadcast），我们只能借助Redis来做一个类似MapReduce中的Reduce功能。为了让大家能深入了解，下面详细介绍一下如何使用Storm计算这些数据。
PV
在Redis中有不同的key，如b2c_pv和mobile_pv，对Storm中得到的每条日志进行逻辑判断决定是b2c还是mobile访问，再使用Redis的incr操作（incr[key]，表示将key对应的value加1，如果key不存在，则在这个操作前，会先置为0）。
UV
我们计算的是每5分钟的UV，方法很简单。在Redis中有一个DB专门用来计算UV，Storm将每个用户的cid（标识用户唯一身份的id）incr到DB中，这样能保证一个cid对应一个key。最后汇总通过Redis的“keys *”来获取DB中key的数目，这样就获取到了cid的数目。又因为我们计算的是5分钟的UV，所以还需要一个crontab，每5分钟将DB中的内容truncate掉。
计算Nginx日志
实际上，计算Nginx日志非常简单，就是分割和计算。将一条Nginx日志分割后，就能知道这次访问的状态码是什么，响应时间是多少。然后DB中会有不同的key，如domain是cart，那么cart域的响应时间在Redis DB里的key就是cart_resp_time，访问量就是cart_count，2xx数量就是cart_2xx_count。根据从日志获取的值，我们会使用Redis的incrby来操作（incrby和incr类似，incr是value加1，incrby可以指定增加的数字）。然后在计算metrics时，脚本先获取当前的cart_count，然后sleep 1秒，再获取一次cart_count，这两个的差值是这1秒钟内cart域的访问量。同样的方法，可以获取这1秒的响应时间，与访问量相除，就可以计算出这1秒的*均响应时间。
介绍完计算逻辑，可以了解到，Storm的处理逻辑非常简单，主要工作就是“分割日志”和“操作Redis计数”。
为了判断到底是RabbitMQ慢还是Storm慢，我们先将Storm停了，然后用一个Python脚本向Queue发送数据和消费Queue里的数据，这样来减小Producer和Consumer性能对RabbitMQ的性能影响。这样测试后发现，每台RabbitMQ的吞吐大概是1w条数据每秒，而且负载很高。后来，我们使用Erlang的HiPE特性（即High Performance Erlang），将性能提升20%，大概达到1.2w条数据每秒。但仍然不能满足我们的要求。我们要求达到15w msg/s，加上25%的冗余，此时需要15×(1+25%)/1.2≈16台服务器，比较多。再考虑到唯品会正处于快速增长期，目前是15w msg/s，很有可能明年就翻几番。使用RabbitMQ似乎不太符合我们的需求，因为在可预见的将来，需要大量服务器来支撑。此外，RabbitMQ对服务器的CPU消耗非常大。
RabbitMQ的消费者除了Storm外，还有Elastic-Search（ES）。使用ES来做日志的全文检索，包括Nginx日志和PHP错误日志，因为Nginx日志的计算只能帮助运维人员和开发人员定位到某个域出问题，再深入地分析，就要从出错时的日志入手了。我们的日志还会有一份全量流入HDFS，原本用日志的搜索直接从HDFS来获取，但发现用Hive查询速度非常慢，大约需要几分钟。ES是基于Solr的一个全文检索引擎，有一个很好用的前端Kibana。在这次大促中，由于前端的RabbitMQ挂了，所以ES没有受到很大的压力。
摘要：1号店结合自己的业务需求，在力求降低成本的前提下，最终采纳Storm计算框架来实现自己的分布式流计算*台。本文中详细阐释了这一过程中的最佳技术实践。
京东618、 1号店711，还有全民购物狂欢节双11，电商促销的浪潮此起彼伏。然而，在买家和卖家欢呼雀跃的同时，电商*台正在经历着非常严峻的考验。面对一天之内犹如洪水般的网购流量，哪怕出现几分钟的闪失，都可能造成众多笔订单的损失，以及无法挽回的销售收入。时间就是金钱，在这一刻体现得淋漓尽致。如何设计电商峰值系统来更好地满足客户需求，如何在海量数据处理中实时发现有效信息并转化为商机，成为众多电商企业都在认真思考的问题。
电商峰值系统要满足三面的要求：低时延，系统对数据的处理速度要快；高可用性，故障可及时恢复，对业务影响降到最小；易扩展性，可动态添加新的计算节点，不影响在线业务，甚至可以自动做出优化调整。
从这三个角度出发，Hadoop框架更适合于大数据批量处理。毕竟，它是先存储再访问，属于“一次写入多次读取”的业务类型。然而电商行业的很多业务，强调访问处理的实时性，包括电商搜索引擎、基于用户购买行为的实时商品推荐和针对网站流量的监控及反作弊等功能。这些业务要求处理行为达到秒级甚至毫秒级的时延，从而促进了以Storm为代表的流式计算系统的推广和应用。
1号店流式计算解决方案
1号店结合自己的业务需求，在力求降低成本的前提下，最终采纳Storm计算框架来实现自己的分布式流计算*台。1号店实时数据处理的整体流程如图1所示。
图1 1号店分布式流计算系统
Tracker是1号店独自开发的数据记录方案，它结合Flume构成网站的数据采集模块，能在保证日志记录效率和稳定性的同时，更好地支持横向扩展，以应对日益庞大的数据量。我们采用Kafka作为前端消息数据缓冲，尽可能降低数据丢失率，同时能够灵活满足不同业务对消息处理并行性和有序性的偏好要求。Storm应用的计算结果，按照各自业务需求选择持久化存储或丢弃。
为了更进一步保证流式计算系统的稳定性，光有容错处理是不够的，我们还必须想方设法减少计算*台被过重负载压垮的风险。Linux容器技术为我们的需求提供了极大便利。它以CGroup内核功能为基础，可以支持对CPU、内存、块设备读写和网络流量等资源的隔离限制，而且此类限制可以细化到进程级别（CGroup是以进程组为基本工作单位的）。通过采用Linux容器技术，可以避免某些业务进程侵占过多系统资源，从而导致节点系统响应缓慢甚至完全瘫痪。
很遗憾，Storm自身还没有支持CGroup资源隔离功能。目前的Storm on Yarn还是个概念性实现，因为YARN对Storm的资源隔离，仅针对整个Storm集群所占用的资源，以实现和Hadoop批量计算框架在同一集群上的共存。而我们的客观需求是希望能对Storm*台上Topology一级进行资源限制，对应到每个计算节点上，就是一种进程级别的资源隔离需求。最终的解决办法是，我们独立设计自己的CGroup资源管理框架，来实现对Storm Topology的资源隔离限制。在图2所示的设计方案中，我们主要考虑以下几点。
图2 1号店Storm集群上的资源管理框架
更简单的用户体验
1. 用户不需掌握CGroup的复杂细节（层级、子系统、组概念及相关操作系统和文件系统知识）。
2. 仅需掌握三种操作：
· 创建/删除某一类型的CGroup，目前支持cpu、memory和cpuset三种类型；
· 分配进程到指定的CGroup。
3. 如上操作可以通过重新设计实现的客户端指令（ycgClient）完成。
4. 用户仅需在Storm UI上对Storm Topology指定优先级（该处优先级定义为进程所在的进程组可获取资源的大小）。
5. 由守护进程（ycgManager）自动管理各计算节点的进程级优先级。
自动化方案降低手动管理成本
· Storm Topology的优先级信息存储在ZooKeeper集群中。
· 资源管理框架可以自适应异构机器结点的动态添加。
· 便于集群管理（机器配置信息会自动存储在ZooKeeper中，包括逻辑CPU个数、内存和交换分区大小）。
能对Storm集群的Worker/Executer级别进行资源限制
这是目前Storm on Yarn做不到的。
模块独立于计算框架本身，方便安装部署及回滚
适当的改进可以很方便地应用于其他框架*台中。
针对Storm UI不能满足我们业务需求的问题，我们基于非Clojure语言重新设计实现了其UI模块。之所以不采用Clojure语言及其Web框架，主要是考虑降低日后的学习和维护成本。在早期的使用中，我们发现原始的Storm UI有以下功能缺陷。
· 只能通过命令行提交Topology Jar包。
· 无法记录Topology操作日志，给运维管理带来不便。
· 缺少用户权限控制。
通过重新设计Storm UI，以上问题得到解决。管理员可以操作Storm UI的用户及其权限，也可以在UI上查看Topology的操作日志，对Storm应用进行有效跟踪管理。未来我们会在UI上对Topology做更细致的实时监控。
随着1号店越来越多的应用被部署在Storm*台上，实时计算的效益日趋明显。2014年上半年部分业务每天产生的日志大约有2亿多条，部署在Storm*台上的商品流量监控、个性化推荐和BI应用，都能做到个位数的秒级响应。同时，我们的日志流量在以极快的速度递增。除此之外，我们还有安全日志分析、反欺诈和订单监控等应用在有效运行。
总结
1号店作为一家成立时间较短的中小规模电商，业务增长十分迅速。我们意识到自己的实时计算*台在今后会有更大的压力和考验。在保证现有系统正常运行的同时，我们也在积极搜集业务部门的各种反馈，基于目前的*台和技术做进一步的调研和二次开发。如何提高系统峰值处理时的性能和可靠性，我们依然任重而道远。
摘要：此次双11蘑菇街的备战思路是：首先，清晰的架构划分可以大大减轻稳定性工作量；其次，功夫要尽量在*时做足，避免总是出临时解决方案；再次，普及稳定性思维，注意细节；最后，出现问题，先快速恢复再查找根源。
双11购物节即将来临,蘑菇街积极备战各种大型促销活动,为全国性的互联网购物节贡献自己的一份力量。保障这种大型促销活动能正常有序地进行,确保99.99%以上的可用性,是我们需要面对的一个严峻考验。因此,我们的工作主要依据以下几个思路开展。
该做什么的就做什么
保障整个系统的可用性和稳定性，第一步需要做的就是,使整体架构清晰化、层次化。那么，对系统进行合理拆分，是最直观的选择。从业务和技术角度出发，遵循SRP（Single Responsibility Principle）原则，合理拆分系统中的各个模块，明确每个模块的职责。这样可以方便快速定位和排查问题，甚至可以有针对性地对每个模块进行优化。
拆分方式基本上分为两种，路由拆分和物理拆分。所谓路由拆分，就是按照请求特征，将请求流量分摊到两个或多个同质的集群里面；而物理拆分，就是在路由拆分的基础上，按照业务和技术上的特征，将同质的集群进行彻底拆分，成为非同质集群。
下面以交易流程为例，来看一下如何操作拆分。交易流程主要包括购物车、下单、支付等几个环节，具体的拆分结果，如图1所示。
图1 交易流程拆分结果
经过分析，整个交易流程按照架构层次可以分解为展示层、业务层及外围应用三块内容，这三部分由于职责差异比较大，所以先按照物理拆分，让层次清晰。
再来看展示层，由于存在一些共享的东西，如页面元素等，做物理拆分，会引入额外的成本，所以路由拆分是不错的选择。
接着来看业务层。这一层是很容易按照角色和业务场景进行拆分的，例如，交易管理服务是给管理人员提供管理功能的，需要考虑权限、内控等问题；交易核心服务是给业务主流程提供主要业务功能，需要考虑可用性；交易查询服务是读取交易数据的主要途径，需要考虑易用性；交易网关服务主要是对接外部支付渠道，需要考虑连通性。很明显，这一层由于自身的差异性比较大，所以采用物理拆分是上上策。
最后来看外围应用，其中包括后台管理、日志查询、业务监控及交易超时控制等，这些应用基本上都是在底层系统*台（管理*台、日志*台、监控*台以及任务*台）进行二次开发而成的，所以天生就适合进行物理拆分。
从上面不难看出，拆分是一个细活，可以选择的维度很多，拆分方式也比较讲究。良好的拆分方案，会让系统更加清晰明了，每个模块该做什么的就做什么。这样应对大型促销活动时，可以游刃有余地按照模块特征进行优化。
……
小结
本文讲述了蘑菇街在确保可用性和稳定性实践中的一些工作思路，但并不是说做好以上几点，就能够保证网站在大型促销活动中的99.99%可用性和稳定性，只能算是在实践过程中得到的一些经验。
总结一下在可用性和稳定性工作中的一些感悟。首先，清晰的架构划分可以大大减轻稳定性工作量；其次，功夫要尽量在*时做足，避免总是出临时解决方案；再次，普及稳定性思维，注意细节；最后，出现问题，先快速恢复再查找根源。
作者姚明，蘑菇街架构支撑团队负责人兼架构师，负责蘑菇街的应用框架、基础服务、中间件产品、系统*台和安全体系等基础架构建设。擅长领域为应用系统架构设计、中间件技术产品设计、系统性能调优和Web安全防范。
摘要：履单流程也是电商系统中直接面对销售高峰带来的短时间内剧增的数据量的子系统之一，如何在流量骤增10倍甚至更多的情况下保证OMS的正常服务，是每一家电商密切关注和不断改进的重点，也是本文分享的核心经验。
OMS（订单管理系统）是电商ERP系统中的核心模块，其中的订单履行流程（履单流程）是消费者购物过程中有直接感知的最后一段，关系到用户体验，其正确性和时效性必须得到保证。同时履单流程也是电商系统中直接面对销售高峰带来的短时间内剧增的数据量的子系统之一，如何在流量骤增10倍甚至更多的情况下保证OMS的正常服务，是每一家电商密切关注和不断改进的重点。
与前端接单流程不同，履单流程无需提供秒级实时响应，但它要执行的工作不单是生成订单保存入库，而要协调ERP中诸多子系统、外部系统及人工处理，共同完成一个订单的出库发货，因此面临的问题和需要的解决方案都有所区别。
在麦包包，我们经历了一小时接单峰值从千级到万级再到十万级的高速增长，虽然OMS中有中间表、分页批处理等抗冲击设计，但在一年比一年高的流量峰值冲击下，仍不时出现阻塞甚至崩溃的迹象，让人胆战心惊。为解决这个问题，需要对整个履单流程所有环节进行分析，找出瓶颈和浪涌威胁，制定有针对性的解决方案，进行评估和测试，明确系统的峰值处理能力，保证在各种情况下的正确处理。
履单流程的流量治理同洪水治理道理相似，要找出高水位或者决堤的位置进行加固。加固的方法可以分为两个方向：
· 疏通和拓宽河道——优化算法、合理并行；
· 蓄水限流——异步、缓冲、限量。
本文将结合麦包包的履单流程面对流量暴增问题时，需要研究的流程节点分析、执行效率优化、入口隔离和异步化、固定流控和弹性架构等方面进行讨论。
关注点：一致性、可用性和峰值处理能力。
最低目标：流量不高于每小时10万单情况下，能够保证每个无须人工确认订单30分钟内提交拣货；流量不高于每小时100万单情况下，能保证每个订单最慢在6小时内提交拣货。
高级目标：流量高于每小时10万单时能动态提升吞吐能力，在流量不高于15万单情况下保持每个订单30分钟内提交拣货。
在讨论治理方案之前，我们需要将流程抽象和分解，进行深入分析。
流程节点分析
要保证系统在流量暴增的情况下正常提供服务，整个流程不能有任意一点产生阻塞。所谓阻塞点是直接或间接造成某个共享计算资源超负荷的点。电商OMS中，CPU和内存的密集计算一般不多，这个超负荷的计算资源多为DB Server。到底是哪一种类型的计算资源并不是最重要的，我们需要先找到引发或可能引发超负荷的原因，再找到其所在程序位置去解决。
履单流程从业务逻辑上一般分为前后衔接的多个步骤，我们将其称为处理节点，我们要做的就是分析流程中各个处理节点，特别是以往产生过阻塞的节点。分析时除了一般性的代码、数据结构的静态分析和单元测试，对产生过阻塞的节点还可以从现场日志入手去分析。例如，对于DB Server超负荷的情况，要分析阻塞现场的SQL队列，找到引起DB Server资源超载的主要几条SQL，再顺藤摸瓜找出触发这些SQL的代码位置和其所属的处理节点。
麦包包的履单主流程包括订单审核、支付确认、出库单生成、快递匹配等节点，简化的流程如图1所示。
图1 履单逻辑流程
通过代码和执行日志分析，我们发现订单人工审核、物流匹配耗时较长，订单的自动审核缺乏流量控制等问题。流程中节点耗时过长不仅会对整个流程的执行时间有直接影响，更重要的是当大量订单涌入时可能堆积过多的数据库慢查询，造成数据库并发过高、超负荷。人工订单审核虽然不是自动流程的一环，但由于和自动流程访问相同的数据库，在面临大量订单时同样也会拖慢数据库性能，造成大量的锁。
提交拣货到提交发货这一段属于WMS的范围，也需要持续优化，但这超出了本文的主题不在这里讨论。
这些问题需要逐一解决，首先我们需要对单节点的性能进行优化。
基本处理能力优化（单节点优化）
流程由一个个处理节点组成，如果各节点本身还有优化的余地，那么整体分析就难以把握最优方向。因此在流程级优化之前应该先对各个节点进行优化，确保计算处理本身已足够高效，也包括资源的合理使用和每个节点在架构上的可伸缩性。
流程整体调优前，首先要消除各个节点的执行效率瓶颈，做算法优化，提高并行效率，减轻或合理分布计算资源的占用。
以针对SOM（销售订单管理）模块进行的优化为例，优化前SOM模块的*均请求响应时间为1.89秒，优化后降低到了0.09秒。优化后单服务器每分钟可响应请求667次，而优化前只有32次左右，在系统架构和硬件资源不变的前提下，提高了节点的处理能力，降低了资源的占用。
做单节点的优化，主要侧重于逻辑优化、算法优化和代码优化等。这个话题已被讨论很多，基本原则如下。
· 优化算法，选择合适高效的算法，降低不必要的递归、循环、多层循环嵌套等计算。用简单的算法完成大部分情况，不要为少数特例而将算法复杂化。特例由特殊的分支处理。
· 避免申请过多不必要的内存开销。
· 及时释放资源，降低资源占用时间，包括内存、I/O、网络和数据库等。
· 善用缓存：缓存常用的、不易变化的；偶有变化，可以考虑缓存依赖机制。
· 慎用数据库锁。
· 恰当地使用事务，事务要细粒度。
· 选择适当的通信方式：Socket、Remoting、Web Services（REST和SOAP）、WCF、 Named Pipes等，要特别注意长连接和短连接的恰当使用。
· 计算并行化。
· 降低系统或模块之间的通信次数，例如工作流服务和数据库服务。
· 降低系统或模块之间的传输数据量，不必要传输的不传或少传。
· 异步计算，降低等待时间。
· 考虑延迟加载和提前加载两种方式。
· 分离原则：分离业务模块，如分离大I/O模块、分离高耗内存模块和分离高耗宽带模块。
· 统筹使用计算资源，如寻求内存计算、数据库计算和网络开销三者之间的最佳*衡。
在单节点优化中，以上方法都可能用到。而对于履单流程来说，计算并行化和节点伸缩性也会起到比较重要的作用。
……
摘要：如何在第一时间了解出现的问题并及时解决问题呢？一套完整的应用性能管理解决方案在电商峰值架构中将发挥无比重要的作用。本文分享了应用性能管理提供商听云，多年积累的电商峰值架构监控经验。
一年一度的“双11”购物狂欢节即将来临，要确保用户享受“快、稳、炫”的抢购体验，技术工程师们需要解决瞬间高并发的诸多问题，如海量数据处理、网络传输产生的延迟和负载均衡，等等。
那么，如何在第一时间了解出现的问题并及时解决问题呢？一套完整的应用性能管理解决方案在电商峰值架构中将发挥无比重要的作用，有了性能管理的保护伞，就可将“宕机”永远留在襁褓中。
本文分享了应用性能管理提供商听云，多年积累的电商峰值架构监控经验，希望能对大家有帮助。
监控内容
最底层是对服务器资源的监控，包括硬盘可用空间、CPU使用率、内存占用、I/O、网络流量等指标。
第二层是对网络链路层面的监控，其中包括内部网络状况的监控，例如集群之间的网络连通性、路由情况，还包括外部用户的网络状态监控，例如DNS、CDN服务质量等指标。
第三层是应用层面的监控，包括Web应用容器、数据库、NoSQL、手机App的指标，例如Cache命中率、JVM状态是否正常、每秒的请求量（QPS）、请求响应时间、请求状态、请求队列长度、数据库响应时间、慢SQL性能、Memcache、Redis服务状态、App打开率、App交互性能、App崩溃等指标。
最顶层是业务层面的监控，包括关键业务的处理能力和业务逻辑的流畅程度等指标，例如单位时间的订单数量、新客户注册数量、客户投诉数量、关键业务的队列排队数量、用户查询购买某一商品的流畅度等。对不同电商来说，监控指标内容和数据来源完全不同。图1中是需要监控的所有内容。监控内容存在短板效应，某一内容层面的监控缺失，均会引起电商的重大经济损失。
图1 监控内容
监控方法
构建监控*台通常有以下3种方式。
· 利用开源软件和*台结合shell脚本搭建监控*台。
· 自行研发监控工具和监控*台。
· 购买第三方的监控服务。
无论采取哪种方式搭建的监控*台，通常都采用分布式架构。如果集中运算的话，通信和运算的成本会很高。因此，电商会采取在监测点分析监控数据的方法，先产生一个比较小的结果数据，然后汇总到一个集中的监控*台上进行二次运算。
由于监控内容涉及面广泛，电商通常会根据不同的监控内容采用不同的监控途径。
服务器资源的监控方法
除了使用操作系统自带的基础命令（如top、 free)采集数据以外，阿里、京东等资金雄厚且技术能力强的知名电商公司，开发并开源了一系列监控工具，例如Tsar是阿里巴巴开源的采集工具，主要用来收集服务器的系统信息（如CPU、I/O、Mem和TCP等）和应用层面的数据（如Squid、HAProxy、Nginx等），用户也可以根据需求编写自己的采集模块，集成到Tsar中即可使用，产生的数据输出到远程数据库或者集成到Nagios或Cacti中即可显示。
网络链路层面的监控方法
监控内部网络的状态采取与监控服务器资源类似的方式，使用脚本调用操作系统自带的命令（Ping和Tracert等）或其他开源工具进行数据采集，数据集成到Nagios或Cacti中展示。
有两种监控外部网络状态的方法可以得到用户使用网站的体验数据。一种方法是自行开发并运营监控网络，此类方法适用于资金雄厚的公司，例如阿里开发了Alibench，并在全国征集志愿者安装这个工具，探测网站访问是否正常并将探测到的数据上传到服务器进行汇总分析。另一种方法是购买第三方服务，例如听云Network服务，以付费的方式招募会员，并在全球安装监测节点。这两种方法的技术原理相似，都是通过在全国或全球的终端用户电脑上部署探测工具，探测工具内嵌IE、Chrome、Firefox这些主流浏览器内核，获取访问网站过程中的DNS解析、TCP建立连接、页面DOM解析和页面渲染等过程的详细数据。通过查看分类汇总的数据分析哪些用户访问网站时出现了错误或性能瓶颈，哪些CDN提供的加速效果更优秀，从哪些角度可以进一步优化网站。
应用层面的监控方法
常规针对应用层面的监控方法是，利用脚本对应用服务器产生的日志进行统计分析，或利用应用服务器自带的统计分析命令和接口进行数据汇总。
在Web应用容器层面通过HTTP请求访问日志可以统计请求量（QPS）、请求响应时间、错误等信息，通过JVM命令查询JVM状态；在数据库层面，开启慢SQL查询日志，使用数据库相关命令统计慢SQL语句。
第三方APM服务厂商的应用性能管理服务，例如听云Server服务，采取自动跟踪Web应用容器内HTTP请求的出入口和应用代码函数方式，不仅可以采集应用运行时的QPS、请求响应时间、错误信息、SQL调用等信息，还可以采集到常规方法无法获取的代码级别的性能信息，进而分析应用的瓶颈所在。
对于*几年兴起的移动App而言，监控App应用需要研发人员嵌入第三方的SDK代码。SDK代码在App运行时统计用户的交互行为、打开情况和崩溃信息，在一定时间段内汇总信息，提交到监控*台。
业务层面的监控方法
对关键业务处理能力的监控，通常采取研发人员预留API接口，使用脚本调用API接口获取关键业务处理数据，并将数据集成到Nagios或Cacti中展示的方法。
业务逻辑流畅程度的监控需要购买第三方的业务流程监控功能，此类工具需要熟悉业务的人员录制业务流程的脚本，并上传到第三方监控*台。*台将流程脚本部署到第三方监控节点上，并自动回放流程脚本模拟用户对流程的操作，最终*台会采集到每一步骤的性能和错误信息。
案例
图2为某电商购物流程的监控曲线图，监控流程为打开电商首页，录入商品名称搜索，点击搜索结果中一款商品打开商品页，将商品加入购物车，点击付款。
图2 购物流程监控图
3月3日购物流程可用性突然下降至65%左右，说明此时35%左右的用户无法正常完成购物体验。由于监控*台设置的报警阈值为90%，所以监控*台在监控到发生异常后5分钟内发出了报警短信和报警邮件。电商运维人员接收到短信报警后通过查看详细的监控数据定位问题并及时通知研发人员解决，问题于购物高峰期来临之前被修复。
通过监控的浏览器拷屏数据发现，电商IT部门3月3日凌晨上线新改版的系统，由于兼容性测试不够全面导致部分浏览器出现JavaScript错误，引起界面错乱，造成购物流程无法正常完成（图3）。
图3 JavaScript错误，导致购物流程出问题
经过排查，程序员可以及时纠正这些问题，使电商网站尤其在关键业务上避免不必要的损失。
总结
通过前面的讲述，我们可以看到，利用有效的监控手段，可以及时了解用户访问电商时出现的问题，极大地有助于电商企业的技术工程师快速定位出现问题的区域，并尽快给出解决方案。这样可以极大提升电商网站的购物体验，对于大促、秒杀等峰值场景更为重要。简单一句话，“在电商峰值架构中，监控无所不在”。
摘要：用我们的视角观察阿里第六年的双十一，记录云计算与大数据的一次技术大阅兵。
2014年11月11日是阿里双十一的第六年。但却是CSDN云计算第一次参加双十一现场活动。在我们看来，双十一除了是电商的狂欢节日之外，也是云计算与大数据的一次“大阅兵”。电视与网络直播之外，我们更愿意从自己的视角将更多技术展现筛选出来，分享给我们的技术小伙伴们！（今日CSDN大头条是《鏖战双11，电商架构大起底》11.11需要稳定高效的系统架构设计来提供有力支持，揭示了国内各大知名电商架构设计的最佳技术实践。）
11月10日杭州淘宝。飞机落地后，来不及办理入住，直接冲入阿里数据大厅（媒体直播席）。而今年与往年最大的不同是，400多家媒体中，约1/4是外媒记者。
主持人介绍今年是双十一的第六年，从2013年的2000套缩减到今年的500套技术预案，8次流量峰值的压力测试*稳。今天所有数字都是实时的，未经任何加工的元数据。这是第一次将后台所有数据都直接对外公开。而所有数字都有美元显示（方便外媒理解）。
21:30，阿里集团COO逍遥子说，移动端的无线接入在18:30以后开始快速增长，这是六年来的第一次。他认为，这是大部分用户在下班后的回家途中，如公交车、地铁等，已经开始双十一的准备。针对之前业内的一些讨论，他再次强调双十一是所有人的。
21:35 有媒体问逍遥子对今年数字的预估？没有明确回答，但他相信绝对会让大家惊讶。
21:40,主持人在串场的时候，顺便浏览了会前信息，有几条不错：
今年的天猫双十一，活动页面、商品排序都是由算法决定的。哪些商品能进入双十一会场、出现在哪些用户的页面和什么位置，都有数据算法在背后支撑。
据阿里巴巴集团在2014年3月披露的数据，阿里巴巴的数据中心已经攒下超100PB（1PB=1024TB）经处理的数据。
基于大数据的算法，可以让流量更加个性化。每个人看到的双十一页面都不一样，大数据让推荐更加精准。
基于大数据的分析，能够预测下一阶段的消费热点，并给商家提出建议。
保障今年双十一的大军中，天猫事业部投入*2000名员工，阿里巴巴集团总投入超过11000名员工。天猫自身加上商家共投入*百万的客服力量，菜鸟的14家物流快递合作伙伴中共有125万快递员参与。
从技术方面来看，在历经五年双十一考验后，阿里巴巴技术团队已具备能力，将黑客攻击、局部爆发性流量增长、机房空调故障等种种“不确定因素”变为可预估的风险。基于在云计算领域长期的技术积累，阿里巴巴技术团队还在今年双十一之前，攻克了两项世界级的创新难题–“服务器资源弹性部署”和“数据中心异地双活”。
阿里巴巴在会议报告厅搭建了数字大屏,提供七路实时信号，包括数据大盘、全球交易图、百强县交易图、热卖品牌榜，菜鸟物流雷达预警等。相比去年13米长、6米高，升级到16米长，6米高，屏幕面积*百*米，总重超7吨。
22:00 天猫推荐算法获奖队伍在这次双十一中将有一次“暗战”。CSDN云计算的读者应该很有印象，8月的《学生强则国强，访天猫推荐算法大赛Top 9团队》就是我们对获奖团队的采访。这次淘宝将会将双十一的数据释放一部分给这些团队中的6位杰出同学，直接在后台进行算法PK，如果比天猫算法团队在这次实战中表现更为优秀（UV超过天猫团队的15%），将获得100万奖金。天猫技术负责人李强表示，阿里11000名技术小二需要更多帮手，欢迎更多技术伙伴加入进来。
22:30 剁手舞挺有意思，大家都去看看。：）现场问答的奖品是搭载云OS3.0的智能手机。
23:00 明星恭贺双十一的视频播放等。后台看到一些数据。0点将实时释放数据。对了，去年的数据是：2013年11月11日凌晨，一分钟内有1370万人涌入天猫，相当于大半个北京城的人都出来逛街。其中，34万“剁手党”在这一分钟内抢到了心仪的宝贝，成交1.17亿元。今年会是多少呢？
23:30 实时数据分析图终于对外公开了。数据大盘、全球交易图、百强县交易图、热卖品牌榜，菜鸟物流雷达预警等都有。居中的主屏幕是交易额、无线成交占比（每5S刷新一次），其他部分是2分钟刷新一次。先欣赏下。
23:58 是的，提前两分钟将切换。因为现在后台是10日的交易量。主持人反复强调观测数据发生，也许会有突发情况，请记者们一定冷静。
00:00 数据出来了。2014年11月11日凌晨，3分钟内成交超过10亿元。美国成为TOP4的购买区。无线成交在60%以上。
1分13秒时的照片留念
00:11 11分钟的时候，成交超过40亿元。由于美国现在是白天工作时间，所以购买力增长强劲，最高排到TOP2。14分钟，超过50亿元。17分钟，广东快递包裹量超过2万。19分钟，订单数量2600万个。超过170个国家参与到购物狂欢中。天猫双十一大家电送货入户的第一单，在11日零时18分送达，广东佛山一位买家购买的奥马冰箱。
00:25 2013年产生了1.5亿包裹量。今年双十一，25分钟时已经产生3000+万包裹，现场记者均认为预计包裹量将远超过去年。陆兆禧回复了记者关于销售额、物流等问题。
00:37 38分钟，突破100亿。2013年，38分钟50个亿，1小时67亿，今年50亿只用了14分钟，20分钟就完成了去年1个小时的交易额！100亿只用了38分钟！赞。
00:45 今天媒体直播到1点。明日还是到凌晨1点。看到很多有价值的照片，明日上图。
11月11日18:00左右，特别约了阿里技术保障部的技术负责人，聊一聊备战双十一的技术故事。大家有关心的问题，欢迎留言。
02:00现场大屏确实没有付款笔数的实时显示。考虑到支付宝、天猫宝、余额宝和银行对接系统的复杂性，也能理解。2点时，支付数据产生。第一分钟83万笔，第三分钟410万笔，第30分钟4086万笔,第一个小时，支付宝完成的付款笔数已经达到6283万笔。
移动方面的数据确实令人惊艳！开场第1分钟实现的移动支付笔数达到65万笔。开场后的第一个小时，用户通过手机完成的支付笔数则达到3504万笔支付。
补充些有意思的背景资料：
支付宝首席架构师程立表示，每年的双十一都是对中国支付系统的一个考验。从今年双十一第一个小时的情况来看，支付宝和各大银行、天弘基金等合作伙伴在双十一前充分的准备初步发挥了成效，整个支付系统稳定得经受了双十一第一波交易洪峰的考验。而跟往年相比，银行对此次双十一大促的重视程度空前。总行科技部位于北京的多家大行，即使在APEC放假期间也加班进行系统测试和优化。双十一的前一天，建行，*安，兴业，民生，中信等多家银行的行长已赶到杭州督战。
今年支付宝和各大银行的合作变化在于：四大国有银行和各家股份制大行都改变了以往分行各自对接的模式，开始余支付宝进行总对总对接，即银行总行科技部与支付宝系统对接。这一模式变更的好处在于银行科技部技术力量可以集中投入，同时减少交易链路消耗，提升系统处理能力及稳定性。
官方发布的数据显示，双十一第一个小时的支付中，快捷支付占到所有支付金额的46%，在所有渠道中占比最高；紧随其后的天猫宝占到所有支付金额的16%，余额宝支付占到15%，账户余额占14%。而传统的网银支付，所有银行的网银等其他渠道相加只占到了9%。天猫宝、余额宝及余额对于支撑整个双十一的支付系统，缓解银行支付渠道压力起到了至关重要的作用。
05:00 baba股票创新高， 市值触及3000亿美元。
07:00 7小时36分零6秒，2014天猫1111购物狂欢节无线成交额达100亿元！（移动端）数字还在跳跃。这个时候如果有机器人轮岗，会很棒。
10:00 2013年，聚石塔处理了75%的双十一订单。今年，构建在阿里云基础上的聚石塔将处理超95%双十一订单。在系统扩容、压测之外，与第三方服务商的ERP软件，如订单管理、客户关系管理、店铺运营等协作也是重点。有朋友说，还提供了“订单全链路”功能，帮助商家实时监控数据，从用户拍下订单、系统收到订单，到配送、签收完成交易，每一个环节都可用数据大屏进行监控。
12:00 截止十二点整，天猫1111购物狂欢节已有12家商家成交额过亿元！42家商家成交过5000万。菜鸟生成的订单和去年全天持*。值得纪念的是，11:49时突破52.9亿美元（超过去年美国感恩节购物季的所有金额）
13:23 359+亿元，无线占比45.2%。25分钟的时候，已经360亿元了。去年全天是362亿元，已经无线接*了。
13:31 超过362亿元，超越去年双十一战绩。期待已久的双十一技术总负责人刘振飞，蚂蚁金服CTO鲁肃和菜鸟负责人14:00左右将来到直播现场。
13:50 回味了几组数据：
2009年双十一销售额5200万元；
2010年双十一总销售额9.36亿元；
2011年，这一数字是52亿元；
2012，实现191亿成交额；
2013年，实现362亿元。
主持人说14:00时候，阿里联手所有伙伴送出一个“大彩蛋”？！哦，大数据分析告诉大家，14:00以后进入*稳阶段，增幅很窄，为了提供更多机会，所有卖光产品再来一次，相当于将双十一分成上下两场。是否有效果，一会数字说话。
14:00 振飞已经连续负责6届双十一技术保障，他说：“本次双十一交易能力达到每秒8万笔的上限；支付能力在峰值能力突破每秒 3.8万笔。在手机客户端上提升用户体验花费很大力气，成立无线小组，从移动网络、手机、网络优化进行了全方位的优化。支付体验也比较流畅，无论是支付宝还是银行支付，都能推荐用户比较适合的通道，便于抢货。更有创新的是，阿里历史上第一次打通了交易*台和支付*台，8次演练中遇到很多问题都得到了解决。所以今年高峰到来，我们淡定迎接了挑战。对于今年重点关注的海外客户，阿里特别在海外部署了更多的CDN，提升海外购物体验。”
对于本次阿里云和大数据技术在双十一中的作用，振飞强调了五点：
1. 通过基于阿里云的聚合塔，承担了95%双十一订单。
2.为中小金融机构提供服务是聚宝盆（阿里云金融服务），帮助更多用户使用金融服务。
3.基于阿里云的余额宝，成为支付的核心。
4.跑到飞天5K上的自主研发的ODPS，为天猫双十一的商品个性化推荐提供了技术支持。
5.凌晨切换到自研的核心数据库OceanBase上，经历了考验。以此为起点，支付宝数据库将取代国外技术，全面切换到OceanBase上。
14:50 蚂蚁金服鲁肃表示，支付宝在今年双十一的交易峰值已经达到285万笔/分钟，相比去年双十一期间79万笔/分钟的交易峰值，今年系统的支撑能力达到了去年3倍以上。他将成归功于：
1.每年大促扎实的基础之外，今年以来，支付宝在系统和技术上再次进行了升级。建立在云计算和大数据*台上，自研的云支付系统在双十一之前正式封顶，实现了全分布、全冗余、高弹性、低成本的海量交易与数据处理架构。相比上一代的支付宝系统架构，“云支付”架构可以支持十亿笔以上的每日支付处理能力，具备更高的服务质量、安全性与稳定性，更低的系统成本。
2.众多的银行合作伙伴也同支付宝一道在双十一之前把系统的支付能力提升到了去年的2倍以上。为顺利迎接双十一，支付宝和众多银行一道前后进行了10次以上高强度、高仿真的系统压力测试。当然，由于峰值压力的巨大，仍然有部分银行遭遇了拥堵瓶颈。(11月11日凌晨的交易高峰期，系统出现小范围的短暂拥堵，影响到淘宝、天猫和一些外部商户的交易成功率,但随着交易高峰期的结束，很快整个系统就恢复了正常，对于给大家带来的一些不便，他对此深表歉意。)
3. 10次以上的测试，其中大部分是携手振飞团队完成的，最后一次已经完全可以达到8w的上限。去年5月份，在去掉了最后一台小型机之后，OceanBase表现非常出乎意料，完全支撑了双十一的压力。
15:30 菜鸟物流的数据在整体分析中是很重要的一环。从零点到现在累计产生物流订单量是1.86亿笔（186,074,242）。如一些朋友所言，今年双十一在县级市场起量很快，这意味着，压力都在物流环节。
16:00 国际市场是今年新的增长点。目前已有206个国家和地区成交，在享受中国双十一。运输/物流很重要。速卖通*台，多数国内用户并不关注，但他是淘宝海外的代言者。这些数据分析却很有意思，目前来看，甚至格陵兰岛和智利都有下单。11日16点速卖通*台开始促销，数据变化能够明显表现这些。目前TOP消费国家及地区的是，中国香港、美国、中国台北、澳大利亚、加拿大、新加坡、澳门、日本、马来西亚和英国。
出口之外，进口同样重要。目前国内消费者购买海外商品越来越多。大出口，大进口的转折点到来了。天猫国际的体验就要和国内淘宝等完全一致。面对政策监管的需要，坚持数据运营很重要。
17:00 独家采访阿里技术保障部资深总监周明。他说从10月份预演和压测，第六次才全部通过。技术上，他重点分享了服务器资源弹性部署和数据中心异地双活。尤其是后者，从2013年初启动，直到*期才正式完成，刚好赶上双十一。而同时做到数据库，保数据的一致性，解决距离带来访问延迟的超大体量电商网站数据中心异地双活，目前全球只有阿里巴巴已完成部署。详细内容*期发布。
19:20交易额突破462亿元。俄罗斯数据快速上升。无线突破200亿元。
19:25 阿里巴巴集团董事局执行副主席蔡崇信极为低调，鲜少在媒体中露面，他的出现引发大家的关注。他分享了最初加入阿里的原因，并谈到阿里的快速发展离不开人，即使到现在也很缺人才。谈到投资，能增加用户粘性的创新企业会是收购目标。
20:00 大家电和手机在今年双十一中表现出色，TOP5分别为海尔、美的、海信、乐视TV、格力；小米、华为、魅族、苹果、三星。20:39时，订单量已经突破2.3亿个，成交额487+亿元。
21:10 突破500亿元。经过下午*稳增长后，开始迎来第二个成交额的“洪峰”。订单量达到2.4+亿。下午2点，依照大数据技术分析所产生的第二波活动，从时间轴的变化趋势可以看出，略有影响，
22:30 215个国家及地区在通过天猫上参加双十一活动。海外用户购买产品排行，第一名手机，第二名连衣裙，第三名假发。成交额已经533亿元。
22:36 马云穿着一件绿色上衣出现了，昨天在指挥室是红色上衣。他说并不太关注数字，而最担心的是明天的物流。今年是为国际化做尝试，是为未来3-5年国际化做准备。等到“双十一”十周年的时候，相信全世界都将为年轻人的创新而自豪。他再次对所有记者说，希望支付宝能在A股上市。
22:50按照去年的传统，最后时刻将关闭实时数据。留给大家十余分钟的想象空间，然后才公布结果。刚刚马云说，即使是双十一技术总负责人振飞也没有权利碰这些数字，他也是如此。所以，这些数字都是最真实的。
23:15 主持人说淘宝最主流的人群是80-90，随着这一代的成长，目前TOP20榜单中有大家电、家居、母婴用品等。小米突破15亿元，位于单店之首。25分时，成交额554亿元。从时间和成长曲线折率来看，也许最终600亿左右。
23:40 561亿。停止实时数据显示。20分钟之后，出最终结果。
0:02 最终数据为571亿。美元93亿。无线占比42.6%。2.78亿订单。
直播结束。留下的思考还有很多。技术无极限，创新无边界！