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

Question

我们有一个多服务架构，包括 HAProxy 前端（如果需要，我们可以将其更改为另一个代理）、一个 mongodb 数据库和运行下的多个后端应用实例 Docker群.

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

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

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

Answer 1

HAproxy 有你需要的。 This article 说明一切。

作为本文的结论，您可以从两种解决方案中进行选择： IP 源与服务器的亲和力 和应用程序层持久性。后一种解决方案比第一种解决方案 stronger/better 但它需要 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

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

Routing to same instance of Backend container that serviced initial request

docker

docker-compose

docker-swarm