|
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的整点售票改为分时段售票，从业务上来平摊用户请求量 * 衡量指标：性能、可用性、伸缩性、扩展性、安全性。
|
|
|
