WebSocket连接的负载均衡

 

21CTO 社区导读:在管理大型系统时,负载均衡的问题一直是个热点话题。负载均衡的目的是最优化资源使用,最大化吞吐量,最小化响应时间,避免任何单点资源的过载,因而解决这个问题对性能表现非常关键。在本文中我们将看一看针对这个问题的一些解决方法。



640.webp_(22)_.jpg

 
为了各位更好的理解WS负载均衡,让我们深入了解一下TCP套接字的背景知识。默认地,一个单独的服务器可以处理65536个套接字连接,因为65536是可用的最大的TCP端口数。因此,既然WS连接拥有TCP的特性,每个WS客户端占用一个端口,可以肯定地说WebSocket的连接数目也是有限的。
但是事实上,这只说对了一半儿。对每个单独的IP地址,服务器都可以处理65536个套接字。因而通过向服务器上添加额外的网络接口,就很容易扩展那个数量。与此同时,去追踪服务器上现有多少链接是极其重要的。一旦超出了限制范围,你会遇到很多关于TCP连接的问题(例如,这个时候不能通过SSH去连接到一个服务器)。因而,在你的应用程序代码中限制每个节点的WS连接数是很好的主意。当我们处理WebSockets问题时也会在我们的apps中使用相同的思路。
一旦我们理解了主要的限制条件,以及解决方式之后,让我们开始考虑负载均衡。下面我将描述在我们自己的项目中试过的三种方式。请注意所有的系统部分都是部署在AWS上的,其中的一些技巧和提示只适用于Amazon的主机配置。
 
ELB方法
实现负载均衡最简单的办法是直接使用AWS提供的Elastic Load Balancer方法。从ELB切换到TCP模式是很容易的,这就使得任何类型的TCP连接的负载均衡成为可能, 包括WebSockets。这个方法具备如下特性:
1)LB的自动故障恢复
2)负载均衡节点可以自动伸缩
3)设置非常简单
 
基本上,对大多数情况而言它是一个很好的解决方案,在你遇到负载飞溅的增长情况之前。在这种情况下,ELB运行的很慢以至于无法建立新的连接。可以去联系Amazon,告诉他们去“预热(pre-warm)”ELB,但是它对我们不是一个好的选项,基于负载测试的目的,当我们需要快速建立成千上万的WS连接时;基于对系统的可用性,对客户都不是好选项。
 
软件负载均衡器
我们曾经试过使用HAProxy作为一个负载均衡器。但是为了让HAProxy正确工作我们需要考虑上文讨论的端口限制问题。为了使HAProxy能够处理超过65536个链接,我们需要执行以下步骤:
1.创建一堆私有的IP地址。为了实现这个目的,选择Amazon Instance -> Actions -> Networking -> Manage Private IP Addresses,我们添加三个IP地址:192.168.1.1,192.168.1.2,192.168.1.3。切记,IP要处于与你的真实应用程序服务器同样的子网中;
2.使用SSH连接到你的HAProxy实例,执行下面的命令:
[size=15]$> ifconfig eth0:1 192.168.1.1
$> ifconfig eth0:2 192.168.1.2
$> ifconfig eth0:3 192.168.1.3[/size]

这些命令会往实例中添加3个虚拟网络接口;
3.配置HAProxy。这里是haproxy.cfg文件中的一段,用于3个Erlang节点接收WS连接。
[size=15]listen erlang_front :8888    mode        http
   balance     roundrobin
   timeout connect 1s
   timeout queue 5s
   timeout server 3600s
   option httpclose
   option forwardfor
   server      erlang-1 192.168.0.1:8888  source 192.168.1.1    server      erlang-2 192.168.0.2:8888  source 192.168.1.2    server      erlang-3 192.168.0.3:8888  source 192.168.1.3[/size]

现在,HAProxy 已经能够处理超过65536个WebSockets链接,通过增加虚拟网络接口,连接限制可以简单地增长。同时,它也能非常快地建立新连接。这个方法看上去可行,尽管它尚有如下缺点:
1)故障恢复的HAProxy实例需要使用类似Keepalived工具去手动建立;
2)每次你增加一个新的Erlang节点,都要做些操作去重新配置HAProxy;
3)随着连接数目增长,没有能水平伸缩HAProxy的选项。我们只有一个垂直选项可用,因此当我们有了越来越多的在线用户后,我们需要越来越多的昂贵的HAProxy实例(以及HAProxy镜像节点)。
 
对于这些缺点我们也还算觉得满意,但是一个更简单的方案已经被实现了。那是可能的,因为我们已经有了一些实现好的代码,而系统设计也允许我们使用一个定制方法。
 
定制方法
在继续前进之前,我们先回顾下面的图,它展示了我们系统的架构。

640.webp_(23)_.jpg

 
 
我们有一个JavaScript客户端应用程序,一个auth应用负责用户授权,一个Erlang应用实现主要的功能。数据流程如下:
1.客户端生成一个含有凭证的HTTP请求,发送给Auth Application;
2.Auth Application检查凭证,生成一个令牌,以一种HTTP请求的形式将它发送给Erlang Cluster;
3.Erlang应用确认,令牌已经收到,给Auth应用返回一个包含配置信息的HTTP响应;
4.Auth App给客户端应用程序发送一个HTTP响应。响应中包含生成的令牌;
5.客户端使用令牌通过我们的HAProxy负载均衡器建立与Erlang应用之间的WebSocket连接。
这是我们基本的数据流,它被稍微修改了一点。我们添加一个简单的模块到Erlang应用程序中去追踪每个Erlang节点上的WebSocket连接数。基于Erlang“分布式的”特性,每个节点可以知道其它节点的连接数。因而,我们可以选择一个拥有更少连接的节点,我们使用这个节点的公共IP地址,把它发送回那个auth应用程序。然后那个auth应用程序将这个IP地址随令牌返回到客户端。客户端使用接收到的IP地址和令牌去建立连接。因而,最终的图显示如下:

640.webp_(24)_.jpg

 
现在我们能够:
1)去掉WS的负载均衡器,这就使得我们的系统变得不是那么复杂;
2)添加Erlang节点,而不用对系统其它部分进行重新配置。
 
除此之外:
1)现在WS连接是平均分布于Erlang节点之间的;
2)系统很容易水平伸缩;
3)对Erlang节点我们不需要使用Elastic IPs。
 
 

作者:Konstantin Shamko  
编译:乔乔
原文:https://dzone.com/articles/loa ... tions


0 个评论

要回复文章请先登录注册