本文汇总了多家电商企业在应对峰值流量时的系统架构设计与实践，包括快、稳、炫三字诀，系统分级、解耦与SOA、流式计算解决方案等，展示了如何通过技术手段确保用户流畅体验、系统稳定性和高性能。文章涵盖了京东、当当、小米、海尔、唯品会等电商的案例，揭示了在双11等大型促销活动中，电商技术的较量与技术创新的重要性。
电商架构
目录
一、 电商峰值系统架构设计
摘要：双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、之前提到的主动同步延迟等。可以结合当前使用的监控工具进行一定程度的二次开发，市场上也有一些第三方提供的云服务可供选择。
业务实时监控，主要是指对业务数据进行监控，如
最低0.47元/天 解锁文章
扫一扫
3588
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
