dubbo的路由规则，是基于invoker集合进行筛选，过滤出可用的invoker集合用于后续的执行。
网关黑白名单场景如下所示：
黑白名单的数据来源一般分两类，一类是静态内置，如：
- 来自某个网段的请求加入黑名单
- 来自预设的指定IP列表的请求加入黑名单
第二类是动态列表，比如来自flink按时间区间动态计算的阈值计算出来的清单，如：
- 按IP在10s内的访问频次阈值
- 按用户id在30s内的访问频次阈值
在dubbo网关下，黑白名单场景却不适合使用dubbo的路由规则来执行，以常用的ConditionRouter来解释。
从ConditionRouter的matchCondition方法可以得知，规则的定义，来自router配置，规则匹配的数据参数则来自consumer&provider的url。基于url就存在一个严重的问题，即受限于数据量&刷新成本。
在黑白名单场景下，规则的命中规模可膨胀，可收缩，也可以剧烈变化。如果使用dubbo的条件路由，则会面临url剧烈变化导致同步成本剧增，url膨胀导致同步效率极差。
针对这种情况，可以自定义router实现，不从url获取参数与值，仅根据调用上下文来获取数据。
从源码角度来看，router的触发有2个地方。其一是在RegistyDirectory在收到url更新时触发的刷新invoker来触发的，其二是在Directory的list时会对提取到的invoker集合进行router处理。故，可以自定义一个router实现，在这一个环节进行黑白名单处理。
但是，实际场合，一般不会通过这种方式来处理，网关实现时，目前依赖的是spring webFlux框架，在接入http请求时，可以扩展filter来支持，并不需要下层到dubbo的执行层面由路由来支持。当然，如果是dubbo直接对外另说。
网关灰度路由的场景：
灰度路由一般是某个应用的某个url基于一定的条件定向转发请求到指定机器上。
这种情况下，路由规则也可以以筛选器的身份参与进来。