网站五层架构

一、网页缓存层

  首先说网页缓存层,比如CDN租凭,其效果比公司自己部署Squid/Varnish要好,它们专业、价格低廉(比如:快网、蓝讯、阿里、腾讯)而且覆盖的城市更多,自己架设Squid/Varnish是次选。很多朋友喜欢尝试自建CDN,这是一项吃力不讨好的工作,未必能达到预期的目标,系统架构师应该在架设网站初期就规划好,不要等到网站流量及压力巨大时才去规划。事实上,这一层有很多优秀的开源软件都能胜任,比如传统的SquidCache。另外,越来越多的朋友喜欢尝试在自己的网站是用Nginx和Varnish作为自己的网页缓存。事实上,Nginx已经具备Squid所拥有的Web缓存加速功能。此外,Nginx对多核CPU的利用胜过Squid,现在越来越多的架构师都喜欢将Nginx同时作为”负载均衡服务器”与”Web缓存服务器”来使用,大家可以根据自己的情况,来决定究竟使用那种软件作为网站的网页缓存。

二、负载均衡层  

  我们熟悉的硬件/软件技术有F5、LVS/HAProxy,还有Nginx,它们的性能都是非常优异的,现在F5/LVS在全世界范围内应用,而且淘宝现在升级架构,也用了LVS取代了F5。HAProxy可能大家不是特别熟悉,单HAProxy+Keepalived确实在生产环境下表现优异,强大的吞吐能力,稳定性能比之硬件过犹不及,并且淘宝也在大规模地推广使用HAProxy,有兴趣的朋友也可以关注。
  再来聊聊Nginx,我已经将Nginx+Keepalived架构用于各种生产环境,经过长期的线上观察,发现Nginx作为负载均衡器/反向代理也很稳定,如果兵发压力过大,我们前面可以用F5/LVS作为最前端的负载均衡,而将Nginx作为七层代理,这样的效果其实也不差,所以说负载层压力不算特别大。

三、Web层  

  Web层压力比较大的网站现在都换成了Nginx作为Web应用服务器,事实上,它的抗并发能力确实超过了预期。我现在维护的一家门户网站,高峰期时某台Nginx应用服务器的并发达到了一万以上,但是Nginx也很稳定地提供服务。在实际的生产环境中,如果我们考虑到后端的数据库服务时,一万兵法应该也算是一个比较大的数值了。
  另外,Linux集群有一个优势,就是它的高扩展性,就算网站的并发有一万以上,后端的Web服务是Nginx,我们多加几台Nginx服务器即可。在实际的线上维护时发现,高峰期间,实际上每台Web的并发不算是特别大,所以我们也能通过技术手段对这一层的网站的压力加以克服。

四、文件服务器层

  现在大家生产服务器一般是使用如下四种作为自己的文件服务器层:
(1)单NFS+备份NFS作为文件服务器,这样做的好处是维护方便,但存在单点故障,需要人手动干预。
(2)DRBD+HeartBeat+NFS高可用文件服务器,维护方便,也不存在单点故障,单随着访问量的增大,后期一样存在压力过大的情况。
(3)分布式文件系统MFS、Glustr。MFS易用、稳定、对海量小文件很高效,而且新版的MFS解决了MasterServer存在单点故障的问题,国内越来越多的公司在使用MFS。事实上,分布式文件系统是解决文件服务器压力过大的最终途径,但也存在隐患,网站功能越多,摊子越大,机器越多,维护起来越复杂。
(4)如果是淘宝和腾讯这种巨量级的公司,可以尝试开发自己的分布式文件系统了。大家可以尝试根据自己网站的情况,来决定究竟选择哪一种如那件作为自己的文件服务器。

五、数据库层  

  数据库层的压力,我觉得网站的PV和并发上去以后,数据库这块的压力是最大的,CND大型广告网站用的是OracleRAC方案,它保证了数据的搞可用性,当然了价格也是非常昂贵的(如果使用高配置的PC服务器,Oracle一般按照CPU个数收费);那么字啊使用免费的MySQL数据时,面对这种并发压力打的情况,我们应该怎么办?
  首先,可以在数据库中加入memcached数据缓存,在实际线上使用时,发现memcached功能强大、性能稳定,在数据流频繁读写,压力过大的情况下,增加一台memcached数据库缓存服务器的效果能超过我们的预期。
  数据库的硬件方面可以考虑投入磁盘队列做成RAID10,如果资金充裕,磁盘可以用固定硬盘来代替SAS硬盘,毕竟数据库的压力主要来自磁盘I/O方面。
  合理的设计MySQL数据库的架构,事实上,在生产环境下,一主多从、读写分离是靠谱的设计方案,从MySQL的负载均衡推荐大家使用LVS,这是因为当后面的MySQL机器超过十台时,HAProxy在这方面的性能不如LVS。
  如果网站的业务量过大,可以采用分库的方法,比如将网站的业务量分成Web、BBS、Blog等几组,每一组均采用主从还够,这样的设计避免了单组数据库压力过大的情况。
  另外我们应该还配合公司的MySQLDBA和开发人员,在数据库参数优化、SQL语句优化、数据切分上多下功夫,避免数据库成为网站的瓶颈。

六、网站架构关注方向总结

(1)我们的网站放在IDC机房内,首选考虑的就应该是如何防止DDOS/CC攻击。DDOS攻击虽然没什么技术含量,但真正攻击过来还是很让人烦躁的。在搭建网站或系统时,我们应该尽可能地了解和熟悉各种防火墙的技术指标参数,为客户提供性价比最好的防火墙方案也是保证整套系统或网站成功的因素之一。
(2)业务逻辑设计要合理,尤其是程序代码层的相关设计,如果程序应用架构和业务实现不够优化,一个本来很简单的实现却绕了很多弯路才实现,那么多强的硬件也没有用。
(3)也许是受张宴先生的影响,现在越来越多的朋友把注意力放在Nginx上了。其实Apache的抗并发能力并不弱。在生产环境下,如果我们的网站不是广告型网站、门户型网站或游戏型网站,2000并发已经是一个很惊人的数字。另外这个仅仅是一台Apache的并发,一个中等规模的网站,后端至少会有3~4台Apache的Web应用程序,所以,全部加起来我们的网站差不多可以顶住上万的并发,上万的并发量对网站根本没有什么大的影响。当然,如果换作Nginx作为Web应用服务器更没问题了。另外,就算并发量非常大,我们最前端的F5/LVS还是顶得住的,无非是在后端多加几台Web应用服务器。所以说,并发量大不可能成为Web应用服务器的瓶颈。
(4)DRBD+HeartBeat+NFS文件服务器在初期没什么压力,但随着网站的用户数和流量越来越大,它可能会感觉有些顶不住了,特别是用户频繁访问图片文件时。我们在公司内部也测试郭Google的分布式文件系统,但是一直没敢用于生产环境中,最后还是决定采用Nginx作为中层代理,增加Squid反向代理服务器集群的方法来解决文件服务器的压力问题。另外,如果资金充裕,最前端也应该租售CDN用于网站加速。
(5)将Nginx作为中层代理使用是一件性价比非常高的事情。如果担心单点Nginx故障,我们可以设置3台以上的Nginx负载均衡器,而它们的loadbalance可以让F5/LVS来做。Nginx在这层可以利用其强大的正则处理能力很完美地处理客户端对静态文件的访问,比如将html、jpg、png、css等交给后端的Squid/varnish集群处理,冬天的PHP/JSP访问请求交给后端的PHP/Tomcat集群服务器处理,动静分离,最大化地发挥Nginx作为负载均衡器/反向代理的优势。如果没有硬件的F5Big-Ip设备,我们也可以用软件LVS来实现,这样成本会相当低。Nginx则利用其强大的正则功能,并根据URL或客户请求文件的后缀名来做动静分离,或者轮询不同的Squid/Varnish反向代理群组。
(6)上线的项目在后期无论怎么优化或架构,最后其压力最大的肯定是MySQL数据库,尤其是那些动态网站。我们在维护时也发现,MySQL数据库在频繁地读写,如何优化MySQL数据库及设计高性能高可用的MySQL数据库架构一致是我们关注和研究的方向,我也希望大家在工作中注意这个问题。
(7)系统或网站的构建、运维和调试并不只是一个人的事情,它是整个团队合作努力的结果,需要整个团队的开发人员、系统工程师和DBA及测试人员共同努力,要写出安全、效率高、优美的代码,需要花费开发人员大量的心血。

时间: 2024-12-17 20:24:17

网站五层架构的相关文章

大型网站系统架构的演化(转)

前言 一个成熟的大型网站(如淘宝.京东等)的系统架构并不是开始设计就具备完整的高性能.高可用.安全等特性,它总是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式.技术架构.设计思想也发生了很大的变化,就连技术人员也从几个人发展到一个部门甚至一条产品线.所以成熟的系统架构是随业务扩展而完善出来的,并不是一蹴而就:不同业务特征的系统,会有各自的侧重点,例如淘宝,要解决海量的商品信息的搜索.下单.支付,例如腾讯,要解决数亿的用户实时消息传输,百度它要处理海量的搜索请求,他们都有各

大型网站技术架构

初始阶段 小型网站的架构很简单,访问量很少,一台服务器充当应用服务器.数据库服务器和文件服务器都绰绰有余. 应用服务与数据服务分离 随着业务量的增大,业务的处理能力遇到了瓶颈.CPU总是满负荷,文件越来越多,而数据库越来越繁忙.这时候需要增加服务器,将服务器的职能进行划分,分别是应用服务器.文件服务器和数据库服务器. 缓存技术改善网站性能 网站访问量的规律与现实世界中的财富分配一样遵循二八原则.80%的业务集中在20%的数据中,比如百度搜索的关键字集中在少数的热门词汇中,淘宝前几页的商品占了大部

JavaWeb网站技术架构

JavaWeb网站技术架构总结 题记 工作也有几多年了,无论是身边遇到的还是耳间闻到的,多多少少也积攒了自己的一些经验和思考,当然,博主并没有太多接触高大上的分布式架构实践,相对比较零碎,随时补充(附带架构装逼词汇). 俗话说的好,冰冻三尺非一日之寒,滴水穿石非一日之功,罗马也不是一天就建成的,当然对于我们开发人员来说,一个好的架构也不是一蹴而就的. 初始搭建 开始的开始,就是各种框架一搭,然后扔到Tomcat容器中跑就是了,这时候我们的文件,数据库,应用都在一个服务器上. 服务分离 随着系统的

《大型网站技术架构》读书笔记之七:随需应变之网站的可扩展架构

此篇已收录至<大型网站技术架构>读书笔记系列目录贴,点击访问该目录可获取更多内容. 一.可伸缩与可扩展-傻傻分不清楚 上篇笔记我们学习了可伸缩架构,但在实际场合中,包括许多架构师也常常混淆可伸缩和可扩展,用可扩展表示伸缩性.那么在此,跟随作者我们来理清这两个概念,避免我们以后对其傻傻分不清楚. (1)扩展性(Extensibiltiy) 指对现有系统影响最小的情况下,系统功能可持续扩展或提升的能力.我们不禁想到了面向对象中一大原则:开闭原则,对扩展开放,对修改封闭.也就说,当系统新增一个功能时

《大型网站技术架构》读书笔记之六:永无止境之网站的伸缩性架构

此篇已收录至<大型网站技术架构>读书笔记系列目录贴,点击访问该目录可获取更多内容. 首先,所谓网站的伸缩性,指不需要改变网站的软硬件设计,仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力.在整个互联网行业的发展渐进演化中,最重要的技术就是服务器集群,通过不断地向集群中添加服务器来增强整个集群的处理能力. 一.网站架构的伸缩性设计 1.1 不同功能进行物理分离实现伸缩 (1)纵向分离:将业务处理流程上得不同部分分离部署,实现系统的伸缩性: (2)横向分离:将不同的业务模块分离部署

《大型网站技术架构》读书笔记之八:固若金汤之网站的安全性架构

此篇已收录至<大型网站技术架构>读书笔记系列目录贴,点击访问该目录可获取更多内容. 一.网站应用攻击与防御 二.信息加密技术与密钥安全 三.信息过滤与反垃圾 四.电子商务风险控制 五.学习总结 转眼之间,<大型网站技术架构>的读书笔记到此就结束了.最近时间非常紧,因此本篇没有详细对笔记进行介绍(本篇涉及太多内容,而且都是安全相关的).通过本书的学习,我们从高性能.高可用.伸缩性.可扩展性.安全性五个方面的架构学习了每个方面经典的技术方案,虽然以理论偏多,但还是可以从中管中窥豹,一览

大型网站技术架构的演进

最近我在阅读 2 本关于大型网站架构的书:<大型网站技术架构--核心原理与案例分析>李智慧.<大型网站系统与 Java 中间件实践>曾宪杰. 我期望从这些书中学习到大型网站是如何做架构的,这个过程会遇到什么问题.当看完这 2 本书后,我总结出两个大问题: 1. 网站技术架构为什么会演进?换个说法就是为什么网站会变大? 2. 演进的过程会遇到什么问题?或者说为了演进,会遇到什么问题? 网站技术架构为什么会演进 我个人总结出来我们的技术架构演进的两种驱动力,驱动着我们为什么演进网站的技

《大型网站技术架构核心原理与案例分析》阅读笔记-01

通过阅读该书籍我们能够更加清楚的树立大型网站的的技术发展历程,剖析大型网站技术架构模式,深入的讲述大型互联网架构核心原理,并通过一些典型的技术案例来讲述大型网站开发全景视图,该书籍深入的阐述了各种大型网站面临的各种架构问题及解决方案. 在第一章第一篇大型网站架构演化中了解到与传统企业应用系统相比,大型互联网应用系统具有高并发大流量.高可用性.海量数据.用户分布广泛,网络情况复杂.安全环境恶劣.需求快速变更,发布频繁.渐进式发展等特点:大型网站架构演化发展历程经历了初始阶段的网络架构它的应用程序.

大型网站技术架构(一):大型网站架构演化

第一章:大型网站架构演化 九层之台,始于垒土:千里之行,始于足下. 对于网站的发展,亦是如此,从上世纪90年代开始,互联网经历了20多年的发展,发生了翻天覆地的变化,今天,全球有一半的人使用互联网,从信息检索到实时通信,从电子购物到文化娱乐,互联网渗透到了生活的每一个角落.但是,构建一个高性能的网站,绝非一朝一夕可以完成,我们来看下,作为一个大型网站系统应有的特点: 1.大型网站系统应有的特点 高并发,大流量:需要面对高并发用户,大流量访问.举个例子,去往迪拜的飞机有200张票,但是有100w人