大型网站架构1--演化

1. 特点

特点	Challenge
高并发，大流量 , 高可用	分布式应用，需保证不宕机，提供稳定服务，安全
海量数据	需要大量服务器，分布式存储，计算
网络情况复杂	需要解决全球各地，国内各运营商网络的差异和时延安全环境恶劣
需求变更快，发布频繁	需自动化代码管理，测试，部署，发布

网站渐进式发展，业务驱动技术 。

---

2. 架构演变历程

大致分为以下6步:

1. 物理分离webserver、数据库和文件
2. 增加缓存
3. 使用应用服务器集群
4. 使用数据库集群
5. 反向代理+CDN加速响应
6. 拆分业务+廉价存储+统一的数据访问模块

step 1：物理分离webserver、数据库和文件

1 物力隔离.png
step 2：增加缓存
Motivation：
a.访问数据库的操作太多，数据库连接资源紧张激烈，又不能开太多，否则数据库机器压力会很大。
b.二八定律，80%的业务集中访问20%的数据。
缓存分类：
缓存在应用服务器本地缓存 VS 远程分布式缓存
缓存内容：
a. 采用 squid 等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存
b. 采用ESI来做动态页面中相对静态的片段部分的缓存。
c. 重复获取的数据信息缓存，如用户信息等 2 增加缓存.png

step 3： 使用应用服务器集群
** Motivation：
a.提高可用性，避免单台宕机
b.webServer已经成为性能瓶颈
c.提高可扩展性，所以不采取获得更强服务器策略
** 挑战
![Uploading webserver集群_348402.png . . .]
a. 如何让访问分配到这两台机器上，考虑方案负载均衡(Apache自带的负载均衡方案，或LVS这类的软件负载均衡方案)
b. 如何保持状态信息的同步，例如用户session等。考虑的方案写入数据库、写入存储、cookie或同步session信息等机制等；

3 增加webServer+负载均衡.png
step 4： 使用数据集群

方式	Motivation	challenge
分库，分表	a.数据库连接的资源竞争非常激烈，确无法进行分布式式部署 b.表中数据越来越多，增删改查的开销也会越来越大	a. 事务造成的性能问题 b.跨库跨表的join问题 c.额外的数据管理负担和数据运算压力
主从热备，读写分离	a. 缓存没有命中的情况下，数据库负载成为瓶颈 b.主从热备是因为需要一个简单的协议保证“一致性”	a. 主从一致性 b. 对应用保持透明性
分布式缓存，分布式数据库，分布式文件系统	a. 多备份分担压力 b.避免单点问题 ，更倾向于选择分表分库	数据分布和查找协议，数据一致性问题。

辅助增加模块：数据库访问管理模块，原因：需要通用的框架来实现分库分表的数据访问

4 数据集群.png

step 5： 反向代理+CDN加速响应
Motivation：访问延迟和用户流失率成正比。
相同点：a，基本原理都是缓存，目的都是把数据尽早返回给用户，并且减轻后端服务器压力。

区别：
CDN：从距离自己最近的网络提供商机房获取数据。
反向代理：部署在数据中心机房，用户请求到达之后首先安防服务的是反向代理服务器，如果命中，直接返回。

5. 反向代理+CDN加速响应.png

step 6： 拆分业务+廉价存储+统一的数据访问模块
（1） 业务拆分：
Motivation：应用场景复杂，server压力大，因此分为治之。 模块与模块之间的通信方式：超链接+消息队列+访问同一个数据存储系统（最常见）
分治的原则：提取可复用业务，拆分松耦合的业务
challenge：
a：需要提供一个高性能、稳定的通信框架，并且需要支持多种不同的通信和远程调用方式；
b：需要进行业务的整理和系统依赖关系的控制等；
c：如何运维（依赖管理、运行状况管理、错误追踪、调优、监控和报警等）好这个庞大的分布式应用。

（2） 廉价存储：
BigTable：分布式数据存储系统，用来处理海量的数据的一种非关系型的数据库
NoSQL：关系型数据面临的挑战，a：事务导致其在分布式系统中性能很低。b: 联表，需要在不同服务器中收集数据，效率低，相反实践证明，冗余带来的收益高于成本。性能：B树更新操作性能不如LSM树
（3）统一的数据访问模块：

6 拆分业务+廉价存储+统一的数据访问模块.png

References

[1] http://www.blogjava.net/BlueDavy/archive/2008/09/03/226749.html
[2] 大型网站技术架构: 核心原理与案例分析[M]. 电子工业出版社, 2013.