传统企业电商峰值系统应对实践

摘要：双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、转化率、下单量、支付量、发货量和仓内作业效率数据，在给业务提供相关决策的同时，也可以用于辅助判断系统问题。

业务实时监控一般分为入侵型与非入侵型两种。

入侵型需要在程序的各个流程节点上进行埋点，相关动作被触发后，通过消息队列推送给监控界面进行展示；非入侵型一般通过分析网络流量，匹配出相应的请求进行内容分析，从而判断出相关目标事件的发生并进行统计与展示监控界面。

入侵型监控系统一般需要进行定制开发，但实现逻辑简单，技术难度较高；非入侵型监控系统开发难度较高，但部署配置简单，同时由于无需在目标系统上进行二次开发，对目标系统不会产生任何压力。

除了以上所讨论的常见问题，在设计一个电商峰值系统的过程中，还有很多问题需要解决，如缓存的更新机制、可靠的消息队列设计、自动化运维体系的建设等。

但最关键的是要求我们电商系统架构师同时在技术和业务上达到精通的程度，才能设计出一个性能优良、成本合理的电商峰值系统。