查看“大型Web网站架构演变”的源代码
←
大型Web网站架构演变
跳转至:
导航
,
搜索
因为以下原因,您没有权限编辑本页:
您所请求的操作仅限于该用户组的用户使用:
用户
您可以查看与复制此页面的源代码。
==前言== 我们以Java Web为例,来搭建一个简单的电商系统,看看这个系统可以如何一步步演变 该系统具备的功能: 用户模块:用户注册和管理 商品模块:商品展示和管理 交易模块:创建交易和管理 ==阶段一、单机构建网站== 网站的初期,我们经常会在单机上跑我们所有的程序和软件。此时我们使用一个容器,如Tomcat、Jetty、Jboss,然后直接使用JSP/Servlet技术,或者使用一些开源的框架如Maven + Spring + Struts + Hibernate、Maven + Spring + Spring MVC + Mybatis。最后再选择一个数据库管理系统来存储数据,如MySQL、SqlServer、Oracle,然后通过JDBC进行数据库的连接和操作。 把以上的所有软件包括数据库、应用程序都装载同一台机器上,应用跑起来了,也算是一个小系统了。此时系统结果如下: [[文件:cloud1-8.png]] ==阶段二、应用服务器与数据库分离== 随着网站的上线,访问量逐步上升,服务器的负载慢慢提高,在服务器还没有超载的时候,我们应该就要做好准备,提升网站的负载能力。假如我们代码层面已难以优化,在不提高单台机器的性能的情况下,采用增加机器是一个不错的方式,不仅可以有效地提高系统的负载能力,而且性价比高。 增加的机器用来做什么呢?此时我们可以把数据库服务器和Web服务器拆分开来,这样不仅提高了单台机器的负载能力,也提高了容灾能力。 应用服务器与数据库分开后的架构如下图所示: [[文件:cloud1-9.png]] ==阶段三、应用服务器集群== 随着访问量继续增加,单台应用服务器已经无法满足需求了。在假设数据库服务器没有压力的情况下,我们可以把应用服务器从一台变成了两台甚至多台,把用户的请求分散到不同的服务器中,从而提高负载能力。而多台应用服务器之间没有直接的交互,他们都是依赖数据库各自对外提供服务。著名的做故障切换的软件有KeepAlived,KeepAlived是一个类似于Layer3、4、7交换机制的软件,他不是某个具体软件故障切换的专属品,而是可以适用于各种软件的一款产品。KeepAlived配合上ipvsadm又可以做负载均衡,可谓是神器。 我们以增加了一台应用服务器为例,增加后的系统结构图如下: [[文件:cloud1-10.png]] 系统演变到这里,将会出现下面四个问题: *用户的请求由谁来转发到到具体的应用服务器? *有那些转发的算法和策略可以使用? *应用服务器如何返回用户的请求? *用户如果每次访问到的服务器不一样,那么如何维护session的一致性? ===负载均衡=== ===HTTP 重定向(重点)==== HTTP重定向就是应用层的请求转发。用户的请求其实已经到了HTTP重定向负载均衡服务器,服务器根据算法要求用户重定向,用户收到重定向请求后,再次请求真正的集群 *优点:简单易用; *缺点:性能较差。 ====DNS域名负载均衡==== DNS域名解析负载均衡就是在用户请求DNS服务器,获取域名对应的IP地址时,DNS服务器直接给出负载均衡后的服务器IP。 *优点:交给DNS,不用我们去维护负载均衡服务器; *缺点:当一个应用服务器挂了,不能及时通知DNS,而且DNS负载均衡的控制权在域名服务商那里,网站无法做更多的改善和更强大的管理。 ====反向代理服务器(重点)==== 在用户的请求到达反向代理服务器时(已经到达网站机房),由反向代理服务器根据算法转发到具体的服务器。常用的Apache,Nginx都可以充当反向代理服务器。 *优点:部署简单; *缺点:代理服务器可能成为性能的瓶颈,特别是一次上传大文件。 ====IP层负载均衡(重点)==== 在请求到达负载均衡器后,负载均衡器通过修改请求的目的IP地址,从而实现请求的转发,做到负载均衡。 *优点:性能更好; *缺点:负载均衡器的宽带成为瓶颈。 ====数据链路层负载均衡==== 在请求到达负载均衡器后,负载均衡器通过修改请求的MAC地址,从而做到负载均衡,与IP负载均衡不一样的是,当请求访问完服务器之后,直接返回客户。而无需再经过负载均衡器。 ===集群调度转发算法=== (学生要了解,重点了解前6种算法,后面几种用的较少) ====rr轮询调度算法==== 顾名思义,轮询分发请求。 *优点:实现简单 *缺点:不考虑每台服务器的处理能力 ====wrr加权调度算法==== 我们给每个服务器设置权值Weight,负载均衡调度器根据权值调度服务器,服务器被调用的次数跟权值成正比。 优点:考虑了服务器处理能力的不同 ====sh原地址散列算法==== 提取用户IP,根据散列函数得出一个key,再根据静态映射表,查处对应的value,即目标服务器IP。过目标机器超负荷,则返回空。 优点:实现同一个用户访问同一个服务器, 解决了session 问题 ====dh目标地址散列算法==== 原理同上,只是现在提取的是目标地址的IP来做哈希。 优点:实现同一个用户访问同一个服务器。 ====lc最少连接算法==== 优先把请求转发给连接数少的服务器。 优点:使得集群中各个服务器的负载更加均匀。 ====wlc加权最少连接算法==== 在lc的基础上,为每台服务器加上权值。算法为:(活动连接数 * 256 + 非活动连接数) ÷ 权重,计算出来的值小的服务器优先被选择。 优点:可以根据服务器的能力分配请求。 。。。 ===集群请求返回模式问题=== ====NAT==== 负载均衡器接收用户的请求,转发给具体服务器,服务器处理完请求返回给均衡器,均衡器再重新返回给用户。 ====DR==== 负载均衡器接收用户的请求,转发给具体服务器,服务器出来玩请求后直接返回给用户。需要系统支持IP Tunneling协议,难以跨平台。 ====TUN==== 同上,但无需IP Tunneling协议,跨平台性好,大部分系统都可以支持。 ===集群Session一致性问题=== ====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共享的支持。 应用:电商购物,视频点播 解决了以上的问题之后,系统的结构如下: [[文件:cloud1-11.png]] 上图可以横向迅速扩展 ==阶段四、数据库读写分离化== ==参考文档== [1] https://www.jianshu.com/p/5a67d789216e
返回至
大型Web网站架构演变
。
导航菜单
个人工具
登录
命名空间
页面
讨论
变种
视图
阅读
查看源代码
查看历史
更多
搜索
导航
首页
最近更改
随机页面
帮助
工具
链入页面
相关更改
特殊页面
页面信息