大型网站系统架构实践深入探讨web应用高可用方案

Posted 年少有为AAA

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了大型网站系统架构实践深入探讨web应用高可用方案相关的知识,希望对你有一定的参考价值。

从上篇文章到这篇文章,中间用了一段时间准备,主要是想把东西讲透,同时希望大家给与一些批评和建议,这样我才能有所进步,也希望喜欢我文章的朋友,给个赞,这样我才能更有激情,呵呵。

由于本篇要写的内容有点多,我就分为几篇博客进行了详细描述。

Haproxy提高web应用的高可用

       上一篇文章讲到了haproxy+tomcat的方案,文章地址:大型网站系统架构的演进(四)http层负载均衡之haproxy实践篇(一)

大家可以先温习一下,

       文中提到了高可用,该集群方案也可以提高应用系统的高可用,如果tomcat应用出现故障,或者tomcat应用服务器出现故障,haproxy会检测到(这里指的是定期心跳检查),并将应用从可用列表中删除,打开监控页面http://192.168.1.227/haproxy-stats

image

可以看到有2个web应用运行,如果将webA停掉,可以看到webA显示down

image

这样客户端请求就不会分发给webA,下面模拟一下webA宕机的情况

这里对sessionId增加了一个后缀做标记

webA:jvm3

webB:jvm2

1. webA正常的情况,客户请求被分发到webA

clip_image005[3]

此时产生的sessionId为jvm3

2. 停掉webA,刷新浏览器

clip_image006[3]

可以看到请求被转发到webB

也就是说web应用出现故障,haproxy会做切换,因此可以保证web应用的高可用。

Haproxy本身的高可用

      如果haproxy本身出现故障,那么网站将不可用,所以我们接下来要做的事情就是解决haproxy单点故障的问题。

我们可以运用虚拟ip技术,将haproxy部署在2台服务器上,一台做为master,正常运营,一台为backup,

当master出现问题的时候,接管master。

      首先有一个虚拟ip暴露给客户端,虚拟ip对应的mac地址为master服务器,

用户向虚拟ip发送一个请求,该请求会被分发到master服务器上,当master出现故障时,被backup检测到,则backup成为master,

且发送消息将arp缓存虚拟ip对应的mac地址backup的mac地址,这样发送到虚拟ip的报文会被转发到backup 。

架构图:

clip_image007[3]

该方案解决了haproxy单点故障的问题,具体用keepalived实现,详细请参考文章:

Keepalived 实现双机热备

Keepalived + haproxy双机高可用方案

如果想实践的朋友,请按照上面2篇文章安装和配置haproxy和keepalived

系统分布如下:

ha主机 192.168.1.227:80

ha备机 192.168.1.246

keepalived 主机 192.168.1.227

keepalived备机 192.168.1.246

web1 http://192.168.1.226:8081/login

web2 http://192.168.1.246:8888/login

虚拟ip 192.168.1.99

安装好haproxy和keepalived后,启动haproxy和keepalived

Haproxy访问地址:

http://192.168.1.99/haproxy-stats

image

注意pid为9644,这是master上的haproxy

应用访问地址

http://192.168.1.99/login/

clip_image010[3]

注意sessionId的后缀为jvm3

查看虚拟ip1.99对应的mac地址

clip_image011[3]

接下来,我们停掉master上的haproxy服务

clip_image012[3]

kill -9 9644

查看haproxy http://192.168.1.99/haproxy-stats

clip_image013[1]

发现haproxy的pid变成backup机器上的了

刷新web的访问页面http://192.168.1.99/login/

clip_image014[1]

发现sessionId没有变化

查看虚拟ip1.99对应的mac地址

clip_image015[1]

mac地址已经变为backup机器上的了

如果我们直接关闭主机服务器或者关闭主机的keepalived,发现测试结果也是一样的

因此该方案实现了haproxy的高可用,解决了haproxy的单点故障问题。

会话保持问题

那么这里我还要提出一个疑问,为什么sessionId也没有变化呢?

也就是说切换到backup服务器的haproxy之后,

可以保持用户的会话,那么它是怎么实现的呢?

这里就要回到上篇文章讲的负载均衡时保持会话的策略

会话保持的流程

1.客户端首次请求,经过haproxy到web服务端时,web服务端set-cookie并响应到haproxy

2.haproxy在cookie后插入SRV=A,并响应客户端

3.客户端第二次请求,经过haproxy时,haproxy将srv后缀去掉,然后请求服务端

这种保持会话的方法是无状态的,也就说主要haproxy配置的负载均衡策略相同,不管在哪台机器上运行

将得到同样的结果

以上是关于大型网站系统架构实践深入探讨web应用高可用方案的主要内容,如果未能解决你的问题,请参考以下文章

高可用的分布式系统架构探讨

大型网站技术架构,5网站的高可用架构之高可用网站的软件质量保证

4 网站架构模式

4 网站架构模式

简谈9种高性能高可用高并发的技术架构

高并发与高可用实战之基础知识大型网站架构特征