大型Web网站架构演变之9大阶段

发布时间：2025-11-04 23:09:25 来源：创站工坊 作者：数据库

 前言

我们以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又可以做负载均衡，可谓是神器。

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

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

针对以上问题，常用的云服务器解决方案如下：

1、负载均衡的问题

一般以下有5种解决方案：

1）、HTTP重定向

HTTP重定向就是应用层的请求转发。用户的请求其实已经到了HTTP重定向负载均衡服务器，服务器根据算法要求用户重定向，用户收到重定向请求后，再次请求真正的集群

2）、DNS域名解析负载均衡

DNS域名解析负载均衡就是在用户请求DNS服务器，获取域名对应的IP地址时，DNS服务器直接给出负载均衡后的服务器IP。

3）、反向代理服务器

在用户的请求到达反向代理服务器时(已经到达网站机房)，由反向代理服务器根据算法转发到具体的服务器。常用的Apache，Nginx都可以充当反向代理服务器。

4）、IP层负载均衡

在请求到达负载均衡器后，负载均衡器通过修改请求的目的IP地址，从而实现请求的转发，做到负载均衡。

5）、数据链路层负载均衡

在请求到达负载均衡器后，负载均衡器通过修改请求的MAC地址，从而做到负载均衡，与IP负载均衡不一样的是，当请求访问完服务器之后，直接返回客户。而无需再经过负载均衡器。

2、集群调度转发算法

1）、rr轮询调度算法

顾名思义，轮询分发请求。

2）、wrr加权调度算法

我们给每个服务器设置权值Weight，负载均衡调度器根据权值调度服务器，服务器被调用的次数跟权值成正比。

3）、sh原地址散列算法

提取用户IP，根据散列函数得出一个key，再根据静态映射表，查处对应的value，即目标服务器IP。过目标机器超负荷，则返回空。

4）、dh目标地址散列算法

原理同上，只是现在提取的是目标地址的IP来做哈希。

5）、lc最少连接算法

优先把请求转发给连接数少的服务器。

6）、wlc加权最少连接算法

在lc的基础上，为每台服务器加上权值。算法为：(活动连接数 * 256 + 非活动连接数) ÷ 权重，计算出来的值小的服务器优先被选择。

7）、sed最短期望延迟算法

其实sed跟wlc类似，区别是不考虑非活动连接数。算法为：(活动连接数 +1 ) * 256 ÷ 权重，同样计算出来的值小的服务器优先被选择。

8)、nq永不排队算法

改进的sed算法。我们想一下什么情况下才能“永不排队”，那就是服务器的连接数为0的时候，那么假如有服务器连接数为0，均衡器直接把请求转发给它，无需经过sed的计算。

9)、LBLC基于局部性最少连接算法

负载均衡器根据请求的目的IP地址，找出该IP地址最近被使用的服务器，把请求转发之。若该服务器超载，最采用最少连接数算法。

10)、LBLCR带复制的基于局部性最少连接算法

负载均衡器根据请求的目的IP地址，找出该IP地址最近使用的“服务器组”，注意，并不是具体某个服务器，然后采用最少连接数从该组中挑出具体的某台服务器出来，把请求转发之。若该服务器超载，那么根据最少连接数算法，在集群的非本服务器组的服务器中，找出一台服务器出来，加入本服务器组，然后把请求转发。

3、集群请求返回模式问题

1)、NAT

负载均衡器接收用户的请求，转发给具体服务器，服务器处理完请求返回给均衡器，均衡器再重新返回给用户。

2)、DR

负载均衡器接收用户的请求，转发给具体服务器，服务器出来玩请求后直接返回给用户。需要系统支持IP Tunneling协议，难以跨平台。

3)、TUN

同上，但无需IP Tunneling协议，跨平台性好，大部分系统都可以支持。

4、集群Session一致性问题

1)、Session

Session  就是把同一个用户在某一个会话中的请求，都分配到固定的某一台服务器中，这样我们就不需要解决跨服务器的session问题了，常见的算法有ip_hash算法，即上面提到的两种散列算法。

2)、Session Replication

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

3)、Session数据集中存储

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

4)、Cookie Base

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

值得一提的是：

解决了以上的问题之后，系统的结构如下：

阶段四、数据库读写分离化

上面我们总是假设数据库负载正常，但随着访问量的的提高，数据库的负载也在慢慢增大。那么可能有人马上就想到跟应用服务器一样，把数据库一份为二再负载均衡即可。

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

读写分离后的系统结构如下：

这个结构变化后也会带来两个问题：

解决方案：

阶段五、用搜索引擎缓解读库的压力

数据库做读库的话，常常对模糊查找力不从心，即使做了读写分离，这个问题还未能解决。以我们所举的交易网站为例，发布的商品存储在数据库中，用户最常使用的功能就是查找商品，尤其是根据商品的标题来查找对应的商品。对于这种需求，一般我们都是通过like功能来实现的，但是这种方式的代价非常大，而且结果非常不准确。此时我们可以使用搜索引擎的倒排索引来完成。

搜索引擎具有的优点：它能够大大提高查询速度和搜索准确性。

引入搜索引擎的开销

搜索引擎并不能替代数据库，它解决了某些场景下的精准、快速、高效的“读”操作，是否引入搜索引擎，需要综合考虑整个系统的需求。

引入搜索引擎后的系统结构如下：

阶段六、用缓存缓解读库的压力

常用的缓存机制包括页面级缓存、应用数据缓存和数据库缓存。

应用层和数据库层的缓存

随着访问量的增加，逐渐出现了许多用户访问同一部分热门内容的情况，对于这些比较热门的内容，没必要每次都从数据库读取。我们可以使用缓存技术，例如可以使用Google的开源缓存技术Guava或者使用Memecahed作为应用层的缓存，也可以使用Redis作为数据库层的缓存。

另外，在某些场景下，关系型数据库并不是很适合，例如我想做一个“每日输入密码错误次数限制”的功能，思路大概是在用户登录时，如果登录错误，则记录下该用户的IP和错误次数，那么这个数据要放在哪里呢?假如放在内存中，那么显然会占用太大的内容;假如放在关系型数据库中，那么既要建立数据库表，还要简历对应的Java bean，还要写SQL等等。而分析一下我们要存储的数据，无非就是类似{ip:errorNumber}这样的key:value数据。对于这种数据，我们可以用NOSQL数据库来代替传统的关系型数据库。

页面缓存

除了数据缓存，还有页面缓存。比如使用HTML5的localstroage或者Cookie。除了页面缓存带来的性能提升外，对于并发访问且页面置换频率小的页面，应尽量使用页面静态化技术。

值得一提的是：

缓存集群的调度算法不同与上面提到的应用服务器和数据库。采用一致性哈希算，这样才能提高结果的概率。

加入缓存后的系统结构如下：

阶段七、数据库水平拆分与垂直拆分

我们的网站演进到现在，交易、商品、用户的数据都还在同一个数据库中。尽管采取了增加缓存和读写分离的方式，但随着数据库的压力继续增加，数据库数据量的瓶颈越来越突出，此时，我们可以有数据垂直拆分和水平拆分两种选择。

数据垂直拆分

垂直拆分的意思是把数据库中不同的业务数据拆分到不同的数据库中，结合现在的例子，就是把交易、商品、用户的数据分开。

优点：

缺点：

问题：

解决问题方案：

数据垂直拆分后的结构如下：

数据水平拆分

数据水平拆分就是把同一个表中的数据拆分到两个甚至多个数据库中。产生数据水平拆分的原因是某个业务的数据量或者更新量到达了单个数据库的瓶颈，这时就可以把这个表拆分到两个或更多个数据库中。

优点：

问题：

解决问题方案：

数据水平拆分后的结构如下：

阶段八、应用的拆分

按微服务拆分应用

随着业务的发展，业务越来越多，应用越来越大。我们需要考虑如何避免让应用越来越臃肿。这就需要把应用拆开，从一个应用变为俩个甚至更多。还是以我们上面的例子，我们可以把用户、商品、交易拆分开。变成“用户、商品”和“用户，交易”两个子系统。

拆分后的结构：

问题：

这样拆分后，可能会有一些相同的代码，如用户相关的代码，商品和交易都需要用户信息，所以在两个系统中都保留差不多的操作用户信息的代码。如何保证这些代码可以复用是一个需要解决的问题。

解决问题：

通过走服务化SOA的路线来解决频繁公共的服务。

走SOA服务化治理道路

为了解决上面拆分应用后所出现的问题，我们把公共的服务拆分出来，形成一种服务化的模式，简称SOA。

采用服务化之后的系统结构：

优点：

问题：

解决方法：

阶段九、引入消息中间件

随着网站的继续发展，的系统中可能出现不同语言开发的子模块和部署在不同平台的子系统。此时我们需要一个平台来传递可靠的，与平台和语言无关的数据，并且能够把负载均衡透明化，能在调用过程中收集并分析调用数据，推测出网站的访问增长率等等一系列需求，对于网站应该如何成长做出预测。开源消息中间件有阿里的Dubbo，可以搭配Google开源的分布式程序协调服务Zookeeper实现服务器的注册与发现。

引入消息中间件后的结构：

总结

以上的演变过程只是一个例子，并不适合所有的网站，实际中网站演进过程与自身业务和不同遇到的问题有密切的关系，没有固定的模式。只有认真的分析和不断地探究，才能发现适合自己网站的架构。

相关文章