docker - 路由到为初始请求提供服务的后端容器的同一实例

Question

我们有一个多服务架构，包括 HAProxy 前端(如果需要，我们可以将其更改为另一个代理)、一个 mongodb 数据库以及在 Docker Swarm 下运行的多个后端应用程序实例。

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

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

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

Answer 1

HAproxy 有你需要的东西。 This article解释一切。

作为本文的结论，您可以从两种解决方案中进行选择:
与服务器的 IP 源亲和性 和 应用层持久化 .后一种解决方案比第一种更强大/更好，但它需要 cookie。

以下是文章的附加内容:

与服务器的 IP 源亲和性

维护用户和服务器之间的亲和性的一种简单方法是使用用户的 IP 地址:这称为源 IP 亲和性。
这样做有很多问题，我现在不打算详细说明(TODO++:另一篇文章要写)。
您唯一需要知道的是，源 IP 亲和性是您想要将用户“固定”到服务器时使用的最新方法。
好吧，确实，只要用户使用单个 IP 地址或者他在 session 期间从不更改他的 IP 地址，它就会解决我们的问题。

应用层持久化

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

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

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

持久性:这是我们使用应用层信息将客户端固定到单个服务器的时候

粘性 session :粘性 session 是由持久性维护的 session

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

使用持久性，我们的意思是我们 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

负载均衡器设置的 session cookie
下面的配置显示了如何配置 HAProxy/Aloha 负载均衡器以在客户端浏览器中注入(inject) 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