nginx-sticky-module-ng 不适合当前金丝雀测试场景，因其不兼容 nginx ≥1.22、需源码编译、仅支持简单 cookie 哈希且无法联动灰度标识；推荐用 upstream hash + 自定义 cookie 或应用无状态化等现代方案。
在金丝雀发布中，会话粘滞（Session Sticky）是确保用户请求持续路由到同一后端实例的关键机制，尤其适用于未共享会话状态的传统应用。Nginx 官方不原生支持 sticky session，需借助第三方模块（如 nginx-sticky-module-ng）实现。但需注意：该模块仅支持 Nginx 1.10–1.20，且与较新版本（如 1.22+）及动态模块加载机制不兼容。因此，实际用于金丝雀流量测试时，更推荐使用现代、可维护的替代方案。
为什么 Sticky-Module 不适合当前金丝雀测试场景
nginx-sticky-module-ng 已多年未更新，存在以下现实限制：
- 不兼容 Nginx 主线版本（≥1.22），而主流发行版（如 Ubuntu 22.04+/CentOS Stream 9）默认搭载 1.20+ 或更高版本
- 需源码编译，无法通过包管理器安装，增加部署复杂度和安全审计成本
- 仅支持基于 cookie 的简单哈希粘滞，不支持权重感知、健康检查联动或灰度标签路由
- 无法区分“金丝雀流量”与“稳定流量”，难以配合 header、cookie 或参数做条件性粘滞
推荐方案：用 Nginx Plus 或开源 Nginx + upstream hash + 自定义 cookie
若坚持使用开源 Nginx（无 Plus 许可），可通过内置 upstream hash 指令模拟轻量级粘滞，并结合金丝雀标识实现可控测试：
- 在 location 块中使用
hash $cookie_sticky_key consistent;，让相同 cookie 的请求始终打到同一 backend - 前端或网关在首次请求时注入带金丝雀标识的 cookie（如
sticky_key=canary-v2-abc123），后续请求自动复用 - 配合
upstream中不同 server 的 weight 和 max_fails 设置，使 canary 实例仅承接粘滞流量，不参与默认轮询
示例配置片段：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
upstream backend {
# 稳定集群（高权重）
server 10.0.1.10:8080 weight=10;
server 10.0.1.11:8080 weight=10;
# 金丝雀实例（低权重 + 显式标识）
server 10.0.1.20:8080 weight=1 down; # 初始不参与轮询
}
<p>server {
location / {</p><h1>优先按自定义 cookie 哈希，保证粘滞</h1><pre class="brush:php;toolbar:false;"> hash $cookie_sticky_key consistent;
proxy_pass http://backend;
# 可选：对携带 canary=1 的请求，自动设 sticky_key
if ($arg_canary = "1") {
add_header Set-Cookie "sticky_key=canary-$host-$remote_addr; Path=/; Max-Age=3600";
}
}}
更健壮的金丝雀会话测试实践（推荐）
绕过 sticky 依赖，从架构层面提升可测性：
- 改造应用层会话：将 session 存入 Redis 或数据库，后端无状态化，彻底消除粘滞需求
-
用 OpenResty + Lua 动态路由：根据 header（如
X-Canary-Version: v2）、cookie 或 JWT claim，将用户固定导向指定 upstream group - 结合服务网格（如 Istio）：利用 VirtualService 的 traffic routing + sessionAffinity（基于 header 或 cookie），原生支持金丝雀+粘滞组合策略
- 压测时显式构造粘滞流：用 curl 或 k6 脚本固定 cookie 值发起多请求，验证单个 canary 实例是否承载全部关联会话
小结：务实选择比强行套用旧模块更重要
nginx-sticky-module-ng 是历史方案，当前生产环境应避免引入。金丝雀发布中的会话一致性，本质是“控制流量归属”问题。用 Nginx 原生 hash + cookie 控制、应用层解耦 session、或升级到服务网格，都能更安全、可观测、易运维地达成目标。测试时聚焦验证：指定标识的用户是否 100% 流入目标 canary 实例，且其后续请求不漂移——这比模块名称是否叫 “sticky” 更关键。
