傳統路由配置
所謂傳統路由配置方式就是在不依賴於服務發現機制情況下，通過在配置文件中具體制定每個路由表達式與服務實例的映射關系來實現API網關對外部請求的路由。沒有Eureka服務治理框架幫助的時候，我們需要根據服務實例的數量采用不同方式的配置來實現路由規則：
單實例配置：通過一組zuul.routes.<route>.path與zuul.routes.<route>.url參數的方式配置：
zuul.routes.david-feign.path=/david-feign/**
zuul.routes.user-service.url=http://localhost:8764/
該配置實現了對符合/david-feign/**規則的請求轉發到http://localhost:8764/地址的路由規則。比如當有一個請求http://localhost:8769/david-feign/hello 發送到API網關上，由於/david-feign/可以匹配path規則，所以API網關會轉發請求到localhost:8764/hello地址
多實例配置：通過一組zuul.routes.<route>.path與zuul.routes<route>.serviceId參數對的方式配置：
zuul.routes.david-feign.path=/david-feign/**
zuul.routes.david-feign.serviceId=david-feign
ribbon.eureka.enable=false
david-feign.ribbon.listOfServers=http://localhost:8080,http://localhost:8081/
該配置實現了對符合/david-feign/**規則的請求轉發路徑到localhost:8080和localhost:8081兩個實例地址的路由規則。它的配置方式與服務路由的配置方式一樣，都采用了zuul.routes.<route>.path與zuul.routes.<route>.serviceId參數對的映射方式，只是這里的serviceId十由用戶手工命名的服務名稱，配合<serviceId>.ribbon.listOfServers參數實現服務與實例的維護。由於存在多個實例，API網關在進行路由轉發時需要實現負載均衡策略，於是這里還需要Spring Cloud Ribbon的配合，由於在Spring Cloud Zuul中自帶了對Ribbon的依賴，所以我們只需要做一些配置即可，比如上面實例中關於Ribbon的各個配置，他們的具體作用如下：
ribbon.eureka.enable:由於zuul.routes.<route>.serviceId指定的是服務名稱，默認情況下Ribbon會根據服務發現機制來獲取配置服務名對應的實例清單。但是該示例並沒有整合類似Eureka之類的服務治理框架，所以需要將該參數設置為false，不然配置的serviceId是獲取不到對應實例清單的。
david-feign.ribbon.listOfServers：該參數內容與zuul.routes.<route>.serviceId的配置相對應，開頭的david-feign對應了serviceId的值，這兩個參數的配置相當於在該應用內部手工維護了服務與實例的對應關系。
不論是但實例還是多實例的配置方式，我們都需要為每一對映射關系指定一個名稱，也就是上面配置中的route，每一個route就對應了一條路由規則。每條路由規則都需要通過path屬性來定義一個用來匹配客戶端請求的路徑表達式，並通過url或serviceId屬性來指定請求表達式映射具體實例地址或服務名。
服務路由配置
Spring Cloud Zuul通過與Spring Cloud Eureka整合，實現了對服務實例的自動化維護，所以在使用服務路由配置的時候，我們不需要向傳統路由配置方式那樣為serviceId去指定具體的服務實例地址，只需要通過一組zuul.routes.<route>.path與zuul.routes.<route>.serviceId參數對的方式配置即可。
比如下面的示例，它實現了對符合/david-feign/**規則的請求路徑轉發到名為david-feign的服務實例上去的路由規則，其中<route>可以指定為任意的路由名稱。
zuul.routes.api-a.path=/api-a/**
zuul.routes.api-a.serviceId=david-feign
可以直接 攔截api-a的請求 去david-feign處理，對於上面這種還有一種更簡單的方式：zuul.routes.<serviceId>=<path>:
zuul.routes.david-feign=/api-a/**
http://localhost:8769/api-a/test
傳統路由的映射方式比較直觀而且容易理解，API網關直接根據請求的URL路徑找到最匹配的path表達式，直接轉發給該表達式對應的url貨對應的servieId下配置的實例地址，以實現外部請求的路由。那么當采用path與serviceID以服務路由方式實現時候，沒有配置任何實例地址的情況下，外部請求經過API網關的時候，它是如何被解析並轉發服務具體實例的呢？
在Spring Cloud Netflix中，Zuul巧妙的整合了Eureka來實現面向服務的路由，實際上，我們可以直接將API網關也看做是Eureka服務治理下的一個普通微服務。他除了會講自己注冊到Eureka服務注冊中心之外，也會從注冊中心獲取所有的服務以及他們的實例清單。所以在eureka的幫助下，API網關服務本身就已經維護了系統中所有serviceId與實例地址的映射關系。當有外部請求到大API網關的時候，根據請求的url路徑找到最佳匹配的path規則，API網關就可以知道要將該請求路由到那個具體的serviceId上去。由於在API網關中已經知道serviceId對應服務實例的地址清單，那么只需要通過Ribbon的負載均衡策略，直接在這些清單中選擇一個具體的實例進行轉發就能完成路由工作了。