大型Web网站架构演变

前言

我们以Java Web为例，来搭建一个简单的电商系统，看看这个系统可以如何一步步演变 该系统具备的功能：

   用户模块：用户注册和管理
   商品模块：商品展示和管理
   交易模块：创建交易和管理

不同阶段

阶段一、单机构建网站

网站的初期，我们经常会在单机上跑我们所有的程序和软件。此时我们使用一个容器，如Tomcat、Jetty、Jboss，然后直接使用JSP/Servlet技术，或者使用一些开源的框架如Maven + Spring + Struts + Hibernate、Maven + Spring + Spring MVC + Mybatis。最后再选择一个数据库管理系统来存储数据，如MySQL、SqlServer、Oracle，然后通过JDBC进行数据库的连接和操作。

把以上的所有软件包括数据库、应用程序都装载同一台机器上，应用跑起来了，也算是一个小系统了。此时系统结果如下：

阶段二、应用服务器与数据库分离

随着网站的上线，访问量逐步上升，服务器的负载慢慢提高，在服务器还没有超载的时候，我们应该就要做好准备，提升网站的负载能力。假如我们代码层面已难以优化，在不提高单台机器的性能的情况下，采用增加机器是一个不错的方式，不仅可以有效地提高系统的负载能力，而且性价比高。

增加的机器用来做什么呢？此时我们可以把数据库服务器和Web服务器拆分开来，这样不仅提高了单台机器的负载能力，也提高了容灾能力。

应用服务器与数据库分开后的架构如下图所示：

阶段三、应用服务器集群

随着访问量继续增加，单台应用服务器已经无法满足需求了。在假设数据库服务器没有压力的情况下，我们可以把应用服务器从一台变成了两台甚至多台，把用户的请求分散到不同的服务器中，从而提高负载能力。而多台应用服务器之间没有直接的交互，他们都是依赖数据库各自对外提供服务。著名的做故障切换的软件有KeepAlived，KeepAlived是一个类似于Layer3、4、7交换机制的软件，他不是某个具体软件故障切换的专属品，而是可以适用于各种软件的一款产品。KeepAlived配合上ipvsadm又可以做负载均衡，可谓是神器。

我们以增加了一台应用服务器为例，增加后的系统结构图如下：

系统演变到这里，将会出现下面四个问题：

   用户的请求由谁来转发到到具体的应用服务器？
   有那些转发的算法和策略可以使用？
   应用服务器如何返回用户的请求？
   用户如果每次访问到的服务器不一样，那么如何维护session的一致性？

参考文档

[1] https://www.jianshu.com/p/5a67d789216e

阶段三 应用服务器集群

负载均衡

1. HTTP 重定向（重点）

2.DNS域名负载均衡

3.反向代理服务器（重点）

4.IP层负载均衡（重点）

5.数据链路层负载均衡

集群调度转发算法

(学生要了解，重点了解前6种算法，后面几种用的较少)

1. rr轮询调度算法

2. wrr加权调度算法

3. sh原地址散列算法

（同一个用户访问请求都到一个服务器上）

  解决session

4. dh目标地址散列算法

原理同上

5. lc最少连接算法

6. wlc加权最少连接算法

。。。

集群请求返回模式问题

1. NAT

2. DR

3. TUN

Session一致性问题

1. Session Sticky

2. Session Replication

3.Session数据集中存储

4、Cookie Base

考点：

Nginx目前支持的负载均衡算法有wrr、sh（支持一致性哈希）、fair（lc）。但Nginx作为均衡器的话，还可以一同作为静态资源服务器。

Keepalived + ipvsadm比较强大，目前支持的算法有：rr、wrr、lc、wlc、lblc、sh、dh

Keepalived支持集群模式有：NAT、DR、TUN

Nginx本身并没有提供session同步的解决方案，而Apache则提供了session共享的支持。

上图可以横向迅速扩展

应用：电商购物，视频点播