Spring Cloud 版本：
Dalston.SR5
今天使用Zuul发现一个和动态刷新相关的问题，动态刷新使用的是 /bus/refresh，即我的Zuul连着一个Rabbitmq，我这里是使用的总线刷新的方式，普通的刷新/refresh应该也是可以再现这个坑的。
我一共有两个服务，服务名分别为one和all，刷新之前的路由规则：
<pre>zuul:
ribbonIsolationStrategy: THREAD
retryable: true
add-host-header: true
servlet-path: /zuul/*
prefix: /test
routes: #规则
n1: path: /*
serviceId: all</pre>改为：
<pre>zuul:
ribbonIsolationStrategy: THREAD
retryable: true
add-host-header: true
servlet-path: /zuul/*
prefix: /test
routes: #规则
n0: path: /one
serviceId: one
n1: path: /*
serviceId: all</pre>加了个n0的规则，并且放在了n1前边，按说刷新之后，如果访问/test/one，那么应该会由服务【one】来处理，而非服务【all】，结果却是仍然会交由服务【all】来处理。
很坑是不是，我觉得这是个BUG，目前我还没有研究源码，但是通过实验得出了几个结论，并且也有了一个不用修改源码的解决方案，详情如下：
先说结论：
*通过动态刷新的配置，对于路由规则的变动，只能新增和修改，不能删除；并且新增的规则在匹配顺序上，位于老规则的后边，也就是说，一旦你老规则里配置了个/*，那么后边的新规则你怎么改都不能生效，仍然会路由到/对应的服务上。
再说解决办法：
借助上边描述的规则，我们可以将配置规则换一种写法再刷新进去，新的写法如下：
<pre>zuul:
ribbonIsolationStrategy: THREAD
retryable: true
add-host-header: true
servlet-path: /zuul/*
prefix: /test
routes: #规则
n1: path: /one
serviceId: one
n2: path: /*
serviceId: all</pre>这里修改了n1，然后新增了n2，巧妙的借助这个规则完成了，让/one路由到服务【one】上，其他规则还继续让服务【all】来处理。
经过调查发现：
zuul获取路由规则的时候，会从所有路由规则中选择第一个能正则匹配的，用来处理当前的请求，接着，我们需要看看刷新之后配置的顺序是不是有问题。
这里看到顺序是按照配置文件的顺序进行加载，应该是没有问题的，结果发现配置文件的顺序并不能保证。这里我们先不去管为什么顺序不能保证了，因为需要牵扯大量的refresh端点事件、配置中心相关代码。
这里根据我们的需求直接决定改成优先精确匹配，精确匹配失败再正则匹配即可，修改后：
修改非常简单，重在调查问题的过程。
如果你想调查配置中心相关代码，这里给个思路，或许有所帮助：
调用/bus/refresh时候走了这段。
继续跟进代码。
属性对比的完整截图，两个Map，一个是之前的配置内容，一个是修改后的配置内容，最终结果是对比得出的两者的不同点。
广播了属性替换事件，具体广播的处理者在哪又得跟源码了，时间有限，就写到这里吧。
今天又发现一个新的坑，也是和上文同一个原因所致。
之前的结论：
*通过动态刷新的配置，对于路由规则的变动，只能新增和修改，不能删除；并且新增的规则在匹配顺序上，位于老规则的后边，也就是说，一旦你老规则里配置了个/*，那么后边的新规则你怎么改都不能生效，仍然会路由到/对应的服务上。
现在发现同一个路由规则的变动也是适用的，也就是说，如果你之前配了一个路由规则：
<pre>zuul:
routes:
route1:
path: /a/** **url: http://URL/PATH/**</pre>将所有/a/xxx的请求交给下边这个url处理，之后你通过配刷新的方式改为了：
<pre>zuul:
routes:
route1:
path: /a/** **serviceId: service1**</pre>是没有效果的，所有/a/xxx的请求还是会被之前那个url处理。
正确的姿势是改为：
<pre>zuul:
routes:
route1:
path: /a/** serviceId: service1
url: </pre>再刷新配置。
总结一下原因：
1、配置刷新目前存在问题无法删除已有的路由规则，只能修改已有规则和新增规则。
2、在路由的serviceId和url同时存在的时候，会以url为准，只有url为空的时候才会交给serviceId来处理。
该问题在
Edgware.SR3
版本中，仍然未得到解决。也许我该转向spring cloud gateway了
