Zuul的引入過程
1. 未引入前
通過前面的學習，使用Spring Cloud實現微服務的架構基本成型，大致是這樣的：
我們使用Spring Cloud Netflix中的Eureka實現了服務註冊中心以及服務註冊與發現；而服務間通過Ribbon或Feign實現服務的消費以及均衡負載。爲了使得服務集羣更爲健壯，使用Hystrix的融斷機制來避免在微服務架構中個別服務出現異常時引起的故障蔓延。
在該架構中，我們的服務集羣包含：內部服務Service A和Service B，他們都會註冊與訂閱服務至Eureka Server，而Open Service是一個對外的服務，通過均衡負載公開至服務調用方。我們把焦點聚集在對外服務這塊，直接暴露我們的服務地址，這樣的實現是否合理，或者是否有更好的實現方式呢？
2. 不足
先來說說這樣架構需要做的一些事兒以及存在的不足：
- 破壞了服務無狀態特點。
爲了保證對外服務的安全性，我們需要實現對服務訪問的權限控制，而開放服務的權限控制機制將會貫穿並污染整個開放服務的業務邏輯，這會帶來的最直接問題是，破壞了服務集羣中REST API無狀態的特點。
從具體開發和測試的角度來說，在工作中除了要考慮實際的業務邏輯之外，還需要額外考慮對接口訪問的控制處理。
-
無法直接複用既有接口。
當我們需要對一個即有的集羣內訪問接口，實現外部服務訪問時，我們不得不通過在原有接口上增加校驗邏輯，或增加一個代理調用來實現權限控制，無法直接複用原有的接口。
3. 問題解決
爲了解決上面這些問題，我們需要將權限控制這樣的東西從我們的服務單元中抽離出去，而最適合這些邏輯的地方就是處於對外訪問最前端的地方，我們需要一個更強大一些的均衡負載器的 服務網關。
服務網關是微服務架構中一個不可或缺的部分。通過服務網關統一向外系統提供REST API的過程中，除了具備服務路由、均衡負載功能之外，它還具備了權限控制等功能。Spring Cloud Netflix中的Zuul就擔任了這樣的一個角色，爲微服務架構提供了前門保護的作用，同時將權限控制這些較重的非業務邏輯內容遷移到服務路由層面，使得服務集羣主體能夠具備更高的可複用性和可測試性。
Zuul簡介
官網：https://github.com/Netflix/zuul
電影《捉鬼敢死隊》中的怪獸，Zuul，在紐約引發了巨大騷亂。
事實上，在微服務架構中，Zuul就是守門的大Boss！一夫當關，萬夫莫開！
Zuul加入後的架構
不管是來自於客戶端（PC或移動端）的請求，還是服務內部調用。一切對服務的請求都會經過Zuul這個網關，然後再由網關來實現 鑑權、動態路由等等操作。Zuul就是我們服務的統一入口。