ps:我们使用了动态路由，如果不是动态路由(使用静态文件的配置文件)，也是符合本文的逻辑.
一 对当前网关的路由解析的分析
跟踪代码发现zuul目前支持的路由解析策略对url的匹配的格式应该是
/url/** ，其中**号不支持出现多次，
1.class DiscoveryClientRouteLocator
2 class ZuulProperties
@Data
@NoArgsConstructor
public static class ZuulRoute {
/**
* The ID of the route (the same as its map key by default).
*/
private String id;
/**
* The path (pattern) for the route, e.g. /foo/**.
//这里只能有一个** 并且测试发现不是* 要两个*
*/
private String path;
/**
* The service ID (if any) to map to this route. You can specify a physical URL or
* a service, but not both.
*/
private String serviceId;
二 目前网关路由对url匹配的一些扩展测试
比如对于数据库的路由表
(使用静态路由的话，和这个表效果一样)
比如我之前使用过的静态文件配置路径的一个小例子
zuul.routes.api-a.path=/api-a/** zuul.routes.api-a.serviceId=client-ribbon zuul.routes.api-b.path=/api-b/** zuul.routes.api-b.serviceId=client-ribbon zuul.routes.api-c.path=/api-b/** zuul.routes.api-c.serviceId=fuzai
经过测试针对路由的path， 在第一部分说明了只支持一个**模糊匹配
**之前的path只支持固定字符串的匹配方式
可以匹配以下3种 （以下三种写法是等效的,当然也可以使用更多的分割路径，比如4个）
/a/b/c/**
/a/b/**
/a/**
其中a,b,c都是固定字符串 并且每一个都可以当作项目id 名字（serviceId）
比如经过如上配置:
url
10.166.15.55:6096/abc/chaosclient-service-provider/def/getMessageqq?num=1001
和
10.166.15.55:6096/chaosclient-service-provider/getMessageqq?num=1001
访问内容可以一致
其实这种也满足了绝大部分的路由场景需要.