openresty＋consul动态配置更新(服务变更发现)

最新推荐文章于 2024-09-23 09:06:40 发布

yueguanghaidao

最新推荐文章于 2024-09-23 09:06:40 发布

阅读量1.4w

点赞数 2

分类专栏： Lua openresty 文章标签： openresty consul 服务发现

本文链接：https://blog.csdn.net/yueguanghaidao/article/details/52862066

版权

本文介绍了如何使用OpenResty结合Consul进行动态配置更新，以解决服务发现和配置动态更新的问题。通过Consul的KV存储和长轮询机制，OpenResty可以实时获取配置变化，无需reload。同时，文章提到了在处理配置变更时要注意工作进程的状态，避免在nginx reload时导致worker无法正常退出，并建议在高负载场景下使用OpenResty的async模式提升性能。

摘要由CSDN通过智能技术生成

最近在做数据收集平台，用openresty往kafka里push数据，不管是kafka broker也好，还是一个配置也好，希望做到动态更新，不需要reload openresty。尤其是针对接口调用的认证，配置很少，如果每次都去redis或mysql中去取感觉也没有必要，直接用lua做配置表无疑性能提高不少。再说kafka broker问题，虽说producer会感知到broker的增加(http://blog.csdn.net/liuzhenfeng/article/details/50688842)，但如果写在配置的那个默认的broker不可用，这就有点尴尬了，有可能业务重启了，还需要修改配置文件；或通过服务注册重新发现新的可用broker。

到最后还是跑到了服务注册与发现的问题，可以通过consul,zookeeper或etcd实现，下面是我在openresty+consul实现的动态配置更新。

原理很简单，在openresty通过长轮训和版本号及时获取consul的kv store变化。consul提供了time_wait和修改版本号概念，如果consul发现该kv没有变化就会hang住这个请求5分钟，在这５分钟内如果有任何变化都会及时返回结果。通过比较版本号我们就知道是超时了还是kv的确被修改了。其实原理和上一篇nginx upsync一样(http://blog.csdn.net/yueguanghaidao/article/details/52801043)

consul的node和service也支持阻塞查询，相对来说用service更好一点，毕竟支持服务的健康检查。阻塞api和kv一样，加一个index就好了

curl “172.20.20.10:8500/v1/catalog/nodes?index=4”

代码如下:

local json = require "cjson"
local http = require "resty.http"

-- consul watcher
-- 设置key
-- curl -X PUT http://172.20.20.10:8500/v1/kv/broker/kafka/172.20.20.11:8080
--
-- 获取所有前缀key
-- curl http://172.20.20.10:8500/v1/kv/broker/kafka/?recurse
-- [{"LockIndex":0,"Key":"broker/kafka/172.20.20.11:8080","Flags":0,"Value":null,"CreateIndex":34610,"ModifyIndex":34610}]
--
-- 获取所有key,index大于34610版本号(当有多个key时需要获取最大版本号)
-- 没有更新,consul阻塞5分钟
-- curl "http://172.20.20.10:8500/v1/kv/broker/kafka/?recurse&index=34610"

local cache