1. 概述
API網關是 一 個更爲智能的應用服務器， 它的定義類似於面向對象設計模式中的Facade模式， 它的存在就像是整個微服務架構系統的門面 一 樣，所有的外部客戶端訪問都需要經過它來進行調度和過濾。它除了要實現請求路由、 負載均衡、 校驗過濾等功能之外， 還需要更多能力， 比如與服務治理框架的結合、 請求轉發時的熔斷機制、 服務的聚合等 一 系列高級功能。
SpringCloud Zuul通過與SpringCloudEureka進行整合， 將自身註冊爲Eureka服務治理下的應用， 同時從Eureka中獲得了所有其他微服務的實例信息。 這樣的設計非常巧妙地將服務治理體系中維護的實例信息利用起來， 使得將維護服務實例的工作交給了服務治理框架自動完成， 不再需要人工介入。
zuul的使用重點基本在於路由配置和過濾器。
2. 基本使用
1. 引入配置
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zuul</artifactId>
</dependency>2. 添加啓動類
啓動類加上註解@EnableZuulProxy，如果需要zuul自動實現容錯，還需要加上@EnableHystrix
3. 配置文件
設置端口，應用名稱，eureka地址等
4. 配置路由（可選）
默認情況下，zuul與eureka聯合使用，zuul會自動讀取eureka中註冊的服務，並且自動代理。自定義的路由配置比如去除某個服務，添加前綴，自定義路由等，暫且不說。
5. 添加過濾器
編寫類繼承ZuulFilter，並配置到spring
6. 啓動eureka，業務服務（service-A），zuul，
如果zuul端口爲8883，則訪問http://localhost:8883/service-A/api就可以看到響應的結果
3. 對Hystrix和Ribbon的支持
1. 添加容錯
編寫類實現ZuulFallbackProvider接口，getRoute方法返回服務的名稱。ClientHttpResponse的getBody方法可以給前臺返回錯誤信息。需要注意的是，這個容錯只有在服務掉線或者超時纔會觸發。
4. 過濾器詳解
zuul共有四種過濾器，分別是pre，route，post和error過濾器。具體如下圖所示：
首先它會進入第 一 個階段pre, 在這裏它會被pre類型的過濾器進行處理， 該類型過濾器的主要目的是在進行請求路由之前做 一 些前置加工， 比如請求的校驗等。
在完成了pre類型的過濾器處理之後， 請求進入第二個階段rou巨ng, 也就是之前說的路由請求轉發階段， 請求將會被routing類型過濾器處理。這裏的具體處理 內容就是將外部請求轉發到具體服務實例上去的過程， 當服務實例將請求結果都返回之後， routing 階段完成， 請求進入第三個階段post。
此時請求將會被post類型的過濾器處理，這些過濾器在處理的時候不僅可以獲取到請求信息， 還能獲取到服務實例的返回信息， 所以在 post類型的過濾器 中， 我們可以對處理結果進行一 些加工或轉換等內容。
另外， 還有 一 個特殊的階段error, 該階段只有在上述三個階段中發生異常的時候纔會觸發，但是它的最後流向還是 po江類型的過濾器，因爲它需要通過post過濾器將最終結果返回給請求客戶端
過濾器的異常處理，主要是error過濾器，在此先不詳細描述
5. 禁用過濾器
zuul.AccessFilter.pre.disable = true
6. 動態路由
通過配置中心實現
7. 動態過濾器
通過動態語言groovy實現