基于 OpenRestry 部署 nginx+lua 实现流量定向分发

在上一篇中,我们在linux上部署了OpenRestry单个节点简单实现了hello word功能,使用OpenRestry的强大之处在于使用它和其他模块比如http等,使用它的lua脚本实现一些接口的转发,利用这个特性我们可以设想一下,假如我们使用OpenRestry来实现nginx集群的负载均衡该如何做呢?

可以分两步,假如有多台机器,每台机器上都部署了nginx,那么只需要其中的一台作为转发请求的节点,其他的作为负载均衡的节点不就可以了吗?事实上,也是这样做的,作为流量或者接口转发的节点,我们称之为流量分发服务器,所有需要通过nginx作为代理的请求首先需要走OpenRestry分发,又这个分发服务器统一将流量按照特定的负载均衡算法转到其他nginx服务器,这个也是作为三级缓存架构中的常用做法。

按照上一篇的搭建OpenRestry的流程,我们在另外两台机器上都部署一份OpenRestry,搭建过程都相同,另外的两台节点IP分别为,192.168.111.133 和 192.168.111.134 ,这两个节点作为应用层的nginx,而之前的192.168.9.140 作为分发层nginx服务器,我们编写lua脚本实现流量定向转发也是在这台节点上做。

这里为了使得后期的运维更加方便,我们重新规划一下OpenRestry的相关配置文件的目录,这里我在servers下面新建了一个叫做hello的文件夹,用于存放lua脚本文件和lua的其他依赖组件,如下,
基于 OpenRestry 部署 nginx+lua 实现流量定向分发_第1张图片

基于 OpenRestry 部署 nginx+lua 实现流量定向分发_第2张图片

这样假如以后你的业务越来越多,就可以通过不同的目录进行区分,这里命名比较随意,主要是为了测试,我们分别看看各自的内容,
hello.conf:基本上和上一篇的内容一模一样,只是整理了一下文件的位置,
基于 OpenRestry 部署 nginx+lua 实现流量定向分发_第3张图片
而lualib是直接从安装完毕的OpenRestry主目录下拷贝过来的,里面放的是lua脚本的依赖文件,可以理解为jar包,
基于 OpenRestry 部署 nginx+lua 实现流量定向分发_第4张图片

这里面配置了以后我们需要去nginx目录下重新配置一下nginx.conf的文件,这里面只需要替换一下上一篇的配置变成下面的即可,

基于 OpenRestry 部署 nginx+lua 实现流量定向分发_第5张图片
在133和134节点上均使用上述的配置流程,然后我们启动一下133和134的nginx然后在浏览器访问一下,可以看到另外两个节点的nginx也可以正常使用了,
基于 OpenRestry 部署 nginx+lua 实现流量定向分发_第6张图片

基于 OpenRestry 部署 nginx+lua 实现流量定向分发_第7张图片

下面就是基于lua脚本实现商品ID的定向转发,直接上代码,我也是参考相关资料进行配置的编写的,可以放心使用,

local uri_args = ngx.req.get_uri_args()
local productId = uri_args["productId"]

local host = {"192.168.31.19", "192.168.31.187"}
local hash = ngx.crc32_long(productId)
hash = (hash % 2) + 1  
backend = "http://"..host[hash]

local method = uri_args["method"]
local requestBody = "/"..method.."?productId="..productId

local http = require("resty.http")  
local httpc = http.new()  

local resp, err = httpc:request_uri(backend, {  
    method = "GET",  
    path = requestBody
})

if not resp then  
    ngx.say("request error :", err)  
    return  
end

ngx.say(resp.body)  
  
httpc:close() 

相信有一点编程基础的同学应该能够看懂上面的代码的意思,只是lua脚本的语法可能不太一样,大体意思都差不多,无非就是实现了一个按照请求的商品productId根据我们自定义的crc36的算法实现不同商品ID转发到不同的应用层nginx上面进行处理,从而达到负载均衡合理使用nginx服务器的功能,然后我们在浏览器请求一下下面的地址,当结果展示出来了,再把productId的值分别编程1或其他的数,看看结果会有何不同,留给各位伙伴自己探索了,

http://192.168.9.140/hello?requestPath=hello&productId=5

本篇的整合到此结束,感谢观看!后续将会基于此思路实现相关的java层逻辑,从而真正实现三级缓存的架构设想。

你可能感兴趣的:(nginx,缓存架构,OpenRestry)