大型网站架构之总结：秒杀案例与小结

前言

目前为止，我们就已经将大型网站架构设计介绍了一遍，主要都是从大方向上去涵盖的，具体细分后每个细节，还是有很多东西需要我们去深入研究的，当然，今天我们就不去做深入研究各个细节了，后期再慢慢讲到。今天我们主要是讲个互联网电商中常见的一个案例：秒杀，然后对我们之前讲的内容做个简单的总结概括。接下来我们先谈谈秒杀的设计吧。

 

什么是秒杀？

秒杀是电商常见的一种营销手段：将少量的商品，以极低的价格，在特定的时间点开始出售，网站通过这种营销手段，制造某种轰动效应，从而达到网站推广的目的，秒杀虽然对网站推广有很多好处，但是对网站技术却是极大的挑战：网站是为正常运营设计的，而秒杀活动带来的并发访问用户却是平时的数百倍甚至上千倍，网站如果为秒杀时的最大并发访问量去设计部署，就需要比正常运营多很多服务器，而这些服务器在大多数时候都是用不上的，对于成本而言就比较浪费了，所以秒杀业务不能使用正常的网站业务流程，也不能和正常的网站交易业务公用一台服务器，必须设计部署专门的秒杀系统，进行专门应对。

 

秒杀的技术挑战

• 对现有网站业务造成冲击：秒杀活动只是网站营销的一个附加活动，这个活动具有时间短，并发访问量大的特点，如果和网站原有应用部署在一起，必然会对现有业务造成冲击，稍有不慎可能导致整个网站瘫痪；

• 高并发下的应用、数据库负载：用户在秒杀活动开始之前，通过不停的刷新浏览器页面以保证不错过秒杀，这些请求如果按照一般网站的应用架构，访问应用服务器，连接数据库，会对应用服务器和数据库服务器造成极大的负载压力；

• 突然增加的网络及服务器带宽：因为访问秒杀页面的用户剧增，对资源的请求量也是剧增，网络带宽也上去了，超过平时网站使用的带宽；

• 直接下单：秒杀的规则是到了秒杀秒杀时间才能开始对商品下单购买，在此时间点之前，只能浏览商品信息，不能下单。而下单页面也是一个普通的URL，如果得到了这个URL，不用等到秒杀开始就可以下单了；

 

秒杀系统的应对策略

• 秒杀系统独立部署：为了避免因为秒杀的高并发访问而拖垮整个网站，使网站不必面对蜂拥而来的用户访问，可将秒杀系统独立部署；如果需要还可以使用独立的域名，使其与网站完全隔离，即使秒杀系统崩溃了，也不会造成网站其他业务正常运行；

• 秒杀商品页面静态化：重新设计秒杀商品页面，不使用网站原有的商品详情页，页面内容静态化：将商品描述、商品参数、成交记录和用户评价全部写入一个静态页面，用户请求不需要经过应用服务器的业务逻辑处理，也不需要访问数据库，所以秒杀商品服务不需要部署动态的web服务器和数据库服务器；

• 租借秒杀活动网络带宽：因为秒杀新增的网络带宽，必须和运营商重新购买商品或者租借，为了减轻网站服务器的压力，需要将秒杀商品页面缓存在CDN，同样需要和CDN服务商临时租借新增的流量出口带宽；

• 动态生成随即下单页面URL：为了避免用户直接访问下单页面URL，需要将该URL动态化，即使秒杀系统的开发者也无法在秒杀之前访问下单页面URL，方案是将下单页面URL加入由服务器端生成的随机数作为参赛，在秒杀开始的时候才能获取得到；

 

秒杀系统架构设计

秒杀系统是为秒杀而设计，不同于一般的网购行为，参与秒杀活动的用户更关心的是如何快速刷新商品页面，在秒杀开始的时候抢先进入下单页面，而不是秒杀商品的详情页用户体验细节，因此秒杀系统页面设计应该尽可能的简单，下单表单也尽可能的简单，购买数量只能是一个且不能修改，送货地址和付款方式都使用用户默认设置的，没有默认也可以先不填，允许等订单提交之后修改；只有第一个提交的订单发送给网站的订单子系统，其余用户提交订单后只能看到秒杀结束的页面，另外还有下面几点需要注意的：

• 如何控制秒杀商品页面按钮是否可点击：购买按钮在活动开始之前应该要不能点击，当秒杀活动开始才能点击，如果此页面是动态生成的，当然可以在服务器端构造响应页面输出，控制按钮是否可点击，但是为了减轻服务器的负载压力，更好的利用CDN，反向代理等性能优化手段，该页面被设计成静态页面，缓存在CDN、反向代理服务器上，甚至用户浏览器上，秒杀开始时，用户刷新页面，请求根本不会到达应用服务器，解决方案是：使用js脚本控制，在秒杀商品静态页面中加入一个js文件引用，该js文件中加入秒杀是否开始的标志和下单页面URL的随机参数，当秒杀开始时，生成一个新的js文件并被用户浏览器加载，控制秒杀商品页面的展示，这个js文件使用随机版本号，并且不被浏览器、CDN和反向代理服务器缓存，如下图：

  

  这个js文件非常小，即使每次浏览器刷新都访问js文件服务器也不会对服务器集群和网络带宽造成太大的压力。

• 如何允许第一个提交的订单被发送到订单子系统：假设最终秒杀成功的用户只有一个，那么如何控制呢，在用户提交订单的时候，就得检查是否有订单已经提交，事实上由于最终能够成功提交的用户只有一个，为了减轻下单页面服务器的负载压力，可以控制进入下单页面的入口，只有少数用户能进入下单页面，其他用户直接进入秒杀结束的页面，假设下单服务器集群有10台服务器，每台服务器只接受最多10个请求下单，如下所示：

  

  秒杀整体系统架构如下图：

   

  

 

大型网站架构设计总结

我们再来回顾下整个网站架构设计，做个小结，网站系统架构层次如下图：

                        

前端架构：前端指用户请求到达网站应用服务器之前经历的环节，通常不包含业务逻辑，不处理动态内容

• 浏览器优化技术：并不是优化浏览器，而是通过优化响应页面，加快浏览器页面的加载和显示，常用的有页面缓存，合并HTTP减少请求次数，使用页面压缩等；

• CDN：内容分发，部署在网络运营商机房，通过将静态资源页面内容分发到离用户最近的CDN服务器，使用户通过最短路径获取内容；

• 动静分离，静态资源独立部署：静态资源，如JS，CSS等文件部署在专门的服务器集群上，和web应用动态内容服务分离，并使用专门的域名；

• 图片服务：不是指网站的logo，按钮图片等，这些和上面的静态资源放一起，这里所说的是网站用户上传的图片，如用户头像，产品图片等，同样使用独立的服务器部署图片服务器集群，并使用独立的二级域名；

• 反向代理：部署在网站机房，在应用服务器、静态资源服务器、图片服务器之前，提供页面缓存服务；

• DNS：域名服务，将域名解析成IP地址，利用DNS可以实现DNS负载均衡，配置CDN也需要修改DNS，使域名解析后指向CDN服务器；

 

应用层架构：应用层是处理网站主要业务逻辑的地方

• 开发框架：网站业务是多变的，一个好的开发框架应该能够分离关注面，使美工、开发工程师可以各司其职，易于协作，同时还应该内置一些安全策略，防护web应用攻击；

• 页面渲染：将分别开发维护的动态内容和静态页面模板集成起来，组合成最终显示给用户的完整页面；

• 负载均衡：将多台应用服务器组成一个集群，通过负载均衡技术将用户请求分发到不同的服务器上，以应对大量用户同时访问时产生的高并发负载压力；

• session管理：为了实现高可用的应用服务器集群，应用服务器通常设计为无状态，不保存用户请求上下文信息，但是网站业务通常需要保持用户会话信息，需要专门的机制管理session，使集群内甚至跨集群的应用服务器可以共享session；

• 动态页面静态化：对于访问量特别大而更新又不是很频繁的动态页面，可以将其静态化，即生成一个静态页面，利用静态页面的优化手段加速用户访问，如：反向代理，CDN、浏览器缓存等；

• 业务拆分：将复杂而又庞大的业务拆分开来，形成多个规模较小的产品，独立开发，部署，维护，降低系统耦合度，也便于数据库分库，按业务对关系数据库进行拆分，技术难度相对较小，而效果又相对较好；

• 虚拟化服务器：将一台物理机器虚拟化为多台虚拟机服务器，对于并发访问较低的业务，更容易用较少的资源构建高可用的应用服务器集群；

 

服务层架构：提供基础服务，供应用层调用，完成网站业务

• 分布式消息：利用消息队列机制，实现业务和业务，业务和服务之间的异步消息发送及低耦合的业务关系；

• 分布式服务：提供高性能、低耦合、易复用、易管理的分布式服务，在网站实现面向服务架构（SOA）；

• 分布式缓存：通过可伸缩的服务器集群提供大规模热点数据的缓存服务，是网站性能优化的重要手段；

• 分布式配置：系统运行需要配置许多参数，如果这些参数需要修改，比如分布式缓存集群加入新的缓存服务器，需要修改应用程序客户端的缓存服务器列表配置，并重启应用程序服务器，分布式配置在系统运行其提供动态推送服务，将配置修改实时推送到应用系统，无需重启服务器；

 

存储层架构：提供数据、文件的持久化存储访问与管理服务

• 分布式文件：网站在线业务需要存储的文件大部分都是图片，网页。视频等比较小的文件，但是这些文件的数量非常庞大，而且通常都在持续增加，需要伸缩性设计较好的分布式文件系统；

• 关系数据库：大部分网站的主要业务是基于关系数据库开发的，但是关系数据库对集群伸缩性的支持比较差，通过在应用程序的数据访问层增加数据库访问路由功能，根据业务配置将数据库访问路由到不同的物理数据库上，可实现关系数据库的分布式访问；

• NoSQL数据库：NoSQL数据库目前有很多，在内存管理、数据模型、集群分布式管理等方面各有优势，目前HBase相比之下是比较火的；

• 数据同步：拥有多个数据中心的网站必须在多个数据中心之间进行数据同步，以保证每个数据中心都拥有完整的数据，在实践中，为了减轻数据库压力，将数据库的事务日志同步到其他数据中心，根据log进行数据重演，实现数据同步；

 

后台架构：网站应用中，除了要处理用户的实时访问请求外，还有一些后台非实时数据分析处理

• 搜索引擎：使用网站内部的搜索引擎，也需要进行数据增量更新及全量更新，构建索引等；

• 数据仓库：根据离线数据，提供数据分析与数据挖掘服务；

• 推荐系统：社交网络及购物网站通过挖掘人与人之间的关系，人和商品之间的关系，发掘潜在的人际关系和购物兴趣，为用户提供个性化推荐服务；

 

数据采集与监控：监控网站访问与系统运行情况，为网站运营决策和运维管理提供支持和保障

• 浏览器数据采集：通过在网站页面嵌入js脚本采集用户浏览环境与操作纪律，分析用户行为；

• 服务器业务数据采集：服务器业务包括两种，一种是采集在服务器端记录的用户请求操作日志；一种是采集应用程序运行期业务数据；

• 服务器性能数据采集：采集服务器性能数据，如系统负载，内存使用率等；

• 系统监控：将上述采集的数据以图表的方式展示，以便运营和运维人员监控整个网站运行状况，做到这一步仅仅是系统监视，更先进的做法是根据采集的数据进行自动化运维，自动处理系统异常状况，实现自动化控制；

• 系统报警：如果采集的数据超过预设正常情况的阈值，比如系统负载过高，就通过邮件或者短信等方式发出报警信号；

 

安全架构：保护网站免遭攻击及敏感信息泄露

• web攻击：以http请求的方式发起攻击，危害最大的就是XSS和SQL注入攻击，但是只要措施得当，这2种攻击都是比较容易防范的；

• 数据保护：敏感信息加密传输与存储，保护网站和用户资产；

 

数据中心机房架构：大型网站需要的服务器规模数以万计，机房物理架构也需要关注

• 机房架构：对于一个拥有十万台服务器的大型网站，每台服务器耗电都是一大笔支出，数据中心能耗问题严重，机房地理位置应该选择散热良好，供电充裕的地方；

• 机柜架构：包括机柜大小，网线布局，指示灯规格，不间断电源，电压规格等一系列问题；

• 服务器架构：大型网站由于服务器采购规模庞大，大都采用定制服务器的方式代替购买服务器整机，根据网站应用需求，定制硬盘、内存、甚至CPU，同时去除不必要的外设接口（显示器输出接口，鼠标，键盘等），并使空间结构利于散热；

 

至此我们就完成了大型网站架构相关内容的讲解，讲得比较粗糙，具体细节并未涉及太多，毕竟是从一个整体的角度来讲解网站架构设计的，细节问题和技术点会慢慢去个个击破，感谢阅读。