OpenResty 通过嵌入 Lua 脚本实现 Nginx 动态路由：支持参数/请求头驱动的上游切换、Redis/Consul 服务发现、JWT 租户隔离，兼顾性能与安全，需配合日志与监控保障生产可用。
OpenResty 能让 Nginx 网关真正“活”起来——它不只是转发请求，还能在运行时读取数据库、调用外部服务、解析 JWT 并据此动态决定路由目标。关键在于把 Lua 脚本嵌入到 Nginx 的请求生命周期中，用轻量逻辑替代静态配置的僵化限制。
用 Lua 实现基于请求头或参数的动态上游选择
无需重启 Nginx，就能根据 Host、X-Env 或 URL 参数（如 ?version=v2）切换后端集群。核心是利用 balancer_by_lua_block 或 rewrite_by_lua_block 修改 ngx.var.upstream_http_host 和 ngx.var.upstream_addr。
- 在
upstream块外定义多个 upstream 组（如backend_v1、backend_v2），不设具体 server - 在
location中用rewrite_by_lua_block解析参数或 header，设置自定义变量（如ngx.var.target_upstream = "backend_v2"） - 用
proxy_pass http://$target_upstream完成动态代理，Nginx 会自动解析变量为对应 upstream 块
接入 Redis 或 Consul 实现服务发现驱动的路由
把路由规则从配置文件移到外部存储，支持灰度发布、AB 测试、故障自动摘除。OpenResty 提供 resty.redis 和 resty.http 模块，可在 access_by_lua_block 中实时查询。
- 例如：请求路径
/api/user→ 查询 Redis 中route:api:user的值，返回http://svc-user-v2:8080 - 搭配 TTL 缓存（
lua_shared_dict）避免每次查 Redis，缓存失效时再回源 - Consul 场景下，用
resty.http调用/v1/health/service/user?passing获取健康实例列表，Lua 随机或轮询选一个 IP:Port
结合 JWT 解析实现租户级路由隔离
多租户 SaaS 场景中，不同租户请求应打到各自独立的后端服务组（如 tenant-a-api、tenant-b-api）。OpenResty 可在网关层完成鉴权与路由解耦。
- 用
lua-resty-jwt解析 Authorization Header 中的 token，提取tenant_id声明 - 将
tenant_id映射为 upstream 名称（如"tenant-" .. tenant_id .. "-api"），并校验该 upstream 是否已预定义 - 若租户未开通服务，直接返回 403；否则设置
ngx.var.upstream_name并交由proxy_pass执行
注意 Lua 性能与安全边界
动态路由能力越强，越要防范脚本失控。OpenResty 不是通用应用服务器，Lua 逻辑必须短小、无阻塞、可预测。
- 禁用
os.execute、io.open等危险 API，通过lua_safe_env on限制全局环境 - 所有外部调用（HTTP/Redis）必须设超时（
set_timeout）和最大重试次数，失败时有兜底 upstream - 复杂业务逻辑（如规则引擎、SQL 查询）应下沉到独立的控制面服务，网关只做轻量决策和转发
不复杂但容易忽略：动态路由的价值不在“能换”，而在“换得快、换得稳、换得可追溯”。配合 OpenResty 的日志定制（log_by_lua_block 记录路由决策链路）和 Prometheus 指标暴露，才能真正支撑起生产级 API 网关。
