nginx的轉發之外，SpringCloud的zuul轉發
服務閘道器是微服務架構中一個不可或缺的部分。通過服務閘道器統一向外系統提供REST API的過程中，除了具備服務路由、均衡負載功能之外，它還具備了許可權控制等功能。Spring Cloud Netflix中的Zuul就擔任了這樣的一個角色，為微服務架構提供了前門保護的作用，同時將許可權控制這些較重的非業務邏輯內容遷移到服務路由層面，使得服務叢集主體能夠具備更高的可複用性和可測試性。
路由在微服務體系結構的一個組成部分。例如，/可以對映到您的Web應用程式，/api/users對映到使用者服務，並將/api/shop對映到商店服務。Zuul是Netflix的基於JVM的路由器和伺服器端負載均衡器。
Netflix使用Zuul進行以下操作：
- 認證
- 洞察
- 壓力測試
- 金絲雀測試
- 動態路由
- 服務遷移
- 負載脫落
- 安全
- 靜態響應處理
- 主動/主動流量管理
Zuul的規則引擎允許基本上寫任何JVM語言編寫規則和過濾器，內建Java和Groovy。
什麼是服務閘道器
服務閘道器 = 路由轉發 + 過濾器
1、路由轉發：接收一切外界請求，轉發到後端的微服務上去；
2、過濾器：在服務閘道器中可以完成一系列的橫切功能，例如許可權校驗、限流以及監控等，這些都可以通過過濾器完成（其實路由轉發也是通過過濾器實現的）。
為什麼需要服務閘道器
上述所說的橫切功能（以許可權校驗為例）可以寫在三個位置：
- 每個服務自己實現一遍
- 寫到一個公共的服務中，然後其他所有服務都依賴這個服務
- 寫到服務閘道器的前置過濾器中，所有請求過來進行許可權校驗
第一種，缺點太明顯，基本不用； 第二種，相較於第一點好很多，程式碼開發不會冗餘，但是有兩個缺點：
- 由於每個服務引入了這個公共服務，那麼相當於在每個服務中都引入了相同的許可權校驗的程式碼，使得每個服務的jar包大小無故增加了一些，尤其是對於使用docker映象進行部署的場景，jar越小越好；
- 由於每個服務都引入了這個公共服務，那麼我們後續升級這個服務可能就比較困難，而且公共服務的功能越多，升級就越難，而且假設我們改變了公共服務中的許可權校驗的方式，想讓所有的服務都去使用新的許可權校驗方式，我們就需要將之前所有的服務都重新引包，編譯部署。
而服務閘道器恰好可以解決這樣的問題：
- 將許可權校驗的邏輯寫在閘道器的過濾器中，後端服務不需要關注許可權校驗的程式碼，所以服務的jar包中也不會引入許可權校驗的邏輯，不會增加jar包大小；
- 如果想修改許可權校驗的邏輯，只需要修改閘道器中的許可權校驗過濾器即可，而不需要升級所有已存在的微服務。
所以，需要服務閘道器！！！
服務閘道器技術選型
引入服務閘道器後的微服務架構如上，總體包含三部分：服務閘道器、open-service和service。
1、總體流程：
- 服務閘道器、open-service和service啟動時註冊到註冊中心上去；
- 使用者請求時直接請求閘道器，閘道器做智慧路由轉發（包括服務發現，負載均衡）到open-service，這其中包含許可權校驗、監控、限流等操作
- open-service聚合內部service響應，返回給閘道器，閘道器再返回給使用者
2、引入閘道器的注意點
- 增加了閘道器，多了一層轉發（原本使用者請求直接訪問open-service即可），效能會下降一些（但是下降不大，通常，閘道器機器效能會很好，而且閘道器與open-service的訪問通常是內網訪問，速度很快）；
- 閘道器的單點問題：在整個網路呼叫過程中，一定會有一個單點，可能是閘道器、nginx、dns伺服器等。防止閘道器單點，可以在閘道器層前邊再掛一臺nginx，nginx的效能極高，基本不會掛，這樣之後，閘道器服務就可以不斷的新增機器。但是這樣一個請求就轉發了兩次，所以最好的方式是閘道器單點服務部署在一臺牛逼的機器上（通過壓測來估算機器的配置），而且nginx與zuul的效能比較，根據國外的一個哥們兒做的實驗來看，其實相差不大，zuul是netflix開源的一個用來做閘道器的開源框架；
- 閘道器要儘量輕。
3、服務閘道器基本功能
- 智慧路由：接收外部一切請求，並轉發到後端的對外服務open-service上去；
- 注意：我們只轉發外部請求，服務之間的請求不走閘道器，這就表示全鏈路追蹤、內部服務API監控、內部服務之間呼叫的容錯、智慧路由不能在閘道器完成；當然，也可以將所有的服務呼叫都走閘道器，那麼幾乎所有的功能都可以整合到閘道器中，但是這樣的話，閘道器的壓力會很大，不堪重負。
- 許可權校驗：只校驗使用者向open-service服務的請求，不校驗服務內部的請求。服務內部的請求有必要校驗嗎？
- API監控：只監控經過閘道器的請求，以及閘道器本身的一些效能指標（例如，gc等）；
- 限流：與監控配合，進行限流操作；
- API日誌統一收集：類似於一個aspect切面，記錄介面的進入和出去時的相關日誌
- 。。。後續補充
4、技術選型
筆者準備自建一個輕量級的服務閘道器，技術選型如下：
- 開發語言：java + groovy，groovy的好處是閘道器服務不需要重啟就可以動態的新增filter來實現一些功能；
- 微服務基礎框架：springboot；
- 閘道器基礎元件：netflix zuul；
- 服務註冊中心：consul；
- 許可權校驗：jwt；
- API監控：prometheus + grafana；
- API統一日誌收集：logback + ELK；
- 壓力測試：Jmeter；
- 。。。後續補充
- 在後續的介紹中，會逐漸介紹各個知識點，並完成一個輕量級的服務閘道器！！！
路由規則
閘道器的預設路由規則
Spring cloud zuul 預設情況下，Zuul會代理所有註冊到Eureka Server的微服務，並且Zuul的路由規則如下：[http://ZUUL_HOST:ZUUL_PORT/]() 微服務在Eureka上的serviceId/**會被轉發到serviceId對應的微服務。
zuul 執行流程
Zuul大部分功能都是通過過濾器來實現的。Zuul中定義了四種標準過濾器型別，這些過濾器型別對應於請求的典型生命週期。
PRE：這種過濾器在請求被路由之前呼叫。我們可利用這種過濾器實現身份驗證、在叢集中選擇請求的微服務、記錄除錯資訊等。
ROUTING：這種過濾器將請求路由到微服務。這種過濾器用於構建傳送給微服務的請求，並使用Apache HttpClient或Netfilx Ribbon請求微服務。
OST：這種過濾器在路由到微服務以後執行。這種過濾器可用來為響應新增標準的HTTP Header、收集統計資訊和指標、將響應從微服務傳送給客戶端等。
ERROR：在其他階段發生錯誤時執行該過濾器。
除了預設的過濾器型別，Zuul還允許我們建立自定義的過濾器型別。例如，我們可以定製一種STATIC型別的過濾器，直接在Zuul中生成響應，而不將請求轉發到後端的微服務。
filterType
filterType：返回一個字串代表過濾器的型別，在zuul中定義了四種不同生命週期的過濾器型別，具體如下:
- pre：路由之前
- routing：路由之時
- post： 路由之後
- error：傳送錯誤呼叫
- filterOrder：過濾的順序
- shouldFilter：這裡可以寫邏輯判斷，是否要過濾，本文true,永遠過濾。
- run：過濾器的具體邏輯。可用很複雜，包括查sql，nosql去判斷該請求到底有沒有許可權訪問。
------
github上有一些小的例子：https://github.com/singgel/SpringCloudExamples