看的一个pdf说的。。大型网站架构演变

摘要: 大型网站架构演变

第一步：物理分离 webserver 和数据库

将应用和数据库从物理上分离，变成了两台机器

第二步：增加页面缓存

例如 squid

第三步：增加页面片段缓存

例如 ESI 等

第四步：数据缓存

缓存技术，包括像 Map 数据结构、缓存算法、所选用的框架本身的实现机制等

第五步： 增加 webserver

1、如何让访问分配到这两台机器上，这个时候通常会考虑的方案是 Apache 自带的负载均衡

方案，或 LVS 这类的软件负载均衡方案；

2、如何保持状态信息的同步，例如用户 session 等，这个时候会考虑的方案有写入数据库、

写入存储、cookie 或同步 session 信息等机制等；

3、如何保持数据缓存信息的同步，例如之前缓存的用户数据等，这个时候通常会考虑的机

制有缓存同步或分布式缓存；

4、如何让上传文件这些类似的功能继续正常，这个时候通常会考虑的机制是使用共享文件

系统或存储等；

第六步：分库

这一步更多的是需要从业务上做合理的划分，以实现分库，具体技术细节上没有其他的要求

第七步：分表、DAL 和分布式缓存

分表更多的同样是业务上的划分，技术上涉及到的会有动态 hash 算法、consistent hash 算法

等；

DAL 涉及到比较多的复杂技术，例如数据库连接的管理（超时、异常）、数据库操作的控

制（超时、异常）、分库分表规则的封装等；

第八步：增加更多的 webserver

1、Apache 的软负载或 LVS 软负载等无法承担巨大的 web 访问量（请求连接数、网络流量等）

的调度了，这个时候如果经费允许的话，会取的方案是购 买硬件负载，例如 F5、Netsclar

、Athelon 之类的，如经费不允许的话，会取的方案是将应用从逻辑上做一定的分类，然

后分散到不同的软负载集群中；

2、原有的一些状态信息同步、文件共享等方案可能会出现瓶颈，需要进行改进，也许这个

时候会根据情况编写符合网站业务需求的分布式文件系统等；

在做完这些工作后，开始进入一个看似完美的无限伸缩的时代，当网站流量增加时，应对的

解决方案就是不断的添加 webserver。

第九步：数据读写分离和廉价存储方案

数据读写分离要求对数据库的复制、standby 等策略有深入的掌握和理解，同时会要求具备

自行实现的技术；

廉价存储方案要求对 OS 的文件存储有深入的掌握和理解，同时要求对采用的语言在文件这

块的实现有深入的掌握、

第十步：进入大型分布式应用时代和廉价服务器群梦想时代

1、拆成分布式后需要提供一个高性能、稳定的通信框架，并且需要支持多种不同的通信和

远程调用方式；

2、将一个庞大的应用拆分需要耗费很长的时间，需要进行业务的整理和系统依赖关系的控

制等；

3、如何运维（依赖管理、运行状况管理、错误追踪、调优、监控和报警等）好这个庞大的

分布式应用。