Spring Cloud Zuul的一个坑

Spring Cloud 版本：

Dalston.SR5

今天使用Zuul发现一个和动态刷新相关的问题，动态刷新使用的是 /bus/refresh，即我的Zuul连着一个Rabbitmq，我这里是使用的总线刷新的方式，普通的刷新/refresh应该也是可以再现这个坑的。

我一共有两个服务，服务名分别为one和all，刷新之前的路由规则：

zuul:
  ribbonIsolationStrategy: THREAD
  retryable: true
  add-host-header: true
  servlet-path: /zuul/*
  prefix: /test
  routes:
#规则
    n1:
      path: /*
      serviceId: all

改为：

zuul:
  ribbonIsolationStrategy: THREAD
  retryable: true
  add-host-header: true
  servlet-path: /zuul/*
  prefix: /test
  routes:
#规则
    n0:
      path: /one
      serviceId: one
    n1:
      path: /*
      serviceId: all

加了个n0的规则，并且放在了n1前边，按说刷新之后，如果访问/test/one，那么应该会由服务【one】来出来，而非服务【all】，结果却是仍然会交由服务【all】来处理。

很坑是不是，我觉得这是个BUG，目前我还没有研究源码，但是通过实验得出了几个结论，并且也有了一个不用修改源码的解决方案，详情如下：

先说结论：

通过动态刷新的配置，对于路由规则的变动，只能新增和修改，不能删除；并且新增的规则在匹配顺序上，位于老规则的后边，也就是说，一旦你老规则里配置了个/*，那么后边的新规则你怎么改都不能生效，仍然会路由到/*对应的服务上。

再说解决办法：

借助上边描述的规则，我们可以将配置规则换一种写法再刷新进去，新的写法如下：

zuul:
  ribbonIsolationStrategy: THREAD
  retryable: true
  add-host-header: true
  servlet-path: /zuul/*
  prefix: /test
  routes:
#规则
    n1:
      path: /one
      serviceId: one
    n2:
      path: /*
      serviceId: all

这里修改了n1，然后新增了n2，巧妙的借助这个规则完成了，让/one路由到服务【one】上，其他规则还继续让服务【all】来处理。

这中解决方式，感觉还是不完美，后续我们可以通过修改源码，或者关注社区的方式，纠正这个坑（BUG）。