导读：nginx是一个高性能的反向代理服务器，lua是一个小巧的脚本语言，这两个的巧妙结合会擦出怎样的火花呢。
关键词：nginx，lua，nginx+lua
前言
nginx，lua，nginx+lua，这三个名词不知道大家熟悉多少。为了后面内容的展示，我简单的介绍一下它们，想深入了解的网上资料很多，在这就不啰嗦了。nginx是一个高性能的反向代理服务器，一般会处在网站的最前端（有可能前面还会加一层slb，在这暂时忽略），用来做后端web服务的代理；lua是一个小巧的脚本语言，其设计的目的就是嵌入应用程序中，为其提供一些扩展和增强，比如redis，nginx等等；nginx+lua顾名思义就是nginx和lua的结合体，这两者之间沟通的桥梁是nginx_lua_module，它是nginx的一个模块，有了它nginx和lua才能互通，笔者在最近几年的工作中恰好有这方面的开发经验，所以想把这些真实的使用场景分享出来供大家做参考，具体的api doc还请大家参考官方资料。
案例1-入口层流量的灰度识别
何谓入口层流量的灰度识别呢，简单来说就是A用户的请求打到线上环境，B用户的请求打到灰度环境，目的就是做新功能的验证，实现逻辑很简单，大体流程如下：
1.测试同学在灰度控制台配置灰度规则，规则里会约束哪些url下哪些商户的请求进入灰度环境；
2.灰度控制台推送规则给入口层nginx，nginx会将规则存储到本地内存中，借助ngx.shared.DICT；
3.请求进入的时候（通过rewrite_by_lua_file触发）获取本地内存中的规则进行比对，如何命中规则就将请求转发到灰度环境，对nginx来说就是切换不同的upstream，比如线上是prod_serverA，灰度是gray_serverA；
代码片段如下：
upstream gray_serverA {
server 192.68.1.1:8080;
}
upstream prod_serverA {
server 192.68.1.2:8080;
}
server {
listen 80;
server_name graytest.demo.com;
charset utf-8;
location ~ \.do$ {
set $backend 'prod_serverA'; #默认的upstream为线上服务
rewrite_by_lua_file "conf/lua-gray/rewriter.lua"; # rewrite_by_lua_file 可以简单的理解为一个过滤器，nginx在rewrite阶段会执行你指定的脚本文件，
#在这个文件中我们会判断请求是否为灰度请求如果是灰度请求就将backend改为gray_serverA
proxy_pass http://$backend;
}
}
案例2-入口层记录错误日志
之前有同学反馈说springmvc偶尔会报415错误，这个错误的一个常见原因是传递的Content-Type头不对，比如后端需要application/json，但是前端传递了application/x-www-form-urlencoded，那就会报这个错。但是跟前端确认了传递的头是没有问题的，有人猜测可能是头信息有特殊字符，导致后端web 容器（tomcat、resin）解析头出现了问题，既然这样把所有请求头打出来一看究竟，于是lua再一次出场，这次主要用来输出请求头到日志文件中，主要用到了log_by_lua_block这个指令，代码片段如下：
location ~ \.do$ { proxy_pass http://$backend; log_by_lua_block {
//判断下如果http 响应状态码为415就输出请求头到文件中 if tonumber(ngx.var.status) == 415 then ngx.log(ngx.ERR,"upstream reponse status is 415,please notice it,here are request headers:") local h, err = ngx.req.get_headers(100,true) if err == "truncated" then ngx.log(ngx.ERR,"request headers beyond 100,will not return") else local cjson = require("cjson") ngx.log(ngx.ERR,cjson.encode(h)) end end } }
想详细了解这个案例的，请移步到我的另一篇博客（https://www.cnblogs.com/chopper-poet/p/11625144.html）。
案例3-将nginx信息注册到监控平台
需求很简单，当nginx启动的时候将自身信息上报到redis中，上报内容包扣自身的ip，代理的域名信息等，有个监控平台会定期从redis读取这些信息做展示，方便运维干活，流程很简单就是定时读取自身ip和代理的域名信息写到redis中，为什么要定时呢，这里还起到一种心跳的效果，当长时间没有上报时可能是nginx出问题了，主要用到的指令如下：
1.init_worker_by_lua_file "conf/ua-grayngxReloadListener.lua"，当nginx启动或者reload的时候会执行指定的文件；
2.ngx.worker.id() 这个方法会返回nginx worker进程的编号，从0开始，如果nginx有4个worker，那取值范围为0-3，这个主要是为了防止并发上报，因为第一步里面提到的init_worker_by_lua_file，如果有几个worker就会触发几次，所以为了只上报一次，会判断下返回值是否为0，也就是只让第一个worker执行；
3.ngx.timer.every 用来执行定时任务；
代码片段如下：
local workerId = ngx.worker.id()
if(workerId == 0) then
ngx.log(ngx.INFO,'workerId is 0 will startup task')
local ok, err = ngx.timer.every(4,function()
#1. get local ip and domins
#2. write to redis
end)
else
ngx.log(ngx.INFO,'workerId is not 0 ,just ignore it')
end
案例4-将入口层流量同时转发到多个后端服务
类似于消息队列的发布订阅一样，在nginx这一层可以将一个请求同时发到多个地址，代码片段如下：
location ~ /capture_test$ { content_by_lua_block { ngx.req.read_body() res1, res3 = ngx.location.capture_multi{ { "/capture_test1",{ method = ngx.HTTP_POST, always_forward_body=true}}, { "/capture_test2",{ method = ngx.HTTP_POST, always_forward_body=true}}, } ngx.say(res3.body) ngx.exit(res3.status) }
总结
上面列举了nginx+lua在我司使用的四个案例，真实场景要复杂很多，为了方便大家理解，特意将案例做了简化。如果觉得有用，请点个推荐。
