Spring Cloud構建微服務架構：服務網關（路由配置）【Dalston版】
在上一篇《Spring Cloud構建微服務架構：服務網關(基礎)》一文中，我們通過使用Spring Cloud Zuul構建了一個基礎的API網關服務，同時也演示了Spring Cloud Zuul基于服務的自動路由功能。在本文中，我們將進一步詳細地介紹關于Spring Cloud Zuul的路由功能，以幫助讀者可以更好的理解和使用它，以完成更復雜的路由配置。
傳統路由配置
所謂的傳統路由配置方式就是在不依賴于服務發現機制的情況下，通過在配置文件中具體指定每個路由表達式與服務實例的映射關系來實現API網關對外部請求的路由。
沒有Eureka和Consul的服務治理框架幫助的時候，我們需要根據服務實例的數量采用不同方式的配置來實現路由規則：
(1) 單實例配置：通過一組 zuul.routes.
- 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地址。
(2) 多實例配置：通過一組 zuul.routes.
- 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.
- ribbon.eureka.enabled：由于 zuul.routes.
.serviceId指定的是服務名稱，默認情況下Ribbon會根據服務發現機制來獲取配置服務名對應的實例清單。但是，該示例并沒有整合類似Eureka之類的服務治理框架，所以需要將該參數設置為false，不然配置的 serviceId是獲取不到對應實例清單的。 - user-service.ribbon.listOfServers：該參數內容與 zuul.routes.
.serviceId的配置相對應，開頭的 user-service對應了 serviceId的值，這兩個參數的配置相當于在該應用內部手工維護了服務與實例的對應關系。
不論是單實例還是多實例的配置方式，我們都需要為每一對映射關系指定一個名稱，也就是上面配置中的
服務路由配置
服務路由我們在上一篇中也已經有過基礎的介紹和體驗，Spring Cloud Zuul通過與Spring Cloud Eureka的整合，實現了對服務實例的自動化維護，所以在使用服務路由配置的時候，我們不需要向傳統路由配置方式那樣為 serviceId去指定具體的服務實例地址，只需要通過一組 zuul.routes.
比如下面的示例，它實現了對符合 /user-service/**規則的請求路徑轉發到名為 user-service的服務實例上去的路由規則。其中
- zuul.routes.user-service.path=/user-service/**
- zuul.routes.user-service.serviceId=user-service
對于面向服務的路由配置，除了使用 path與 serviceId映射的配置方式之外，還有一種更簡潔的配置方式： zuul.routes.
- 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/
【本文為51CTO專欄作者“翟永超”的原創稿件，轉載請通過51CTO聯系作者獲取授權】
