大型网站的架构演进

1 两台服务器

数据库和应用程序，分别在一台机器上。应用层序通过JDBC协议和数据库服务器通讯。

访问量增加，系统需要向前演进。（暂时不考虑，机器和软件层面的优化）

2 应用服务器负载告警，应用服务器走向集群

应用服务器压力变大时，根据对应用的检测结果，可以针对性优化。这里介绍把应用从单机变为集群。

2.1 遇到两个问题

•  应用服务器有两台，用户该访问哪台？
•  session的问题

2.1.1 在应用服务器前，引负载均衡服务器

2.1.2 session会保存在单机上。

三个解决方案：

session sticky: 配置负载均衡服务器，同样的session标识，访问同一台服务器

缺点：负载均衡服务器，变成来了一个有状态的节点，保存着session和服务器的映射。

session replication:将session对象同步到每台服务器

缺点：用户量变大，服务器变多时，内存开销变大，网络开销变大

session数据集中存储：把session存在同一个地方

        缺点：session数据服务器出问题，影响所有应用

cookie based:将session放在cookie

缺点：1.cookie长度受限制 2.session外部传输不安全 3. 消耗带宽 4.性能

3 读写分离

3.1 数据库作为读库

数据量和访问量在增加。对于大型网站，读多写少。

缺点：1.延迟

           2.写到主库，读到备库，事务里都到主库

解决延迟：mysql5.5以后，采用semi-sync

3.2 搜索引擎

lucence

3.3 缓存

缓解数据库读压力

key-value

先访问缓存，再数据库

清楚冷门数据

缓存命中率

扩容，缩蓉

3.4 distributed storage 分布式存储系统

单机数据库，强的单机事务支持

分布式文件系统，分布式key-value系统，分布式数据库系统

4 数据库拆分

4.1 专库专用，数据垂直拆分

分布式事务；去掉事务。

4.2 水平拆分

垂直拆分，水平拆分， 读写分离

sql路由

主键重复

分页

 

5 应用面临的新挑战

5.1 某应用变大

存在user共享代码，不容易维护

直接访问存储层，希望进一步简化

6 走服务化路

web系统 业务服务 数据系统

远程调用 集中代码 web负责浏览器交互 业务业务逻辑和负责访问数据层

不通团队维护相应模块

消息中间件 message oriented middleware