1. 项目初期
2. 服务器分离
以上的服务分离架构，即使文件服务crash 了，但是application server 和 Database Server 继续可以访问运行
3. 基于并发访问越来越高，数据库压力越来越大，引入分布式缓存
80%的数据访问基于20%的业务数据上，28原则
分布式缓存思考
（1）.那种业务数据适合远程分布式缓存
（2）.那种业务数据适合本地缓存
（3）.分布式缓存扩容的时候存在的问题，如何解决，算法有哪些
（4）.基于这种架构，我们需要解决的问题
4. QPS 访问越来越高，Application Server 将会出现瓶颈，增加负载均衡调度服务器
思考的问题
（1）.负载均衡的调度策略有哪些，各有什么优缺点，例如轮训（实现简单，不考虑服务器的处理能力），权重（考虑服务器处理能力），地址散列（原IP地址散列，目标地址散列， 实现同一个用户访问同一个服务器）
（2）.假设一个场景，一个用户第一次访问A 服务器，session信息被存储到A服务器上，但是由于负载均衡服务器，同一个用户第二次访问的时候，访问了B服务器，但是B服务器上没有用户的session信息，因此解决session管理的问题
上图session 管理缺点
（1）.某一个application server 重启了，这时候session 全部消失
（2）.第二种session解决方案，session copy
（1）. 解决session共享问题
（2）.缺点Cookie长度是有限制的
（3）.Cookie 保存在浏览器上，不安全
因此出现了一下方案
缺点
（1）.Session server 是单点，如何保证系统正常的运行
（2）.我们可以考虑session server 集群
（3）.适用于Web服务器session 服务器多的场景
5. 当用户量达到一定数量时，数据库就会出现瓶颈，如何解决，数据库的读写分离
应用接入多数据源
应用程序也应该需要相应的变化
data access module 数据写入模块，是开发人员不知道读写分离的存在，多数据源对业务代码无侵入性
当数据的IO非常大的时候，我们的主库与附库在跨机房传输的时候，又是一个要解决的问题？
6. 增加CDN 与反向代理服务器，可以很好的解决不同的地区访问速度的问题
反向代理可以缓存用户数据，这个时候我们的文件服务器可能会出现了瓶颈
7. 文件服务器分布式集群
分布式文件系统
（1）.是否需要备份服务器
8. 这个时候，数据库又出现瓶颈，专库专用的原则（micro service的设计理念），进行数据的垂直拆分，解决写数据并发量大的问题
问题：
（1）. 跨数据库的事务
（2）.可以使用分布式事务
（3）.或者去掉事务，或者不使用强制性事务
随着数据量，访问量的变大，我们每个业务的数据量已经达到单个数据库的瓶颈，这个时候进行数据库水平拆分
解决单数据库的问题
拆分的时候注意点：
（1）. SQL的路由问题
（2）.既然user表进行了分库，但是面临的另外一个涉及分页的问题
9. 当解决这以上问题之后，我们的搜索又会出现瓶颈，把应用服务器的搜索功能独立出来，架设一个搜索引擎服务器
data access module 链接着数据库，搜索引擎，NoSQL Server
该架构也不是最后的架构，根据实际的业务来决定，例如以上的架构负载均衡服务器是一个单点，因此仍然可以继续提升优化空间