周6参加华东运维大会，听了人家淘宝用nginx的一些场景，其中AB的灰度测试可能适用场景会比较普遍，当然大会上，并没有详细讨论实现。

大概需求是： 网站类业务在更新new feature时，并不想让全量用户看到，可以针对地区性用户开放此feature

大概构思了一个方式，使用 nginx+redis/memcache+IP库实现，简单的流程图如下：

当然其中的new feature server和normal server不必要一定得是物理上的服务器，可以是任意逻辑上分开的服务和http URI

所用的模块是 ngx-lua-module, 以及一个基于ngx-lua写的lib:  lua-resty-memcached或lua-resty-redis, 这里假设使用memcached作为ip数据的存储，cache内保存以ip作为key，以true(1)或false(0)作为value的数据，nginx在请求到来时，从cache内以remote_addr(如果是用XFF头，则对XFF做一次处理后获取到real ip)作为key从cache内做一次get，判断此req应该的转发；

这里有一个问题是：cache内是保存具体的IP形式的方式，还是以CIDR的超网形势存储，若直接使用IP作为key，数据量不容小视，而且IP信息的准确度得有一定的保证才行；若使用CIDR的方式，则在nginx端又会增加一次IP转换CIDR以及对get到的CIDR做比较(具体实现方法还没想到)， 复杂度会有所增加，个人偏向直接使用IP作为key，只要保证了IP的一定准确性，数据大小问题不大，现在遍地都是32G，64G内存的缓存。

若使用ip作为key，一个折中的办法是每次进行ABtest的时候，flush缓存，只保存指定地区的ip数据即可，ngx在做get的时候，如果没有返回，则认为此req是到normal server的.

管理平台方面，只需要做个简单的批量set缓存的功能就可以了，至于UI么，就看你给谁用了，自己用嘛，UI丑陋点就丑陋点了

性能和可用性方面：

增加了一次缓存的连接和get操作，理论上此开销应该是很小的，ngx-lua实现的lua-resty-memcached有不少人做过测试，性能非常可观.

可用性方面会增加一个当缓存断线的风险点，通过settimeout，将缓存超时限制到一个较小的时间，影响较小，另外ABtest的方案也不应该常年累月的在线上，只有在有需求时，才需要这套系统吧，因此可用性方面对全局影响应该是较小的，相比新的feature上线时影响全部用户的风险，这个冒险还是值得的。

上述暂时只是个人的思路，而且也还没上线使用，实现方面只完成了nginx获取key来判断req转发的验证，针对此方式也未做过详细压力测试，抛砖引玉，有好的方式欢迎讨论.