Web网站架构演变之路，2024年“金三银四”来袭

---

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

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

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

阶段三、应用服务器集群

---

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

多台应用服务器之间没有直接的交互，他们都是依赖数据库各自对外提供服务。著名的做故障切换的软件有keepalived，keepalived是一个类似于layer3、4、7交换机制的软件，他不是某个具体软件故障切换的专属品，而是可以适用于各种软件的一款产品。keepalived配合上ipvsadm又可以做负载均衡，可谓是神器。

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

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

• 用户的请求由谁来转发到到具体的应用服务器

• 有什么转发的算法

• 应用服务器如何返回用户的请求

• 用户如果每次访问到的服务器不一样，那么如何维护session的一致性

解决方案：

• 第一个问题即是负载均衡的问题，一般有5种解决方案：

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

优点：简单。

缺点：性能较差。

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

优点：交给DNS，不用我们去维护负载均衡服务器。

缺点：当一个应用服务器挂了，不能及时通知DNS，而且DNS负载均衡的控制权在域名服务商那里，网站无法做更多的改善和更强大的管理。

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

优点：部署简单。

缺点：代理服务器可能成为性能的瓶颈，特别是一次上传非常大的文件。

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

优点：性能更好。

缺点：负载均衡器的宽带成为瓶颈。

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

• 第二个问题即是集群调度算法问题，常见的调度算法有以下10种：

• rr 轮询调度算法。顾名思义，轮询分发请求。

优点：实现简单

缺点：不考虑每台服务器的处理能力

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

优点：考虑了服务器处理能力的不同

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

• dh 目标地址散列：同上，只是现在用提取的是目标地址的IP来做哈希。

优点：以上两种算法都能实现同一个用户访问同一个服务器。

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

优点：使得集群中各个服务器的负载更加均匀。

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

优点：可以根据服务器的能力分配请求。

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

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

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

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

• 第三个问题是集群模式问题，一般3种解决方案：

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

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

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

• 第四个问题是session问题，一般有以下4种解决方案：

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

优点：实现简单。

缺点：应用服务器重启则session消失。

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

优点：减轻负载均衡服务器的压力，不需要实现ip_hasp算法来转发请求。

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

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

优点：相比session replication的方案，集群间对于宽带和内存的压力减少了很多。

缺点：需要维护存储session的数据库。

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

优点：实现简单，基本免维护。

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

值得一提的是：

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

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

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

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

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

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

---

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

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

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

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

• 主从数据库之间数据同步问题

• 应用对于数据源的选择问题

解决问题方案：

• 我们可以使用MYSQL自带的master+slave的方式实现主从复制。

• 采用第三方数据库中间件，例如mycat。mycat是从cobar发展而来的，而cobar是阿里开源的数据库中间件，后来停止开发。mycat是国内比较好的mysql开源数据库分库分表中间件。

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

---

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

搜索引擎具有以下优点：

• 它能够大大提高查询速度。

引入搜索引擎后也会带来以下的开销：

• 带来大量的维护工作，我们需要自己实现索引的构建过程，设计全量/增加的构建方式来应对非实时与实时的查询需求。

• 需要维护搜索引擎集群

• 搜索引擎并不能替代数据库，他解决了某些场景下的“读”的问题，是否引入搜索引擎，需要综合考虑整个系统的需求。

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

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

---

1、后台应用层和数据库层的缓存

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上前端开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024c （备注前端）

前端框架

前端框架太多了，真的学不动了，别慌，其实对于前端的三大马车，Angular、React、Vue 只要把其中一种框架学明白，底层原理实现，其他两个学起来不会很吃力，这也取决于你以后就职的公司要求你会哪一个框架了，当然，会的越多越好，但是往往每个人的时间是有限的，对于自学的学生，或者即将面试找工作的人，当然要选择一门框架深挖原理。

以 Vue 为例，我整理了如下的面试题。

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

学生，或者即将面试找工作的人，当然要选择一门框架深挖原理。

以 Vue 为例，我整理了如下的面试题。

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-GQS8xRON-1712539395591)]