nginx upstream列表是否可以动态加载

lxxstcno1 · 2015-07-29T00:49:23+00:00

Hello! 2015-07-28 13:11 GMT+08:00 yangzhenzhen: > 您好： > 我在使用resty-cli的时候&#xFF0...

nginx upstream列表是否可以动态加载

lxxstcno1

先描述一下问题背景：
最近在用mesos+marathon做可伸缩服务。
mesos在提高资源利用率，快速build应用服务等方面优势明显
但是在如何统一服务入口方面非常弱，虽然有官方推出了mesosdns，或者第三方提供的bamboo（haproxy+zk+自定义任务提交server），但是还是存在不够高效和实时的问题。

    所以我们采用了openresty+泛域名作为marathon服务暴露的方案，使用lua从marahthon获取服务地址，再把请求proxy_pass到marathon启动的上游服务中。
    但是，目前我们只处理了上游只有一个服务实例的状况。当有多个实例时，我们没有处理。
    所以我的问题是：是否有方法动态加载upstream列表？满足负载均衡和ha的需要

easedays

https://github.com/openresty/lua-upstream-nginx-module/issues/1 可以跟踪这个issue的动态，不知道这个feature合适能够发布。

2015-07-29 0:49 GMT+08:00 吕晓旭 <lxxs...@gmail.com>:

先描述一下问题背景：
最近在用mesos+marathon做可伸缩服务。
mesos在提高资源利用率，快速build应用服务等方面优势明显
但是在如何统一服务入口方面非常弱，虽然有官方推出了mesosdns，或者第三方提供的bamboo（haproxy+zk+自定义任务提交server），但是还是存在不够高效和实时的问题。

    所以我们采用了openresty+泛域名作为marathon服务暴露的方案，使用lua从marahthon获取服务地址，再把请求proxy_pass到marathon启动的上游服务中。
    但是，目前我们只处理了上游只有一个服务实例的状况。当有多个实例时，我们没有处理。
    所以我的问题是：是否有方法动态加载upstream列表？满足负载均衡和ha的需要

--

membphis

四月份qcon大会碰面的时候，春哥就提及这个功能。已经实现，只是觉得不够完美。

很快就会放出来。

2015-07-29 10:14 GMT+08:00 Zhang Xiangjun <eas...@gmail.com>:

https://github.com/openresty/lua-upstream-nginx-module/issues/1 可以跟踪这个issue的动态，不知道这个feature合适能够发布。

2015-07-29 0:49 GMT+08:00 吕晓旭 <lxxs...@gmail.com>:
先描述一下问题背景：
最近在用mesos+marathon做可伸缩服务。
mesos在提高资源利用率，快速build应用服务等方面优势明显
但是在如何统一服务入口方面非常弱，虽然有官方推出了mesosdns，或者第三方提供的bamboo（haproxy+zk+自定义任务提交server），但是还是存在不够高效和实时的问题。

    所以我们采用了openresty+泛域名作为marathon服务暴露的方案，使用lua从marahthon获取服务地址，再把请求proxy_pass到marathon启动的上游服务中。
    但是，目前我们只处理了上游只有一个服务实例的状况。当有多个实例时，我们没有处理。
    所以我的问题是：是否有方法动态加载upstream列表？满足负载均衡和ha的需要

--

--

Membhis

My github: https://github.com/membphis

Our Book: OpenResty Best Practices

lxxstcno1

@agentzh 急需这个功能，什么时候能放出来呀？

在 2015年7月29日上午11:21，YuanSheng Wang <mem...@gmail.com>写道：

四月份qcon大会碰面的时候，春哥就提及这个功能。已经实现，只是觉得不够完美。

很快就会放出来。

2015-07-29 10:14 GMT+08:00 Zhang Xiangjun <eas...@gmail.com>:
https://github.com/openresty/lua-upstream-nginx-module/issues/1 可以跟踪这个issue的动态，不知道这个feature合适能够发布。

2015-07-29 0:49 GMT+08:00 吕晓旭 <lxxs...@gmail.com>:
先描述一下问题背景：
最近在用mesos+marathon做可伸缩服务。
mesos在提高资源利用率，快速build应用服务等方面优势明显
但是在如何统一服务入口方面非常弱，虽然有官方推出了mesosdns，或者第三方提供的bamboo（haproxy+zk+自定义任务提交server），但是还是存在不够高效和实时的问题。

    所以我们采用了openresty+泛域名作为marathon服务暴露的方案，使用lua从marahthon获取服务地址，再把请求proxy_pass到marathon启动的上游服务中。
    但是，目前我们只处理了上游只有一个服务实例的状况。当有多个实例时，我们没有处理。
    所以我的问题是：是否有方法动态加载upstream列表？满足负载均衡和ha的需要

--

--

--

Membhis
My github: https://github.com/membphis
Our Book: OpenResty Best Practices

--

lihang_net

Hi，

您好，老师~ 首先非常感谢您抽时间看我这封邮件，我最近想基于redis 3.0做一个proxy，目前想用nginx upstream来做，(slot信息和对应的节点ip信息都是从redis里面拿出来，存储在nginx全局变量里面的)

但是nginx 里面upstream列表我想不要nginx upstream的配置，我想在启动的时候或者启动之后去动态的添加进去，这些信息ip列表或者在运行的时候动态的添加

我压根就不需要配置upstream指令~ 不知道这样可行吗？自己尝试了下，貌似不行，不知道您有什么好的建议~

我看这个模块ngx_http_dyups_module 好像是支持的，但是不知道能不能用于生产环境，希望春哥提供更简单方便的方式，

我想改改，改成适应于自己需求的简单的方式

在 2015年7月30日星期四 UTC+8下午2:00:01，xiaoxu写道：

@agentzh 急需这个功能，什么时候能放出来呀？

在 2015年7月29日上午11:21，YuanSheng Wang <memb...@gmail.com>写道：
四月份qcon大会碰面的时候，春哥就提及这个功能。已经实现，只是觉得不够完美。

很快就会放出来。

2015-07-29 10:14 GMT+08:00 Zhang Xiangjun <ease...@gmail.com>:
https://github.com/openresty/lua-upstream-nginx-module/issues/1 可以跟踪这个issue的动态，不知道这个feature合适能够发布。

2015-07-29 0:49 GMT+08:00 吕晓旭 <lxxs...@gmail.com>:
先描述一下问题背景：
最近在用mesos+marathon做可伸缩服务。
mesos在提高资源利用率，快速build应用服务等方面优势明显
但是在如何统一服务入口方面非常弱，虽然有官方推出了mesosdns，或者第三方提供的bamboo（haproxy+zk+自定义任务提交server），但是还是存在不够高效和实时的问题。

    所以我们采用了openresty+泛域名作为marathon服务暴露的方案，使用lua从marahthon获取服务地址，再把请求proxy_pass到marathon启动的上游服务中。
    但是，目前我们只处理了上游只有一个服务实例的状况。当有多个实例时，我们没有处理。
    所以我的问题是：是否有方法动态加载upstream列表？满足负载均衡和ha的需要

--

--

--

Membhis
My github: https://github.com/membphis
Our Book: OpenResty Best Practices

--

easedays

如果需要还是去github的issue上comment吧

2015-07-30 16:11 GMT+08:00 Lucien Li <liha...@126.com>:

Hi，
您好，老师~ 首先非常感谢您抽时间看我这封邮件，我最近想基于redis 3.0做一个proxy，目前想用nginx upstream来做，(slot信息和对应的节点ip信息都是从redis里面拿出来，存储在nginx全局变量里面的)
但是nginx 里面upstream列表我想不要nginx upstream的配置，我想在启动的时候或者启动之后去动态的添加进去，这些信息ip列表或者在运行的时候动态的添加
我压根就不需要配置upstream指令~ 不知道这样可行吗？自己尝试了下，貌似不行，不知道您有什么好的建议~
我看这个模块ngx_http_dyups_module 好像是支持的，但是不知道能不能用于生产环境，希望春哥提供更简单方便的方式，
我想改改，改成适应于自己需求的简单的方式

在 2015年7月30日星期四 UTC+8下午2:00:01，xiaoxu写道：
@agentzh 急需这个功能，什么时候能放出来呀？

在 2015年7月29日上午11:21，YuanSheng Wang <memb...@gmail.com>写道：
四月份qcon大会碰面的时候，春哥就提及这个功能。已经实现，只是觉得不够完美。

很快就会放出来。

2015-07-29 10:14 GMT+08:00 Zhang Xiangjun <ease...@gmail.com>:
https://github.com/openresty/lua-upstream-nginx-module/issues/1 可以跟踪这个issue的动态，不知道这个feature合适能够发布。

2015-07-29 0:49 GMT+08:00 吕晓旭 <lxxs...@gmail.com>:
先描述一下问题背景：
最近在用mesos+marathon做可伸缩服务。
mesos在提高资源利用率，快速build应用服务等方面优势明显
但是在如何统一服务入口方面非常弱，虽然有官方推出了mesosdns，或者第三方提供的bamboo（haproxy+zk+自定义任务提交server），但是还是存在不够高效和实时的问题。

    所以我们采用了openresty+泛域名作为marathon服务暴露的方案，使用lua从marahthon获取服务地址，再把请求proxy_pass到marathon启动的上游服务中。
    但是，目前我们只处理了上游只有一个服务实例的状况。当有多个实例时，我们没有处理。
    所以我的问题是：是否有方法动态加载upstream列表？满足负载均衡和ha的需要

--

--

--

Membhis
My github: https://github.com/membphis
Our Book: OpenResty Best Practices

--

--

agentzh

Hello!

2015-07-29 0:49 GMT+08:00 吕晓旭:
> 所以我们采用了openresty+泛域名作为marathon服务暴露的方案，使用lua从marahthon获取服务地址，再把请求proxy_pass到marathon启动的上游服务中。
>     但是，目前我们只处理了上游只有一个服务实例的状况。当有多个实例时，我们没有处理。
>     所以我的问题是：是否有方法动态加载upstream列表？满足负载均衡和ha的需要

我几个月前已经实现并测试通过了 balancer_by_lua 这个 ngx_lua 的新指令。届时你不仅可以在 Lua
里按请求级别动态生成后端 peer 的信息，还可以在 Lua
里面动态地为每个请求决定是否重试，如何重试，以及重试多少次等所有细节。简言之，你将可以用纯 Lua 编写 nginx upstream
模块的逻辑，而且更加灵活。

受公司开源策略的限制，这个特性的开源可能需要等到今年 9 月或者 10 月。

Regards,
-agentzh

lihang_net

春哥求开源啊，这么强大的功能nginx+lua 实现 upstream的功能~ 求开源，求开源，我这项目正好可以使用~

在 2015年7月31日星期五 UTC+8下午2:18:44，agentzh写道：

Hello!

2015-07-29 0:49 GMT+08:00 吕晓旭:
> 所以我们采用了openresty+泛域名作为marathon服务暴露的方案，使用lua从marahthon获取服务地址，再把请求proxy_pass到marathon启动的上游服务中。
> 但是，目前我们只处理了上游只有一个服务实例的状况。当有多个实例时，我们没有处理。
> 所以我的问题是：是否有方法动态加载upstream列表？满足负载均衡和ha的需要

我几个月前已经实现并测试通过了 balancer_by_lua 这个 ngx_lua 的新指令。届时你不仅可以在 Lua
里按请求级别动态生成后端 peer 的信息，还可以在 Lua
里面动态地为每个请求决定是否重试，如何重试，以及重试多少次等所有细节。简言之，你将可以用纯 Lua 编写 nginx upstream
模块的逻辑，而且更加灵活。

受公司开源策略的限制，这个特性的开源可能需要等到今年 9 月或者 10 月。

Regards,
-agentzh

aaashun

Hi,

动态加载upstream和ha这个问题, 可以这样来考虑:

1. 反向代理: 用nginx, haproxy等应该都能实现

2. 服务发现: 用ZK, Etcd等, 这里简称KV

3. 后端服务

后端服务启动时向zetcd注册自己的地址和负载能力等信息

反向代理服务监听KV上的事件, 据此添加或删除后端节点

这样可以做到动态加载, 服务发现, 后端也可以挂不同的服务.

这里的单点是角色1, 针对这个点做ha也很方便

balancer_by_lua指令听起来更简捷, 应该是复用了角色1和2, 等春哥释放出来时再确认一下.

Best regards

On Friday, July 31, 2015 at 5:32:27 PM UTC+8, Lucien Li wrote:

春哥求开源啊，这么强大的功能nginx+lua 实现 upstream的功能~ 求开源，求开源，我这项目正好可以使用~

在 2015年7月31日星期五 UTC+8下午2:18:44，agentzh写道：
Hello!

2015-07-29 0:49 GMT+08:00 吕晓旭:
> 所以我们采用了openresty+泛域名作为marathon服务暴露的方案，使用lua从marahthon获取服务地址，再把请求proxy_pass到marathon启动的上游服务中。
> 但是，目前我们只处理了上游只有一个服务实例的状况。当有多个实例时，我们没有处理。
> 所以我的问题是：是否有方法动态加载upstream列表？满足负载均衡和ha的需要

我几个月前已经实现并测试通过了 balancer_by_lua 这个 ngx_lua 的新指令。届时你不仅可以在 Lua
里按请求级别动态生成后端 peer 的信息，还可以在 Lua
里面动态地为每个请求决定是否重试，如何重试，以及重试多少次等所有细节。简言之，你将可以用纯 Lua 编写 nginx upstream
模块的逻辑，而且更加灵活。

受公司开源策略的限制，这个特性的开源可能需要等到今年 9 月或者 10 月。

Regards,
-agentzh

lxxstcno1

牛逼，翘首期待中。。

Yichun Zhang (agentzh) <age...@gmail.com>于2015年7月31日星期五写道：

Hello!

2015-07-29 0:49 GMT+08:00 吕晓旭:
> 所以我们采用了openresty+泛域名作为marathon服务暴露的方案，使用lua从marahthon获取服务地址，再把请求proxy_pass到marathon启动的上游服务中。
> 但是，目前我们只处理了上游只有一个服务实例的状况。当有多个实例时，我们没有处理。
> 所以我的问题是：是否有方法动态加载upstream列表？满足负载均衡和ha的需要

我几个月前已经实现并测试通过了 balancer_by_lua 这个 ngx_lua 的新指令。届时你不仅可以在 Lua
里按请求级别动态生成后端 peer 的信息，还可以在 Lua
里面动态地为每个请求决定是否重试，如何重试，以及重试多少次等所有细节。简言之，你将可以用纯 Lua 编写 nginx upstream
模块的逻辑，而且更加灵活。

受公司开源策略的限制，这个特性的开源可能需要等到今年 9 月或者 10 月。

Regards,
-agentzh

lxxstcno1

服务注册中心少不了，即使有了balancer_by_lua模块。mesos marathon自带服务注册和rest API，和openresty绝配

aaashun <aaa...@gmail.com>于2015年7月31日星期五写道：

Hi,

动态加载upstream和ha这个问题, 可以这样来考虑:

1. 反向代理: 用nginx, haproxy等应该都能实现
2. 服务发现: 用ZK, Etcd等, 这里简称KV
3. 后端服务

后端服务启动时向zetcd注册自己的地址和负载能力等信息
反向代理服务监听KV上的事件, 据此添加或删除后端节点

这样可以做到动态加载, 服务发现, 后端也可以挂不同的服务.
这里的单点是角色1, 针对这个点做ha也很方便

balancer_by_lua指令听起来更简捷, 应该是复用了角色1和2, 等春哥释放出来时再确认一下.

Best regards
On Friday, July 31, 2015 at 5:32:27 PM UTC+8, Lucien Li wrote:
春哥求开源啊，这么强大的功能nginx+lua 实现 upstream的功能~ 求开源，求开源，我这项目正好可以使用~

在 2015年7月31日星期五 UTC+8下午2:18:44，agentzh写道：
Hello!

2015-07-29 0:49 GMT+08:00 吕晓旭:
> 所以我们采用了openresty+泛域名作为marathon服务暴露的方案，使用lua从marahthon获取服务地址，再把请求proxy_pass到marathon启动的上游服务中。
> 但是，目前我们只处理了上游只有一个服务实例的状况。当有多个实例时，我们没有处理。
> 所以我的问题是：是否有方法动态加载upstream列表？满足负载均衡和ha的需要

我几个月前已经实现并测试通过了 balancer_by_lua 这个 ngx_lua 的新指令。届时你不仅可以在 Lua
里按请求级别动态生成后端 peer 的信息，还可以在 Lua
里面动态地为每个请求决定是否重试，如何重试，以及重试多少次等所有细节。简言之，你将可以用纯 Lua 编写 nginx upstream
模块的逻辑，而且更加灵活。

受公司开源策略的限制，这个特性的开源可能需要等到今年 9 月或者 10 月。

Regards,
-agentzh

easedays

我等不及春哥的这个新feather了，自己实现了一个比较简陋的版本https://github.com/xdays/docker-dlb，和@aaashun的思路类似。

总体上说，就是写个脚本包装起来程序，自动生成nginx配置。具体说，启动监听Docker Engine的事件，捕捉启动和关闭事件，然后从Docker容器的环境变量提取需要的信息存入etcd做持久化，然后将信息灌入模板生成nginx配置，然后reload nginx进程。

2015-08-03 10:27 GMT+08:00 吕晓旭 <lxxs...@gmail.com>:

服务注册中心少不了，即使有了balancer_by_lua模块。mesos marathon自带服务注册和rest API，和openresty绝配

aaashun <aaa...@gmail.com>于2015年7月31日星期五写道：

Hi,

动态加载upstream和ha这个问题, 可以这样来考虑:

1. 反向代理: 用nginx, haproxy等应该都能实现
2. 服务发现: 用ZK, Etcd等, 这里简称KV
3. 后端服务

后端服务启动时向zetcd注册自己的地址和负载能力等信息
反向代理服务监听KV上的事件, 据此添加或删除后端节点

这样可以做到动态加载, 服务发现, 后端也可以挂不同的服务.
这里的单点是角色1, 针对这个点做ha也很方便

balancer_by_lua指令听起来更简捷, 应该是复用了角色1和2, 等春哥释放出来时再确认一下.

Best regards
On Friday, July 31, 2015 at 5:32:27 PM UTC+8, Lucien Li wrote:
春哥求开源啊，这么强大的功能nginx+lua 实现 upstream的功能~ 求开源，求开源，我这项目正好可以使用~

在 2015年7月31日星期五 UTC+8下午2:18:44，agentzh写道：
Hello!

2015-07-29 0:49 GMT+08:00 吕晓旭:
> 所以我们采用了openresty+泛域名作为marathon服务暴露的方案，使用lua从marahthon获取服务地址，再把请求proxy_pass到marathon启动的上游服务中。
> 但是，目前我们只处理了上游只有一个服务实例的状况。当有多个实例时，我们没有处理。
> 所以我的问题是：是否有方法动态加载upstream列表？满足负载均衡和ha的需要

我几个月前已经实现并测试通过了 balancer_by_lua 这个 ngx_lua 的新指令。届时你不仅可以在 Lua
里按请求级别动态生成后端 peer 的信息，还可以在 Lua
里面动态地为每个请求决定是否重试，如何重试，以及重试多少次等所有细节。简言之，你将可以用纯 Lua 编写 nginx upstream
模块的逻辑，而且更加灵活。

受公司开源策略的限制，这个特性的开源可能需要等到今年 9 月或者 10 月。

Regards,
-agentzh

--

freelingchang

我现在的思路是完全抛弃nginx 自带的upstream,自己来实现这部分的功能。比如 proxy_pass http://$myself_upstream ;然后lua 从redis取出server 列表缓存5秒钟，用轮询的方式返回server地址。后面再把存活检测，重试机制加进去。你这个生成静态配置文件reload的方式有点土，特别是高并发的情况下...

在 2015年8月3日星期一 UTC+8下午10:22:55，Zhang Xiangjun写道：

我等不及春哥的这个新feather了，自己实现了一个比较简陋的版本https://github.com/xdays/docker-dlb，和@aaashun的思路类似。

总体上说，就是写个脚本包装起来程序，自动生成nginx配置。具体说，启动监听Docker Engine的事件，捕捉启动和关闭事件，然后从Docker容器的环境变量提取需要的信息存入etcd做持久化，然后将信息灌入模板生成nginx配置，然后reload nginx进程。

2015-08-03 10:27 GMT+08:00 吕晓旭 <lxxs...@gmail.com>:
服务注册中心少不了，即使有了balancer_by_lua模块。mesos marathon自带服务注册和rest API，和openresty绝配

aaashun <aaa...@gmail.com>于2015年7月31日星期五写道：

Hi,

动态加载upstream和ha这个问题, 可以这样来考虑:

1. 反向代理: 用nginx, haproxy等应该都能实现
2. 服务发现: 用ZK, Etcd等, 这里简称KV
3. 后端服务

后端服务启动时向zetcd注册自己的地址和负载能力等信息
反向代理服务监听KV上的事件, 据此添加或删除后端节点

这样可以做到动态加载, 服务发现, 后端也可以挂不同的服务.
这里的单点是角色1, 针对这个点做ha也很方便

balancer_by_lua指令听起来更简捷, 应该是复用了角色1和2, 等春哥释放出来时再确认一下.

Best regards
On Friday, July 31, 2015 at 5:32:27 PM UTC+8, Lucien Li wrote:
春哥求开源啊，这么强大的功能nginx+lua 实现 upstream的功能~ 求开源，求开源，我这项目正好可以使用~

在 2015年7月31日星期五 UTC+8下午2:18:44，agentzh写道：
Hello!

2015-07-29 0:49 GMT+08:00 吕晓旭:
> 所以我们采用了openresty+泛域名作为marathon服务暴露的方案，使用lua从marahthon获取服务地址，再把请求proxy_pass到marathon启动的上游服务中。
> 但是，目前我们只处理了上游只有一个服务实例的状况。当有多个实例时，我们没有处理。
> 所以我的问题是：是否有方法动态加载upstream列表？满足负载均衡和ha的需要

我几个月前已经实现并测试通过了 balancer_by_lua 这个 ngx_lua 的新指令。届时你不仅可以在 Lua
里按请求级别动态生成后端 peer 的信息，还可以在 Lua
里面动态地为每个请求决定是否重试，如何重试，以及重试多少次等所有细节。简言之，你将可以用纯 Lua 编写 nginx upstream
模块的逻辑，而且更加灵活。

受公司开源策略的限制，这个特性的开源可能需要等到今年 9 月或者 10 月。

Regards,
-agentzh

--

qiujinhan

春哥你好~ 这个特性的开源没有哇？

在 2015年7月31日星期五 UTC+8下午2:18:44，agentzh写道：

Hello!

2015-07-29 0:49 GMT+08:00 吕晓旭:
> 所以我们采用了openresty+泛域名作为marathon服务暴露的方案，使用lua从marahthon获取服务地址，再把请求proxy_pass到marathon启动的上游服务中。
> 但是，目前我们只处理了上游只有一个服务实例的状况。当有多个实例时，我们没有处理。
> 所以我的问题是：是否有方法动态加载upstream列表？满足负载均衡和ha的需要

我几个月前已经实现并测试通过了 balancer_by_lua 这个 ngx_lua 的新指令。届时你不仅可以在 Lua
里按请求级别动态生成后端 peer 的信息，还可以在 Lua
里面动态地为每个请求决定是否重试，如何重试，以及重试多少次等所有细节。简言之，你将可以用纯 Lua 编写 nginx upstream
模块的逻辑，而且更加灵活。

受公司开源策略的限制，这个特性的开源可能需要等到今年 9 月或者 10 月。

Regards,
-agentzh

agentzh

Hello!

2015-10-12 11:04 GMT+08:00 jinhan qiu:
> 春哥你好~  这个特性的开源没有哇？
>

还没有。但会在近期开源。

Regards,
-agentzh

qiujinhan

狂赞！谢谢春哥，非常期待哇~

在 2015年10月12日星期一 UTC+8下午12:35:57，agentzh写道：

Hello!

2015-10-12 11:04 GMT+08:00 jinhan qiu:
> 春哥你好~ 这个特性的开源没有哇？
>

还没有。但会在近期开源。

Regards,
-agentzh