一、总体架构图
1.1 初始阶段
这时应用程序、数据库、文件等所有的资源都在一台服务器上
1.2 服务器分离
随着网站业务的发展，一台服务器逐渐不能满足需求：越来越多的用户访问导致性能越来越差，越来越多的数据导致存储空间不足。这是就需要将应用和数据分离。
1.3 应用垂直切分
随着网站业务的发展，应用服务器处理不过来， 需要把业务拆分成多个小业务，分别交给不同的应用程序处理， 业务直接通过kafka等消息中间件等相连,这样主业务处理速度加快.
1.4 应用的水平切分
使用集群是完整解决高并发、海量数据问题的常用手段。当一台服务器的处理能力，存储空间不足时，通过增加一台服务器分担原有的服务器的访问及存储压力。通过负载均衡调度服务器，可将来自用户浏览器的访问请求分发到应用服务器的集群中的任何一台服务器上，如果有更多的用户，就在集群中假如更多的应用服务器，使应用服务器的负载压力不再成为整个网站的瓶颈。
1.5 数据库读写分离
利用从服务器分担压力， 从而提高服务器处理性能。
1.6 缓存
利用缓存技术， 不用每次去数据库查询数据，提高应用程序的处理速度。且大大减少了数据库服务器的压力。
1.7 数据库分库分表
利用分库分表技术， 把数据库访问均匀分布到数据库集群中，提高数据库性能。
1.8 分布式数据库
当数据库服务器表很大时候， 维护分库分表比较困难，可以考虑分布式数据库。
1.9 NoSQL和搜索引擎
有些数据需要查询速度比较快且查询逻辑比较简单可以考虑nosql数据库。
1.10 cdn和反向代理
DN解决的是如何将数据快速可靠从源站传递到用户的问题。用户获取数据时，不需要直接从源站获取，通过CDN对于数据的分发，用户可以从一个较优的服务器获取数据，从而达到快速访问，并减少源站负载压力的目的。
1.11 微服务器架构
优势就是分解巨大单体式应用为多个服务方法解决了复杂性问题，提高了开发效率和部署效率。 但是因为微服务框架一般都是分布式方式，会带来分布式一致性等问题。
总结： 要提高性能，主要方法就是增加模块。增加的模块与原来相同， 就要负载均衡；不同就要分担不同的任务。
二、各模块补充说明
1.3 应用垂直切分。一般比较常见的是通过消息中间件来串联应用。 一个应用处理完之后生产消息到消息中间件，另外一个应用从消息中间件提取消息， 消费消息。
1.4 应用的水平切分。应用水平切分之后， 需要增加一个负载均衡器来分配任务。 负载均衡器在等到所有应用之后会采用一些策略（轮询，加权，负载能力，hash）等分配任务给应用。
1.6 缓存是一个抽象的概念， 其实只要能存储数据， 且查询速度快都可以看做是缓存。 缓存要考虑什么时候加载， 什么时候过期，缓存失效怎么处理。
1.7 分库分表需要考虑当数据库数量变化时候， 缓存一致性问题。
三、参考
https://blog.csdn.net/zhaoxuejie/article/details/46347063