路由到服务初始请求的后端容器的同一实例-Java 学习之路

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

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

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

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

1 回答

1
HAproxy拥有您所需要的 . This article解释了所有 .

作为本文的结论，您可以选择两种解决方案： IP source affinity to server 和 Application layer persistence . 后一种解决方案比第一种解决方案更强大/更好，但它需要cookie .

这是文章的附加内容：

IP source affinity to server

维护用户和服务器之间关联的一种简单方法是使用用户的IP地址：这称为源IP关联 . 这样做有很多问题，我现在不打算详细介绍它们（TODO：另一篇要写的文章） . 您唯一需要知道的是，当您想要将用户“粘住”到服务器时，源IP亲缘关系是最新的方法 . 嗯，只要用户使用单个IP地址或者他在会话期间从不更改IP地址，它就能解决我们的问题 .

Application layer persistence

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

What is the difference between Persistence and Affinity

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

持久性：这是我们使用应用程序层信息将客户端粘贴到单个服务器的时候

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

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

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

Affinity configuration in HAProxy / Aloha load-balancer

以下配置显示了如何根据客户端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 setup by the Load-Balancer 下面的配置显示了如何配置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
```
回复于 2024-05-05T04:46:08+08:00

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

1 回答

相关问题