Openresty(二十一)ngx.balance和balance_by_lua灰度发布

一  openresty实现灰度发布

①  灰度发布

说明： '早期'博客对'灰度'发布的'概念'进行解读,并且对'原生 nginx'灰度实现进行讲解

后续： 主要拿'节点引流'的灰度发布,并且关注'gray灰度策略'

相关借鉴

②  回顾HTTP反向代理流程

ngx_http_upstream

可'操作'点：根据'负载均衡策略'选择上游的服务器

  wrr               hash               least_conn              反向代理和负载均衡原理

③  指令

balance: '均衡'

说明： 只有下面'两个'指令,而不是'三个',没有'balancer_by_lua'指令

掌握： upstream {}、'balancer_by_lua_file'、'balancer_by_lua_block'

upstream

强调： upstream模块中'server配置的地址'不能用变量,只能为'ip'

balancer_by_lua_block

1、负载均衡器'结果'可以和'现有的nginx upstream模块'一起使用

常见： 'ngx_proxy'和'ngx_fastcgi'

2、'balancer_by_lua*'可以和'标准upstream连接池'机制一同工作

常见： 标准'keepalive'指令

注意： 确保keepalive 指令在一个单独的upstream{}配置块中的'balancer_by_lua_*'的后面

3、'balancer_by_lua*' 会完全'忽略'掉定义在upstream{}块中定义的'servers'列表

重点： 但是'server'指令必须存在,作为一个'placeholder'占位符存在,避免'nginx -t'报错

同俗理解：  openretry '优先走' balancer_by_lua 逻辑块

实质：通过lua-resty-core库中的'ngx.balancer'模块,从一个完全'动态'的server列表中'选择'

颗粒度：基于'每个请求'中

4、当nginx的upstream机制'重试'请求中指令指定的条件,如proxy_next_upstream指令

说明： 这个指令'注册的Lua代码'处理器可能在一个单独的'下游请求'中被调用'不止'一次

5、注意'事项'

  1) 这个上下文中执行的Lua代码并'不支持yielding'

  2) 所以可能yield的Lua APIs(例 cosockets和"light threads")在这个上下文中是'被禁用'

  3) 通过在'早期阶段'处理程序'如：access_by_lua*'处理这种操作和

  4) 通过'ngx.ctx 'table传递结果给这个上下文的解决方法可以'绕过'这个限制

balancer_by_lua_file

1、OpenResty 的 'balancer_by_lua' 指令让'动态负载均衡'成为可能

2、它'替代'了原生的 'hash/ip_hash/least_conn' 等算法

3、不仅可以让'自由定制'负载均衡策略，还可以随意'调整'后端服务器的数量

4、完全'超越'了 upstream 系列指令，实现了接近'商业版' Nginx Plus 的功能

+++++++++++++ "注意事项" +++++++++++++

1、'balancer_by_lua' 也是一个比较'特殊'的执行阶段

特点： 这里'不能'使用 'ngx.sleep'、'ngx.req.*' 或 'coocket'

补充： 同时应当尽量'避免'大计算量操作或磁盘读写,否则会导致'阻塞'

2、动态负载均衡使用的'服务器列表'通常'存储在外部'的 Redis '常见' 或 MySQL 里

备注： 由于'不能直接'使用 cosocker,所以在 'balancer_by_lua' 里也就'不能'操作这些服务器

解决： 但可以在'其他'的阶段'access_by_lua、ngx.timer[常见]'里 -->

访问服务器获取'列表'、解析'域名'，然后放在 'ngx.ctx' 或全局模块里'传递'过来

k8s nginx ingress动态更新原理

③  ngx.balance

​lua-resty-core 模块 '提供' ngx.balancer

1、这'四'个函数的的'用法'都很'简单'

2、动态负载均衡的'重点'其实是服务器'列表的维护'和'选择算法'

备注：这些工作通常应该在 'balancer_by_lua' 之'外'完成,ngx.balancer 只是最后的'执行者'

set_current_peer     nginx转发实现过程中的问题总结

最佳实践： balancer.set_current_peer用于设置后端的'地址'与'端口'

balancer中只能'设置ip',不'支持'直接设置域名,

思考： 如何解决'DNS'解析问题?

  1、host中的域名'不起'作用,'可以'使用'lua-resty-dns'解析域名,然后获取'解析'结果

  2、可以在'access_by_lua*阶段'解析域名,总之要在'upstream'之前'解析'域名

  例如：这里是在rewrite阶段,从'请求信息'中读取出了'关键'信息,做了一次DNS解析再'设置'进去的

set_more_tries

set_more_tries：设置连接'失败'后的'重试'次数

balancer.set_more_tries不能超过proxy_next_upstream_tries

推荐： 用'ngx.ctx.tries'记录进入balancer.lua的'次数',超过设置的重试次数直接给错误响应码

get_last_failure

get_last_failure：获取'上一次连接失败'的具体'原因'

注意： state_name '和' status_code  返回值的'含义'

set_timeouts

recreate_request

相关参考

④  案例讲解

1： 简单'案例'

if not ok then --> 检查'是否'设置成功,代码要'健壮'

第三方lua-resty-balance