Spring Cloud架構教程 （四）服務網關（路由配置）

傳統路由配置

所謂的傳統路由配置方式就是在不依賴於服務發現機制的狀況下，經過在配置文件中具體指定每一個路由表達式與服務實例的映射關係來實現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的值，這兩個參數的配置至關於在該應用內部手工維護了服務與實例的對應關係。

• 好比下面的示例，它實現了對符合/user-service/**規則的請求路徑轉發到名爲user-service的服務實例上去的路由規則。其中<route>能夠指定爲任意的路由名稱。

  不管是單實例仍是多實例的配置方式，咱們都須要爲每一對映射關係指定一個名稱，也就是上面配置中的<route>，每個<route>就對應了一條路由規則。每條路由規則都須要經過path屬性來定義一個用來匹配客戶端請求的路徑表達式，並經過url或serviceId屬性來指定請求表達式映射具體實例地址或服務名。

  服務路由配置

  服務路由咱們在上一篇中也已經有過基礎的介紹和體驗，Spring Cloud Zuul經過與Spring Cloud Eureka的整合，實現了對服務實例的自動化維護，因此在使用服務路由配置的時候，咱們不須要向傳統路由配置方式那樣爲serviceId去指定具體的服務實例地址，只須要經過一組zuul.routes.<route>.path與zuul.routes.<route>.serviceId參數對的方式配置便可。

  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的負載均衡策略，直接在這些清單中選擇一個具體的實例進行轉發就能完成路由工做了。源碼來源