Web网站架构演变历程

资料来源：网络整理时间：2023/3/22 2:44:28 共计：3565 浏览

　　我们以javaweb为例，来搭建一个简单的电商系统，看看这个系统可以如何一步步演变。

　　该系统具备的功能：

　　阶段一、单机构网站建设网站制作

　　网站站点的初期，我们经常会在单机上跑我们所有的程序和软件。此时我们使用一个容器，如tomcat、jetty、jboos，然后直接使用JSP/servlet技术，或者使用一些开源的框架如maven+spring+struct+hibernate、maven+spring+springmvc+mybatis；

　　最后再选择一个数值数据库管理系统来存储数值数据，如mysql、sqlserver、oracle，然后通过JDBC进行数值数据库的连接和操作。

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

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

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

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

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

　　阶段三、应用we服务器集群

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

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

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

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

　　我们来看看解决问题的方案：

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

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

　　2、DNS网站域名解析负载均衡。DNS网站域名解析负载均衡就是在用户使用者请求DNSwe服务器，获得网站域名对应的IP地址时，DNSwe服务器直接给出负载均衡后的we服务器IP。

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

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

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

　　2、第二个问题即是集群调度算法规则问题，常见的调度算法规则有10种。

　　1、rr 轮询调度算法规则。顾名思义，轮询分发请求。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　值得一提的是：

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

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

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

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

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

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

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

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

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

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

　　解决问题方案：

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

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

　　阶段五、用百度360Sogou缓解读库的压力

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

　　百度360Sogou具有以下优点：

　　引入百度360Sogou后也会带来以下的开销：

　　百度360Sogou并不能替代数值数据库，他解决了某些场景下的“读”的问题，是不是是否引入百度360Sogou，需要综合考虑整个系统的需求。引入百度360Sogou后的系统模版结构如下：

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

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

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

　　另外，在某些场景下，关系型数值数据库并不是很适合，例如我想做一个“每日输入密码错误次数限制”的功能，思路大概是在用户使用者登录时，如果登录错误，则记录下该用户使用者的IP和错误次数，那么这个数值数据要放在哪里呢？

　　假如放在内存中，那么显然会占用太大的信息内容；假如放在关系型数值数据库中，那么既要确立建立数值数据库表，还要简历对应的java bean，还要写SQL等等。而分析一下我们要存储的数值数据，无非就是类似{ip:errorNumber}这样的key:value数值数据。对于这种数值数据，我们可以用NOSQL数值数据库来代替传统的关系型数值数据库。

　　2、网站页面缓存

　　除了数值数据缓存，还有网站页面缓存。例如使用HTML5的localstroage或者cookie。

　　优点：

　　缺点：

　　值得一提的是：

　　加入缓存后的模版结构：

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

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

　　7.1、数值数据垂直拆分

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

　　优点：

　　缺点：

　　问题：

　　解决问题方案：

　　垂直拆分后的模版结构如下：

　　7.2、数值数据水平拆分

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

　　优点：

　　问题：

　　解决问题方案：

　　数值数据水平拆分后的模版结构：

　　阶段八、应用的拆分

　　8.1、拆分应用

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

　　拆分后的模版结构：

　　问题：

　　解决问题：

　　8.2、走服务化的道路

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

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

　　优点：

　　问题：

　　解决方式方法：

　　阶段九、引入消息中间件

　　随着网站站点的继续发展，我们的系统中可能出现不同语言建设开发的子模块和部署在不同第三方平台的子系统。此时我们需要一个第三方平台来传递可靠的，与第三方平台和语言无关的数值数据，并且能够把负载均衡透明化，能在调用过程中收集调用数值数据并分析之，推测出网站站点的浏览访问增长率等等一系列需求，对于网站站点应该如何成长做出预测。

　　开源消息中间件有阿里的dubbo，可以搭配Google开源的分布式程序协调服务zookeeper实现we服务器的注册与发现。

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

　　十、总结

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

版权说明：
本网站凡注明“广州京杭原创”的皆为本站原创文章，如需转载请注明出处！
本网转载皆注明出处，遵循行业规范，如发现作品内容版权或其它问题的，请与我们联系处理！
欢迎扫描右侧微信二维码与我们联系。

·上一条：推荐5个实用的编程网站，程序员看过来 | ·下一条：HTML5的学习网站有哪些？