nginx+lua在我司的实践

 导读: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 } }

想详细了解这个案例的,请移步到我的另一篇博客(http://jiuqidy.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在我司使用的四个案例,真实场景要复杂很多,为了方便大家理解,特意将案例做了简化。如果觉得有用,请点个推荐。

参考资料

http://github.com/openresty/lua-nginx-module

posted @ 2020-02-14 14:36  踩刀诗人  阅读(...)  评论(...编辑  收藏

页面底部区域 foot.htm