文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏

负载均衡问题在大型系统管理中通常是一个热门话题。负载均衡是为了优化资源利用,提高吞吐量,缩短响应时间,避免单一资源过载,所以解决这个问题对系统性能是很重要的。在这篇文章中将来看一看解决这种问题可能的方法。

为了更好的理解WS负载均衡,我们稍微深入了解一下TCP套接字的背景。默认情况下,一个单独的服务可以处理65536个套接字连接因为这是TCP可用端口的最大数量。由于WS连接自带TCP而且每个WS客户端占据一个端口我们可以明确的说websocket 连接的数量也是有限制的。

第 1 段(可获 1.54 积分)

实际上这不全是事实。 对于每个IP地址服务器可以处理65,536个套接字。 因此,通过向服务器添加额外的网络接口可以轻松扩展数量。 与此同时,跟踪服务器上存在的连接数也是非常重要的。

一旦超过限制,您可能会有很多其他的TCP连接问题(例如,无法通过ssh连接到服务器)。 因此,最好限制应用程序代码中每个节点的WS连接。 当我们处理websockets时,我们在应用程序中也这样做。

一旦我们得到主要的限制和克服它的方式,让我们继续负载均衡。 下面我将描述我们在我们的一个项目中尝试的3种方式。 请注意,所有系统部件都部署到AWS,一些技巧和提示仅适用于Amazon配置。

第 2 段(可获 1.96 积分)

ELB 方法

实现负载平衡的最简单的方法就是使用AWS提供的 Elastic Load Balancer。 可以将ELB切换到TCP模式,从而实现任何类型的TCP连接(包括WebSocket)的负载平衡。 这种方法可以实现:

  • LB的自动故障转移;
  • 负载均衡节点的自动缩放;
  • 非常容易设置。

基本上,对于大多数常见的情况,这是一个很好的解决方案,直到你的负载快速增长。 在这种情况下,ELB将会变得太慢,无法建立新的连接。 您可以联系亚马逊并要求他们“预热(pre-warm)”ELB,但是对我们来说为了进行负载测试,我们需要快速建立数千个WS连接,对我们的客户来说,出于系统的可用性,我们不会这样选择。

 

第 3 段(可获 1.59 积分)

软件负载均衡

我们尝试使用HAProxy作为负载均衡器。 但为了使HAProxy正常工作,您应该记住我们上面讨论的端口限制问题。 为了使HAProxy处理超过65k的连接,我们应该按照以下步骤:

1.创建一组私有IP地址。 为此,选择您的Amazon实例 - >操作 - >网络 - >管理私有IP地址。 也就是说 添加了3个IP地址:192.168.1.1,192.168.1.2,192.168.1.3。 要记住,IP应该在你实际应用服务器的同一个子网中;

第 4 段(可获 1.3 积分)

2. 通过 SSH 链接到 HAProxy 服务器上并运行如下命令:

$> ifconfig eth0:1 192.168.1.1
$> ifconfig eth0:2 192.168.1.2
$> ifconfig eth0:3 192.168.1.3

此命令将为这个服务增加三个虚拟网络接口;

3. 配置 HAProxy。这是 haproxy.cfg 配置文件的一部分,配置了三个 Erlang 节点用于接受 WS 连接。

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
第 5 段(可获 0.48 积分)

现在HAProxy可以处理超过65,536个websocket连接,并且可以通过添加虚拟网络接口轻松增加连接限制。 此外,它建立新的连接速度相当快。

这种方法似乎是可行的,尽管有以下缺点:

  • 应该使用诸如keepalived之类的工具手动设置故障转移HAProxy实例;
  • 当你添加一个新的Erlang节点时,需要重新配置HAProxy;
  • 随着连接数量的增长,没有水平缩放HAProxy的选项。 我们只有垂直选项可用,所以当我们有越来越多的活跃用户时,我们应该为HAProxy(和HAProxy镜像节点)获得越来越贵的实例。
第 6 段(可获 1.4 积分)

我们接受这些缺点,但可以实现更简单的解决方案。 这是可能的,因为我们已经实现了一些代码,我们的系统设计允许我们使用自定义方法。

自定义方法

继续前进,让我们看看下面显示我们系统架构的图表。

我们有一个JavaScript客户端应用程序,一个负责用户授权的auth应用程序和一个具有主应用程序功能的Erlang应用程序。 流程如下:

  1. 客户端使用凭证向授权应用程序发出HTTP请求;
  2. Auth应用程序检查凭证,生成令牌并通过HTTP请求将其发送到Erlang Cluster;
  3. Erlang应用程序确认接收到令牌,并向Auth应用程序发送带有确认的HTTP响应;
  4. Auth App向客户端应用程序发送HTTP响应。 此响应包括生成的令牌;
  5. 客户端使用令牌通过我们的HAProxy负载均衡器与Erlang应用程序建立websocket连接。
第 7 段(可获 1.84 积分)

这是我们稍作修改后的基本流程。 我们向Erlang应用程序添加了一个简单的模块来跟踪每个Erlang节点上的websocket连接数。 由于Erlang的“分布式”性质,每个节点知道其他节点的连接。

因此,我们可以选择具有较少连接的节点。 我们使用这个节点的公共IP地址,并且只发送回auth应用程序。 然后auth应用程序将此IP和令牌一起发送给客户端。 客户端使用接收的IP地址和令牌建立WS连接。 所以最终的图看起来像这样:

第 8 段(可获 1.2 积分)

现在我们可以:

  • 摆脱WS负载均衡器,这使我们的系统不那么复杂;
  • 添加Erlang节点,而不对系统的其他部分进行任何重新配置。

此外:

  • WS连接现在平均分布在Erlang节点之间;
  • 系统容易水平缩放;
  • 我们不必为Erlang节点使用弹性IP。
第 9 段(可获 0.69 积分)

文章评论