《大型网站技术架构：核心原理与案例分析》——大型网站架构演化过程
2017-10-27 19:51
447 查看
大型网站软件系统的特点
高并发，大流量高可用
海量数据
用户分布广泛，网络情况复杂
安全环境恶劣
需求快速变更，发布频繁
渐进式发展
大型网站架构演化发展历程
初始阶段的网站架构
" title="">
Linux+PHP+Apache+MySQL
应用服务和数据服务分离
演化原因一台服务器逐渐不能满足需求，越来越多的用户访问导致性能越来越差，越来越多的数据导致存储空间不足
演化后
应用和数据分离后整个网站使用三台服务器
应用服务器：需要更快更强大的CPU处理大量的业务逻辑
文件服务器：需要更大的硬盘存储大量用户上传的文件
数据库服务器：需要更快的硬盘和更大的内存进行快速磁盘检索和数据缓存
" title="">
使用缓存改善网络性能
演化原因大部分的业务访问集中在一小部分数据上，把这一小部分数据缓存在内存可以减少数据库的访问压力，提高整个网站的数据访问速度
演化后
网站使用的缓存可以分为两种
本地缓存：缓存在应用服务器上，优点是访问速度更快一些，但是受应用服务器内存的限制，其缓存的数据量有限，而且会出现和应用程序争用内存的情况
远程缓存：缓存在专门的分布式缓存服务器上，优点是可以使用集群的方式，部署大内存的服务器作为专门的缓存服务器，可以在理论上做到不受内存容量限制的缓存服务
" title="">
使用应用服务器集群改善网站的并发处理能力
演化原因当一台服务器的处理能力、存储空间不足时，应该增加一台服务器分担原有服务器的访问及存储压力
演化后
通过负载均衡调度服务器，可将来自用户浏览器的访问请求分发到应用服务器集群中的任何一台服务器上，如果有更多的用户，就在集群中加入更多的应用服务器，使应用服务器的负载压力不再成为整个网站的瓶颈
" title="">
数据库读写分离
演化原因在网站的用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈
演化后
利用数据库的主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上，实现数据库读写分离，从而改善数据库负载压力
应用服务器在写数据的时候，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库，这样当应用服务器读数据的时候，就可以通过从数据库获得数据
应用服务器端应使用专门的数据访问模块，使数据库读写分离对应用透明
" title="">
使用反向代理和CDN加速网站响应
演化原因不同地区的用户访问网站时，速度差别极大，为了提供更好的用户体验，需要加速网站访问速度
演化后
使用CDN和反向代理尽早返回数据给用户，一方面加快用户访问速度，另一方面也减轻后端服务器的负载压力
CDN：CDN部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据
反向代理：部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户
" title="">
使用分布式文件系统和分布式数据库系统
演化原因单一服务器满足不了大型网站持续增长的业务需求，需要使用分布式数据库和分布式文件系统
演化后
将数据库拆分，把不同业务的数据库部署在不同的物理服务器上
" title="">
使用NoSQL和搜索引擎
演化原因随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂
演化后
采用一些非关系数据库技术如NoSQL和非数据库查询技术如搜索引擎
" title="">
业务拆分
演化原因大型网站为了应对日益复杂的业务场景，通过使用分而治之的手段将整个网站业务分成不同的产品线，如大型购物交易网站就会将首页、商铺、订单、买家、卖家等拆分成不同的产品线，分归不同的业务团队负责
演化后
根据产品线划分，将一个网站拆分成许多不同的应用，每个应用独立部署维护，应用之间可以通过一个超链接建立关系，也可以通过消息队列进行数据分发
" title="">
分布式服务
演化原因随着业务拆分越来越小，存储系统越来越庞大，应用系统的整体复杂度呈指数级增加，部署维护越来越困难
演化后
既然每一个应用系统都需要执行许多相同的业务操作，比如用户管理、商品管理等，那么可以将这些共用的业务提取出来，独立部署。由这些可复用的业务连接数据库，提供共用业务服务，而应用系统只需要管理用户界面，通过分布式服务调用共用业务服务完成具体业务操作
" title="">
淘宝网的架构演化
2003年 LAMP架构
" title="">
2004年 转向Java+Oracle
" title="">
2006年
" title="">
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 