服務網關概述
為什麼需要服務網關
在傳統的單體應用中，我們通常将業務功能寫在一個應用内，統一部署、統一測試。随着業務的發展，每更新一個業務子產品都需要将單體應用重新進行編譯部署。業務子產品的更新，會影響到其他關聯的業務子產品，甚至于造成整個應用系統的不可用，給單體應用的系統維護造成很大的困難。
此時我們需要對舊的單體應用進行服務化改造，将單體應用中的業務功能子產品拆分成獨立的服務單元，每個服務單元獨立管理自身的釋出、維護，解決了單體應用的弊端。
在遷移到微服務架構初期，服務單元數量少，服務間調用簡單。當用戶端通過前端頁面執行某項操作時，通過F5或Nginx等設施的路由和負載均衡配置設定後，被轉發到不同的服務執行個體上。為了讓這些設施能夠正确處理服務路由與分發請求，需要手工維護路由規則和服務執行個體清單，當有服務執行個體增減或IP位址變更時，需要手工修改服務執行個體清單以保持服務執行個體資訊與服務執行個體清單配置一緻性。當系統應用規模越來越大時，手工維護路由規則和服務執行個體清單的難度增加。我們需要一套機制來有效降低維護路由規則與服務執行個體清單的難度。
大多數情況下，為了保證對外服務的安全性，我們在服務端實作的服務接口，往往都會提供一些權限調用機制；為了防止用戶端在發起請求時被篡改等安全方面的考慮，還會有一些簽名校驗的機制存在。由于使用了微服務架構的理念，我們将原本單體應用中的服務子產品拆分為多個獨立的服務單元，每個獨立的服務單元對都需要提供對應的校驗邏輯。随着服務單元數量的增多，在獨立的服務單元内部都需要提供這樣的校驗機制，當我們需要對各個服務單元中的校驗機制進行擴充和優化時，不得不去每個服務單元進行校驗機制的修改，增加了校驗機制的維護複雜度。我們也需要一套機制來解決微服務架構中，對于微服務接口通路時各前置校驗的備援問題。
綜上所述，服務網關的出現主要解決了如下問題：
- 服務路由轉發
- 通過過濾器的方式解決權限校驗、服務限流等功能
何為服務網關
為了解決上述問題，服務網關的概念應運而生，微服務網關的存在就像是整個微服務系統的門面一樣，所有的外部用戶端通路都需要通過服務網關來進行排程和過濾。除了要實作請求路由、負載均衡、校驗過濾等功能外，還需要提供熔斷機制、服務聚合等功能。
Zuul
概述
為了實作上述功能，Netflix提供了開源服務網關Zuul,Zuul提供了一系列不同類型的過濾器(Filter),通過這些過濾器，能夠快速的實作服務路由轉發、服務限流、負載均衡、服務鑒權等功能，避免外部請求沖垮微服務系統。
過濾器
功能
身份驗證：通過身份驗證來區分不同的權限。
鑒權：對請求的有效性進行驗證，如惡意請求、提供驗證碼等。
限流：在高并發的場景下，限制請求通過的流量，避免過大的流量壓垮伺服器。
動态路由：根據需要将請求動态路由到不同的後端服務執行個體。
壓力測試：通過增删後端服務執行個體，确定整體微服務系統可承擔的流量。
靜态響應處理:對于處于高負荷的系統，提供靜态資料作為服務的相應結果。
多區域彈性：将服務請求路由到最近的服務站點，提高服務的整體性能。
過濾器類型
pre：前置過濾器,請求被網關路由之前被調用。可以用此種過濾器實作服務限流、鑒權、參數校驗。
routing:路由過濾器，将服務調用請求從網關路由到微服務。用于建構發送給服務注冊中心的請求，并使用Http Client或Netflix Ribbon進行服務調用。
post:路由到微服務後執行，為請求調用響應添加标準的Http Header、收集統計資訊和名額、将相應從微服務發送到用戶端等。
error:其他階段發生錯誤時執行該過濾器。
Zuul采取了動态讀取、編譯和運作這些過濾器。過濾器之間不能直接互相通信，而是通過RequestContext對象來共享資料，每個請求都會建立一個RequestContext對象，Zuul過濾器具有以下關鍵特性：
- Type:Zuul過濾器類型，決定了過濾器在請求的哪個階段起作用。
- Execution Order:執行順序，規定了過濾器的執行順序，Order值越小，執行順序越靠前。
- Criteria:标準，過濾器執行所需要的條件
- Action:行動，如果符合執行條件，則執行具體操作。
生命周期
外部http請求到達api網關後，進入pre過濾器對http請求進行處理。該過濾器的主要目的是在進行服務調用請求路由前做一些前置加工，比如權限校驗、服務限流、參數校驗等。在完成了pre類型的過濾器處理之後，請求進入第二個過濾器routing階段，即服務路由請求轉發階段，服務調用請求會被routing類型的過濾器進行處理。這裡的具體處理内容就是将外部請求轉發到具體服務執行個體上去的過程，當服務執行個體請求結果都傳回之後，routing階段完成，服務調用請求進入第三個階段post過濾器。在post過濾器内處理的過程中，不僅可以擷取到服務調用請求資訊，還可以擷取到服務執行個體的傳回資訊，在post類型的過濾器中，可以對服務請求調用結果進行加工和轉換的工作。還有一個特殊的error過濾器階段，在上述三個過濾器階段執行的過程中發生異常的情況下被觸發，最終還是流向post類型的過濾器，需要通過post類型過濾器将最終結果傳回給用戶端。