ps:我們使用了動態路由，如果不是動態路由(使用靜態檔案的配置檔案)，也是符合本文的邏輯.

一 對當前閘道器的路由解析的分析

跟蹤程式碼發現zuul目前支援的路由解析策略對url的匹配的格式應該是

/url/**  ，其中**號不支援出現多次，

1.class DiscoveryClientRouteLocator

2 class ZuulProperties

@Data

@NoArgsConstructor

publicstaticclass 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

訪問內容可以一致

其實這種也滿足了絕大部分的路由場景需要.