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

前言

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

 

什么是秒杀?

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

 

秒杀的技术挑战

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

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

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

  • 直接下单:秒杀的规则是到了秒杀秒杀时间才能开始对商品下单购买,在此时间点之前,只能浏览商品信息,不能下单。而下单页面也是一个普通的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,同时去除不必要的外设接口(显示器输出接口,鼠标,键盘等),并使空间结构利于散热;

 

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

©️2020 CSDN 皮肤主题: 我行我“速” 设计师:Amelia_0503 返回首页