Question

我们拥有由HAProxy前端（如果需要，可以将其更改为另一个代理），mongodb数据库以及在Docker Swarm下运行的后端应用程序的多个实例组成的多服务体系结构。

一旦初始请求被路由到后端应用程序的实例（容器），我们希望来自移动客户端的所有将来请求都被路由到同一实例。后端应用程序使用TCP套接字与VoIP PBX通信。

理想情况下，我们想使用docker-compose文件中的副本密钥控制后端应用程序的实例数。但是，如果容器死亡并被重新创建，我们将要求移动客户端继续路由到同一容器。原因是每个容器都保存着状态信息。

使用Docker swarm可能吗？我们认为后端应用程序的每个实例在创建时都会获得一个标识符，该标识符然后用于执行基于路径的某种路由。

Answer 1

HAproxy满足您的需求。 This article进行了解释。

作为本文的结论，您可以选择两种解决方案： 与服务器的IP源关联性和应用程序层持久性。后一种解决方案比第一种解决方案更强大/更好，但它需要cookie。

这是该文章的附加内容：

与服务器的IP源关联

维护用户与服务器之间亲和性的一种简单方法是使用用户的IP地址：这称为源IP亲和性。这样做有很多问题，我现在不准备详细介绍（TODO ++：另一篇要写的文章）。您唯一要知道的是，当您要将用户“粘在”服务器上时，源IP关联是最新使用的方法。好吧，只要用户使用一个IP地址，或者他在会话期间从不更改IP地址，就可以解决我们的问题。

应用层持久性

由于Web应用程序服务器必须分别标识每个用户，所以为了避免将某个用户的内容提供给另一个用户，我们可以使用此信息，或者至少尝试在负载均衡器中重现相同的行为以保持持久性在用户和服务器之间。我们将使用的信息是会话Cookie，可以由负载均衡器本身设置，也可以由应用程序服务器设置。

持久性和亲和力有什么区别

亲和力：这是当我们使用来自应用程序层下一层的信息来维护对单个服务器的客户端请求时

持久性：这是当我们使用应用程序层信息将客户端绑定到单个服务器时

粘性会话：粘性会话是由持久性维护的会话

持久性优于亲和力的主要优点是它更准确，但有时持久性不可行，因此我们必须依靠亲和力。

使用持久性，是指我们100％确保用户将被重定向到单个服务器。使用亲和力，我们的意思是可以将用户重定向到同一服务器...

HAProxy / Aloha负载均衡器中的相似性配置

以下配置显示了如何基于客户端IP信息在HAProxy中进行关联：

frontend ft_web
  bind 0.0.0.0:80
  default_backend bk_web
backend bk_web
  balance source
  hash-type consistent # optional
  server s1 192.168.10.11:80 check
  server s2 192.168.10.21:80 check

负载均衡器设置的会话Cookie 以下配置显示了如何配置HAProxy / Aloha负载均衡器以在客户端浏览器中注入cookie：

frontend ft_web
  bind 0.0.0.0:80
  default_backend bk_web
backend bk_web
  balance roundrobin
  cookie SERVERID insert indirect nocache
  server s1 192.168.10.11:80 check cookie s1
  server s2 192.168.10.21:80 check cookie s2

路由到服务初始请求的后端容器的同一实例

1 个答案: