架构的演变

1.单机构建网站

一句话概括：一台机器上一个容器（jsp、servlet）+数据库

2.服务器集群

当访问量逐步上升，服务器的负载慢慢提高，单台计算机的处理能力有限。

应用服务器和数据库分离

应用服务器的集群

随着访问量继续增加，单台应用服务器已经无法满足需求了。在假设数据库服务器没有压力的情况下，我们可以把应用服务器从一台变成了两台甚至多台，把用户的请求分散到不同的服务器中，从而提高负载能力。多台应用服务器之间没有直接的交互，他们都是依赖数据库各自对外提供服务。

但是问题就来了：

2.1.如何均匀的将请求发送到应用服务器上？

负载均衡

反向代理服务器。在用户的请求到达反向代理服务器时（已经到达网站机房），由反向代理服务器根据算法转发到具体的服务器。常用的apache，nginx都可以充当反向代理服务器。
优点：部署简单。
缺点：代理服务器可能成为性能的瓶颈，特别是一次上传大文件。

负载均衡算法

轮询算法<br>随机

2.2.如果用户访问到不同的服务器上，session如何保持一致?

方案一：基于cookie

就是把session存在cookie中，有浏览器来告诉应用服务器我的session是什么，同样实现了session和应用服务器的解耦。

问题：cookie长度限制，安全性低，宽带消耗。

方案二：就是在集群中复制session，使得每个服务器都保存有全部用户的session数据。

问题：复制时宽带开销大，访问量大的话session占用内存大且浪费。

方案三：同一个用户在某一个会话中的请求，都分配到固定的某一台服务器中，这样我们就不需要解决跨服务器的session问题了

问题：没有真正的负载均衡，可能出现一个应用服务器的session都快挤爆了，但是一些应用服务器session却很轻松。

方案四：session数据集中存储就是利用数据库来存储session数据，实现了session和应用服务器的解耦。

3.读写分离

把数据库一份为二再负载均衡即可。但对于数据库来说，并没有那么简单。假如我们简单的把数据库一分为二，然后对于数据库的请求，分别负载到A机器和B机器，那么显而易见会造成两台数据库数据不统一的问题。那么对于这种情况，我们可以先考虑使用读写分离的方式。

3.1如何同步？

MYSQL自带的master+slave的方式实现主从复制。

复制的过程就是slave从master获取binary log然后执行。复制的过程是异步的，因此就存在延迟的现象。因此也只能保证最终一致性。

还是有问题：
master挂了怎么办？
双master

4.用缓存缓解读库的压力

对于一些频繁的数据，总是从数据库中读取，这无疑给数据库造成了很大的压力。如果在程序中缓存，那么造成代码耦合，难以重复利用以及难以统一管理。因此加入了缓存。

5.面向服务

随着业务的发展，业务越来越多，应用越来越大。我们需要考虑如何避免让应用越来越臃肿。这就需要把应用拆开，从一个应用变为俩个甚至更多。但是其中又有一些通用的业务服务，比如登录，因此我们就直接直接把服务剥离出来，然后让服务为web应用提供服务。而web应用只需要考虑调用服务，展示页面。

那么问题来了！！！

1.web应用如何调用服务，如何通信？
rpc
2.注册中心挂了怎么办？
zookeeper集群