2023年如何借助AWS ALB将新会话路由至特定目标服务器

核心方案：利用ALB会话粘性+多目标组路由 #

针对你的场景，无需修改应用URL添加查询参数，直接通过AWS ALB的原生规则和目标组配置就能实现，步骤如下：

1. 配置两个目标组 #

• 目标组TG1（原有会话组）：包含服务器A和B，开启基于应用Cookie的会话粘性（如果你的应用自身管理会话Cookie，比如SESSIONID），粘性超时设置为你的应用会话超时时间（比如24小时）。若应用不生成会话Cookie，可使用ALB生成的Cookie，粘性超时同样匹配会话有效期。
• 目标组TG2（新会话组）：仅包含服务器B，同样开启会话粘性，超时规则与TG1保持一致。

2. 配置ALB路由规则（按优先级排序） #

ALB规则优先级从高到低执行，确保精准匹配：

• 优先级1：匹配新会话请求：
  规则条件：HTTP 请求中不存在会话Cookie（比如你的应用会话Cookie名为MY_APP_SESSION），或 请求路径匹配登录接口（如/login）。
  动作：转发至TG2。
  （注：如果应用是登录后才生成会话Cookie，未携带该Cookie的请求即为新会话，直接引导至B；加上登录路径匹配是双重保障）
• 优先级2：匹配已有会话请求：
  规则条件：HTTP 请求中存在有效会话Cookie。
  动作：转发至TG1。
  （TG1的会话粘性会自动将已有会话路由到对应的服务器：原绑定A的会话继续走A，原绑定B的会话继续走B）
• 默认规则：转发至TG2（兜底处理所有未匹配的请求，确保新流量不会意外到A）

3. 监控与最终下线服务器A #

• 通过CloudWatch监控TG1中服务器A的指标：RequestCountPerTarget（目标请求数）、ActiveConnectionCount（活跃连接数），跟踪A的会话活跃度。
• 当A的RequestCountPerTarget连续数小时为0，确认无活跃会话后，先将A从TG1中移除，观察1-2小时确保无流量进入A，再关闭服务器A。

方案优势 #

• 无需修改应用代码，完全通过ALB配置实现，侵入性低
• 严格区分新/旧会话，原有用户无感知，实现平滑迁移
• 适配AWS ALB最新规则能力，利用Cookie匹配和优先级路由特性完成需求

内容的提问来源于stack exchange，提问作者pinoyyid