<h3 id="导言"><a href="https://fankeke.github.io/#%E5%AF%BC%E8%A8%80" class="headerlink" title="导言"></a>导言</h3><p>为了在接入层面做到对请求精细化的控制和导流,需要在nginx上做分流的工作,解决包括但不限于几种需求,如版本上线,灰度发布、特殊用户,特殊版本等。其工作流程如下:</p>

在业务侧,可以根据需求将其业务节点划分为组,可以按照自己定制的策略来反馈给nginx,根据需求来导流相应分组。

NGINX+Lua实现

方案预期

在到达分流目的同时,需要有到达其它几个目的:
1 配置方便,兼容其它功能
如果某个服务需要接入分流系统,SRE可以清晰清楚且便捷的配置即可,不会影响其它的功能,不需要有其它冗余的操作或交流。

2 提供降级开关
响应业务需求,SRE或者业务需求发能够方便地选择开启或者关闭某个分流需求,甚至不需要对nginx做重启操作

3 即配即走,不重启NGINX
我们希望能够到达即配即走的效果,不重启NGINX。(当然接入分流系统时配置文档的变更,SRE需要重启)
(事实上如果业务接入了其它lua的功能,那么连配置都不用更改,直接走新的Lua框架即可生效)

4 系统轻巧,耦合度低
希望将系统做的足够轻巧,能够掌握整改分流过程和生效过程,方便及时排查问题,不影响其它业务。

5 高容错性
系统不应该对请求有伤害,包括系统不可用时、分流集群不合法时等意外情况下,都要保重请求的正常。

6 流量统计
能够从对分流情况有明确的感知和了解,包括每个分流集群的qps、响应时间等。

方案设计

方案架构

为了达到上面几个目的,构件了一套轻巧的系统。核心思想为表驱动的方式:以业务的appkey为索引,通过查表找出该业务需要分流的策略,将具体分流策略下放,加载策略进行分流。

在请求来临时,取出appkey,查找分流数据,执行分流策略。每个不同的分流逻辑在不同的分流文档里面完成。
该表时刻处于变化中,从第三方存储中定时加载到nginx共享内存。其分流流程如下:

分流数据的更新逻辑如下:
方案一:

当管理机把更新的表推送到redis后,每个nginx会从redis里面定时拉取该表,缓存入nginx的共享内存。
该方案优势:
1 每个分流的Nginx都可以自己拉取,只要有定时拉取的逻辑
存在的问题:
1 单个worker拉取,需要patch tengine源码,担心会造成问题
2 每个nginx定时轮询,且定时时间短

方案二:

通过http接口,在每次数据真正变更时候走http来更新每个分流nginx的内存,并将最新的一份数据存储在redis里面容灾。
优势:
1 不用定时器,即不需patch源码
2 在数据真正变动时进行更新,没有无谓轮询。