在上一篇《Spring Cloud構建微服務架構：服務網關（基礎）》一文中，我們通過使用Spring Cloud Zuul構建了一個基礎的API網關服務，同時也演示了Spring Cloud Zuul基于服務的自動路由功能。在本文中，我們將進一步詳細地介紹關于Spring Cloud Zuul的路由功能，以幫助讀者可以更好的理解和使用它，以完成更復雜的路由配置。
傳統路由配置
所謂的傳統路由配置方式就是在不依賴于服務發現機制的情況下，通過在配置文件中具體指定每個路由表達式與服務實例的映射關系來實現API網關對外部請求的路由。
沒有Eureka和Consul的服務治理框架幫助的時候，我們需要根據服務實例的數量采用不同方式的配置來實現路由規則：
- 單實例配置：通過一組
zuul.routes.<route>.path與zuul.routes.<route>.url參數對的方式配置，比如：
zuul.routes.user-service.path=/user-service/**
zuul.routes.user-service.url=http://localhost:8080/
該配置實現了對符合/user-service/**規則的請求路徑轉發到http://localhost:8080/地址的路由規則，比如，當有一個請求http://localhost:1101/user-service/hello被發送到API網關上，由于/user-service/hello能夠被上述配置的path規則匹配，所以API網關會轉發請求到http://localhost:8080/hello地址。
- 多實例配置：通過一組
zuul.routes.<route>.path與zuul.routes.<route>.serviceId參數對的方式配置，比如：
zuul.routes.user-service.path=/user-service/**
zuul.routes.user-service.serviceId=user-service
ribbon.eureka.enabled=false
user-service.ribbon.listOfServers=http://localhost:8080/,http://localhost:8081/
該配置實現了對符合/user-service/**規則的請求路徑轉發到http://localhost:8080/和http://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.enabled：由于zuul.routes.<route>.serviceId指定的是服務名稱，默認情況下Ribbon會根據服務發現機制來獲取配置服務名對應的實例清單。但是，該示例并沒有整合類似Eureka之類的服務治理框架，所以需要將該參數設置為false，不然配置的serviceId是獲取不到對應實例清單的。 -
user-service.ribbon.listOfServers：該參數內容與zuul.routes.<route>.serviceId的配置相對應，開頭的user-service對應了serviceId的值，這兩個參數的配置相當于在該應用內部手工維護了服務與實例的對應關系。
不論是單實例還是多實例的配置方式，我們都需要為每一對映射關系指定一個名稱，也就是上面配置中的<route>，每一個<route>就對應了一條路由規則。每條路由規則都需要通過path屬性來定義一個用來匹配客戶端請求的路徑表達式，并通過url或serviceId屬性來指定請求表達式映射具體實例地址或服務名。
服務路由配置
服務路由我們在上一篇中也已經有過基礎的介紹和體驗，Spring Cloud Zuul通過與Spring Cloud Eureka的整合，實現了對服務實例的自動化維護，所以在使用服務路由配置的時候，我們不需要向傳統路由配置方式那樣為serviceId去指定具體的服務實例地址，只需要通過一組zuul.routes.<route>.path與zuul.routes.<route>.serviceId參數對的方式配置即可。
比如下面的示例，它實現了對符合/user-service/**規則的請求路徑轉發到名為user-service的服務實例上去的路由規則。其中<route>可以指定為任意的路由名稱。
zuul.routes.user-service.path=/user-service/**
zuul.routes.user-service.serviceId=user-service
對于面向服務的路由配置，除了使用path與serviceId映射的配置方式之外，還有一種更簡潔的配置方式：zuul.routes.<serviceId>=<path>，其中<serviceId>用來指定路由的具體服務名，<path>用來配置匹配的請求表達式。比如下面的例子，它的路由規則等價于上面通過path與serviceId組合使用的配置方式。
zuul.routes.user-service=/user-service/**
傳統路由的映射方式比較直觀且容易理解，API網關直接根據請求的URL路徑找到最匹配的path表達式，直接轉發給該表達式對應的url或對應serviceId下配置的實例地址，以實現外部請求的路由。那么當采用path與serviceId以服務路由方式實現時候，沒有配置任何實例地址的情況下，外部請求經過API網關的時候，它是如何被解析并轉發到服務具體實例的呢？
在Spring Cloud Netflix中，Zuul巧妙的整合了Eureka來實現面向服務的路由。實際上，我們可以直接將API網關也看做是Eureka服務治理下的一個普通微服務應用。它除了會將自己注冊到Eureka服務注冊中心上之外，也會從注冊中心獲取所有服務以及它們的實例清單。所以，在Eureka的幫助下，API網關服務本身就已經維護了系統中所有serviceId與實例地址的映射關系。當有外部請求到達API網關的時候，根據請求的URL路徑找到最佳匹配的path規則，API網關就可以知道要將該請求路由到哪個具體的serviceId上去。由于在API網關中已經知道serviceId對應服務實例的地址清單，那么只需要通過Ribbon的負載均衡策略，直接在這些清單中選擇一個具體的實例進行轉發就能完成路由工作了。
示例倉庫
- Github：https://github.com/dyc87112/SpringCloud-Learning
- 碼云：https://gitee.com/didispace/SpringCloud-Learning/
