Web网站架构演变趋势

1、1 Web 网站架构演变趋势 2 目录 前言 . 3 阶段一、单机构建网站 . 3 阶段二、应用服务器与数据库分离 . 4 阶段三、应用服务器集群. 5 阶段四、数据库读写分离化. 11 阶段五、用搜索引擎缓解读库的压力 . 13 阶段六、用缓存缓解读库的压力. 14 阶段七、数据库水平拆分与垂直拆分 . 17 阶段八、应用的拆分 . 20 阶段九、引入消息中间件. 23 十、总结 . 24 3 前言 我们以 javaweb为例，来搭建一个简单的电商系统，看看这个系统可以如何一步步演变。 该系统具备的功能： 用户模块：用户注册和管理 商品模块：商品展示和管理 交易模块：创建交易和管理 阶段一、单机构建网站 网站的初期，我们经常会在单机上跑我们所有的程序和软件。此时我们使用一个容器， 如 tomcat 、 jetty 、jboos ，然后直接使用JSP/servlet技术，或者使用一些开源的框架如 maven+spring+struct+hibernate、maven+spring+springmvc+mybatis；最后再选择一个数据 库管理系统来存储数据，如mysql 、sqlser

2、ver 、oracle ，然后通过 JDBC 进行数据库的连接和操作。 把以上的所有软件都装载同一台机器上，应用跑起来了，也算是一个小系统了。此时系统结果如 下： 4 阶段二、应用服务器与数据库分离 随着网站的上线，访问量逐步上升，服务器的负载慢慢提高，在服务器还没有超载的时候，我们 应该就要做好准备，提升网站的负载能力。假如我们代码层面已难以优化，在不提高单台机器的性能 的情况下，增加机器是一个不错的方式，不仅可以有效地提高系统的负载能力，而且性价比高。 增加的机器用来做什么呢？此时我们可以把数据库，web 服务器拆分开来， 这样不仅提高了单台 机器的负载能力，也提高了容灾能力。 应用服务器与数据库分开后的架构如下图所示： 5 阶段三、应用服务器集群 随着访问量继续增加，单台应用服务器已经无法满足需求了。在假设数据库服务器没有压力的情 况下，我们可以把应用服务器从一台变成了两台甚至多台，把用户的请求分散到不同的服务器中，从 而提高负载能力。多台应用服务器之间没有直接的交互，他们都是依赖数据库各自对外提供服务。著 名的做故障切换的软件有keepalived，keepalived是一个类

3、似于layer3 、4、7 交换机制的软件， 他不是某个具体软件故障切换的专属品，而是可以适用于各种软件的一款产品。keepalived配合上 ipvsadm又可以做负载均衡，可谓是神器。 我们以增加了一台应用服务器为例，增加后的系统结构图如下： 6 系统演变到这里， 将会出现下面四 个问题 ： 1.用户的请求由谁来转发到到具体的应用服务器 2.有什么转发的算法 3.应用服务器如何返回用户的请求 4.用户如果每次访问到的服务器不一样，那么如何维护session 的一致性 我们来看看解决问题的方案： 1、第一个问题即是负载均衡的问题，一般有5 种解决方案： 1、http重定向 。HTTP 重定向就是应用层的请求转发。用户的请求其实已经到了HTTP 重定向负 载均衡服务器，服务器根据算法要求用户重定向，用户收到重定向请求后，再次请求真正的集群 优点：简单。 缺点：性能较差。 2、DNS 域名解析负载均衡。DNS 域名解析负载均衡就是在用户请求DNS 服务器，获取域名对应的 IP 地址时， DNS 服务器直接给出负载均衡后的服务器IP。 7 优点：交给DNS ，不用我们去维护负载均衡服务器。

4、 缺点：当一个应用服务器挂了，不能及时通知DNS ，而且 DNS 负载均衡的控制权在域名服务商那 里，网站无法做更多的改善和更强大的管理。 3、反向代理服务器 。在用户的请求到达反向代理服务器时（已经到达网站机房），由反向代理服务 器根据算法转发到具体的服务器。常用的apache ，nginx 都可以充当反向代理服务器。 优点：部署简单。 缺点：代理服务器可能成为性能的瓶颈，特别是一次上传大文件。 4、IP 层负载均衡 。在请求到达负载均衡器后，负载均衡器通过修改请求的目的IP 地址，从而实现请 求的转发，做到负载均衡。 优点：性能更好。 缺点：负载均衡器的宽带成为瓶颈。 5、数据链路层负载均衡。在请求到达负载均衡器后，负载均衡器通过修改请求的mac 地址，从而做 到负载均衡，与IP 负载均衡不一样的是，当请求访问完服务器之后，直接返回客户。而无需再经过 负载均衡器。 2、第二个问题即是集群调度算法问题，常见的调度算法有10 种。 1、rr 轮询调度算法 。顾名思义，轮询分发请求。 优点：实现简单 缺点：不考虑每台服务器的处理能力 8 2、 wrr 加权调度算法 。 我们给每个服务器设

5、置权值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 算法。我们想一下什么情况下才能“永不排队”，那就是服务器的 连接数为

6、0 的时候，那么假如有服务器连接数为0，均衡器直接把请求转发给它，无需经过sed 的计 算。 9、LBLC 基于局部性的最少连接。均衡器根据请求的目的IP 地址，找出该IP 地址最近被使用的 服务器，把请求转发之，若该服务器超载，最采用最少连接数算法。 9 10、LBLCR 带复制的基于局部性的最少连接。均衡器根据请求的目的IP 地址，找出该IP 地址最 近使用的“服务器组”，注意，并不是具体某个服务器，然后采用最少连接数从该组中挑出具体的某 台服务器出来，把请求转发之。若该服务器超载，那么根据最少连接数算法，在集群的非本服务器组 的服务器中，找出一台服务器出来，加入本服务器组，然后把请求转发之。 3、第三个问题是集群模式问题，一般3 种解决方案： 1、NAT ：负载均衡器接收用户的请求，转发给具体服务器，服务器处理完请求返回给均衡器，均 衡器再重新返回给用户。 2、DR ：负载均衡器接收用户的请求，转发给具体服务器，服务器出来玩请求后直接返回给用户。 需要系统支持IP Tunneling协议，难以跨平台。 3、TUN ：同上，但无需IP Tunneling协议，跨平台性好，大部分系统都可以支持。 4、第四个问题是session 问题，一般有4 种解决方案： 1、Session Sticky。session sticky就是把同一个用户在某一个会话中的请求，都分配到固定 的某一台服务器中，这样我们就不需要解决跨服务器的session 问题了，常见的算法有ip_hash 法， 即上面提到的两种散列算法。 优点：实现简单。 缺点：应用服务器重启则session 消失。 2、Session Replication。session replication就是在集群中复制session ，使得每个服务器都 保存有全部用户的session 数据。 10 优点：减轻负载均衡服务器的压力，不需要要实现ip_hasp 算法来转发请求。 缺点：复制时宽带开销大，访问量大的话

《Web网站架构演变趋势》由会员1473****695分享，可在线阅读，更多相关《Web网站架构演变趋势》请在金锄头文库上搜索。