Lua в Nginx: динамическая маршрутизация запросов
Привет, Хабр!
Сегодня рассмотрим то, как использовать Lua в Nginx: динамическую маршрутизацию, балансировку трафика, подмену заголовков и трансформацию тела запроса в реальном времени. OpenResty и lua‑nginx‑module позволяют перенести часть логики на уровень веб‑сервера, сокращая задержки и повышая гибкость.
Динамическое изменение upstream через lua-resty-balancer
Одной из самых крутых фич, за которую я люблю OpenResty, является возможность изменять upstream в рантайме. Вместо того чтобы перезагружать сервер при смене конфигурации, просто обновляем значение в lua_shared_dict — и всё работает.
Пример конфигурации:
http {
lua_shared_dict balancer_cache 10m;
upstream dynamic_upstream {
server 127.0.0.1:8080; # Резервный сервер по умолчанию
}
server {
listen 80;
server_name example.com;
location / {
access_by_lua_block {
local balancer_cache = ngx.shared.balancer_cache
local new_upstream = balancer_cache:get("current_upstream")
if new_upstream then
ngx.var.upstream = new_upstream
else
ngx.var.upstream = "dynamic_upstream"
end
ngx.log(ngx.INFO, "Используем upstream: ", ngx.var.upstream)
}
proxy_pass http://$upstream;
}
}
}Храним текущий upstream в lua_shared_dict и можем динамически менять его, например, через REST API или cron‑задачу. Так даже можно реализовывать failover‑механизмы, A/B‑тесты и какие‑нибудь схемы балансировки. Но, как говорится, с большой силой приходит большая ответственность: всегда добавляйте обработку ошибок и логирование.
Подмена заголовков и изменение тела запроса/ответа на ходу
Еще есть возможность изменять заголовки и тело запросов/ответов в реальном времени.
Пример изменения заголовков:
http {
lua_shared_dict balancer_cache 10m;
upstream dynamic_upstream {
server 127.0.0.1:8080; # Резервный сервер по умолчанию
}
server {
listen 80;
server_name example.com;
location / {
access_by_lua_block {
local balancer_cache = ngx.shared.balancer_cache
local new_upstream = balancer_cache:get("current_upstream")
if new_upstream then
ngx.var.upstream = new_upstream
else
ngx.var.upstream = "dynamic_upstream"
end
ngx.log(ngx.INFO, "Используем upstream: ", ngx.var.upstream)
}
proxy_pass http://$upstream;
}
}
}Подменяем заголовок User‑Agent. Но на этом возможности не заканчиваются: можно динамически добавлять, удалять или модифицировать любые заголовки, в зависимости от бизнес‑логики. А теперь пример изменения тела ответа:
server {
listen 80;
server_name example.com;
location /modify_body {
proxy_pass http://backend_service;
header_filter_by_lua_block {
ngx.header["Content-Type"] = "application/json"
}
body_filter_by_lua_block {
local chunk = ngx.arg[1]
if chunk then
-- Пример: добавляем поле "extra": "value" в JSON-ответ.
chunk = string.gsub(chunk, "}", ', "extra": "value"}')
end
ngx.arg[1] = chunk
}
}
}Приправляем JSON‑ответ, добавляя новое поле. Конечно, тут еще потребуется более аккуратное парсирование JSON и проверка корректности данных. Но главное здесь — понять принцип: можно менять данные на ходу, без вмешательства в бек.
Nginx как API Gateway с динамической маршрутизацией
Используем lua_shared_dict для хранения динамических правил маршрутизации, что позволяет адаптироваться к изменяющимся условиям — будь то A/B‑тестирование, экстренное переключение на резервный сервер или плавное обновление конфигурации.
http {
lua_shared_dict route_config 1m;
server {
listen 80;
server_name api.example.com;
location / {
access_by_lua_block {
local route_config = ngx.shared.route_config
local uri = ngx.var.uri
local route = route_config:get(uri)
if route then
ngx.var.target = route
else
ngx.var.target = "default_backend"
ngx.log(ngx.WARN, "Маршрут для URI ", uri, " не найден, используем default_backend")
end
ngx.log(ngx.INFO, "Маршрутизируем URI: ", uri, " к ", ngx.var.target)
}
proxy_pass http://$target;
}
}
}lua_shared_dict route_config позволяет хранить и изменять правила маршрутизации без перезагрузки Nginx, что по сути база для обновлений через API или по расписанию. В access_by_lua_block определяем маршрут на основе URI, а при его отсутствии автоматом используем default_backend, тем самым делая некую отказоустойчивость.
Redis+Lua: управление балансировкой трафик
Когда Nginx должен быстро адаптироваться к изменяющимся условиям, логично вынести логику маршрутизации в хранилище с мгновенным доступом. Redis + Lua — мощный дуэт, позволяющий динамически управлять трафиком без перезагрузки сервера.
Пример интеграции Redis с Nginx:
http {
lua_package_path "/usr/local/openresty/lualib/?.lua;;";
lua_shared_dict redis_cache 10m;
server {
listen 80;
server_name api.example.com;
location /traffic {
access_by_lua_block {
local redis = require "resty.redis"
local red = redis:new()
red:set_timeout(1000) -- Таймаут 1 секунда
local ok, err = red:connect("127.0.0.1", 6379)
if not ok then
ngx.log(ngx.ERR, "Ошибка подключения к Redis: ", err)
return ngx.exit(500)
end
local route, err = red:get("route:" .. ngx.var.uri)
ngx.var.backend = (route and route ~= ngx.null) and route or "default_backend"
ngx.log(ngx.INFO, "Выбран backend: ", ngx.var.backend)
-- Возвращаем соединение в пул
local ok, err = red:set_keepalive(10000, 100)
if not ok then
ngx.log(ngx.ERR, "Ошибка возврата соединения в пул: ", err)
end
}
proxy_pass http://$backend;
}
}
}Nginx перед каждым запросом обращается к Redis по ключу route:/traffic для выбора целевого backend, что позволяет централизованно управлять балансировкой и оперативно перенаправлять нагрузку; при этом высокая производительность достигается за счёт минимальных задержек Redis и использования lua_shared_dict для кеширования, а пул соединений, настроенный через set_keepalive, экономит ресурсы, возвращая неиспользованные TCP‑соединения (до 100 соединений с таймаутом 10 секунд) вместо создания нового для каждого запроса.
Если у вас возникнут вопросы или захотите поделиться своими фишками — пишите в комментариях.
Больше актуальных навыков по IT‑инфраструктуре вы можете получить в рамках практических онлайн‑курсов от экспертов отрасли. В каталоге можно посмотреть список всех программ, а в календаре — записаться на открытые уроки.
