分享

大型网站架构演化一些关键点

2016-04-29  心不留意外尘   |  转藏
   

http://blog.csdn.net/yyyiran/article/details/17174331

2013.12

一直都对海量服务后台架构很感兴趣,最近看完了《大型网站技术架构 & 核心原理与案例分析(李智慧 著)》一书,涵盖了大型网站架构的很多技术细节,写得极其赞!这里结合自己的一些见解,整理一个笔记出来。


// =======================================================================================


单服务器LAMP

* 大学时期常搞的LAMP,Linux+Apache+MySQL+php,接入、应用程序、数据库、文件都在一台服务器。流量小,一台机器绰绰有余

* 增长瓶颈:机器功能耦合

PS:架构设计一个核心原则就是高内聚低耦合,将网站的接入、逻辑、存储分开到专门的服务器是首先考虑的


应用逻辑和存储分离

* 3台服务器各司其职:应用服务器(CPU),文件服务器(磁盘容量),数据库服务器(磁盘IO)

* 增长瓶颈:数据库访问压力大

PS:数据库最终会读写磁盘文件,受到磁盘IO限制会首先成为瓶颈


引入缓存减少数据库读写

* 缓存是后台开发一种重要的方法,其背后遵循的是“局部性原理”,也称“28定律”:即日常80%的访问会集中在20%的数据上。将这小部分“热点”数据缓存在内存中,就可以大大降低数据库的访问次数

* 缓存分为2种,本地缓存和分布式缓存

1 本地缓存:数据缓存在应用服务器上。优点是本地内存读写操作(纳秒级),速度最快;缺点是内存大小受限,扩展性较差

2 分布式缓存:数据缓存在专用的缓存服务器上。优点是应用和存储低耦合,专门服务器维护,易扩展;缺点是读写需网络开销(毫秒级)

* 缓存数据更新:应用程序首先读缓存,读不到数据时再访问数据库,并将读到的数据写入缓存。如果这时缓存是满的,就必须淘汰一些已有数据,常用的淘汰算法是LRU,即最近最少使用

* 增长瓶颈:应用服务器并发处理能力


使用应用服务器集群提高网站并发处理能力

* “网站撑不住了,就拿机器顶!”,集群是海量服务中解决高并发的常用手段

* 负载均衡:多台应用服务器,如何将前端请求均匀分发到各台机器上,这就需要前端加一个负载均衡服务器做请求分发。nginx简单灵活的负载均衡策略被广泛使用,常见的负载均衡算法有轮询、随机、加权、来源地址hash等

增长瓶颈:数据库负载过高

PS:当网站访问量继续上升,虽然加了缓存,但是缓存不命中及应用写操作(当然也有只写缓存的策略)还是需要访问数据库


数据库读写分离

* 数据库服务器主从分离:一台主数据库服务器(Master)负责写操作,多台从数据库服务器(Slave)负责读操作,主服务器被写之后会同步数据变更到从服务器

* 数据库访问模块封装:将应用程序对数据库的操作封装成模块,使得后端数据库读写分离等变更对应用程序透明(高内聚低耦合)


到目前为止,网站总体架构如下图所示,已经能支撑起大部分网站的访问需求了。当然,不单单是网站,这些架构关键点对任何海量服务的后台开发都是相通的



当网站访问继续增加,有日均PV过亿的趋势,这时网站其实还有很多关键点可以继续优化:


使用反向代理和CDN做网站文件缓存

* 将网站一些静态文件,如图片、html页面等缓存在反向代理服务器或者CDN服务器,用户的请求可以不用到达应用服务器就返回数据给用户。是网站加速、提高用户体验的2种常用手段

1 反向代理:部署在网站中心机房

2 CDN,即内容发布系统:部署在网络提供商各地的机房,常用于视频和图片文件的缓存


使用分布式文件系统

* 当一台文件服务器满足不了网站文件存储需求时,接下来应考虑的就是使用分布式文件系统。HDFS、HBase等是当前海量文件存储比较热门的方案


使用分布式数据库和NoSQL

* 关系型数据库的分布式是大型网站业务持续增长的最后手段,可通过不同业务模块分库,相同业务模块分表等方法实现数据库的分布式部署

* NoSQL相对于关系型数据库有更简单的数据结构,更高的性能及更好的可扩展性。但对业务需求的支持也相对有限。


应用逻辑的业务模块拆分

* 一个网站必定有多种业务模块,比如购物网站都有用户模块、商品模块、订单模块等等,将这些业务模块拆分并独立维护。保证各业务模块高内聚低耦合,利于开发上团队分工,也利于后期独立部署运营


// =======================================================================================


大型网站架构设计的一些价值观:


* 大道至简。简单的设计使开发和维护变得清晰有序

* 业务和功能的划分和模块化。各业务模块,各功能模块(接入-逻辑-存储)划分清晰,高内聚低耦合,尘归尘土归土

* 架构来源于需求,而不是技术。架构设计衡量标准是满足用户的产品需求,而不是为了技术而技术

* 架构是演化而来的。别追求有完美的架构设计后再上线,好的架构往往都是不断修改甚至推翻之后慢慢演化而来的

* 不要所有问题都用技术来解决。有些技术上难以解决的问题,往往可以用业务手段来解决,如12306的整点售票改为分时段售票,从业务上来平摊用户请求量

* 衡量指标:性能、可用性、伸缩性、扩展性、安全性。


    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 全屏 打印 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多