个人觉得按照自己的场景诉求，选择最适合的组合就好了，不一定要强求某个模块来完成你要的所有事情。
比如我之前做的动态路由场景，就要求后端服务器信息都是动态获取的，所以最初我选择lua_resty_http的方式，但事实上cosocket来做全量请求的转发，性能，功能上表现都不够好。何况LuaJIT还有内存使用限制。
于是我转成了使用ngx_http_dyups_module动态生成upstream，然后用proxy_pass转出去，但总觉得不太优雅。
在balancer_by_lua发布后，我就有了更好的选择了，只需配置一个upstream，然后balancer阶段动态的修改后端地址即可。
动态路由的场景下，负载均衡自己写就很正常了，而且这个工作量其实很小；
在 2016年5月20日星期五 UTC+8下午5:41:20，bigplum写道：
用lua-resty-
http面临的问题就是不支持后端多个服务器负载均衡，需要自己写逻辑实现。
既然nginx已经提供了upstream这种方式，拿过来用就很正常了。
用upstream还能让lua访问的后端服务器和nginx转
发的服务器保持一致，而不会出现相同的服务器组在多个地方重复配置的情况。
On Wednesday, May 11, 2016 at 6:48:37 PM UTC+8, Guanglin Lv wrote:
既然使用了upstream为啥不直接用proxy_pass，而要去使用lua-resty-http呢？
反之亦然，既然要使用lua-resty-http何必使用upstream呢？
在 2016年5月11日星期三 UTC+8下午3:26:45，bigplum写道：
lua-resty-http 模块不支持后端服务器负载均衡，就需要自己写逻辑实现。
这个逻辑其实可以放到 lua-upstream-nginx-module 中统一实现，提供一
个获取get_server的接口，在请求后端http时，调用get_server获取到一个
可用ip，然后再发起http请求。
目前
这两个都是获取所有的服务器。
