為什么需要服務網關
在分布式系統系統中，有商品、訂單、用戶、廣告、支付等等一大批的服務，前端怎么調用呢？和每個服務一個個打交道？這顯然是不可能的，這就需要有一個角色充當所有請求的入口，這個角色就是服務網關（API gateway）。
服務網關應該具備的要素
穩定性、高可用：網關是所有請求的入口，如果這里出現問題就會導致所有的服務不能對外提供服務了，可見其重要性
性能、并發性：既然是所有請求的入口，那就意味著并發量大，這對其性能就有很高的要求
安全性：要確保服務的安全，防止外部的惡意訪問，像金融行業一般會對數據進行加密傳輸
拓展性：因為各種請求都經過網關服務，所以網關上大有文章可做，是處理所有非業務功能的絕佳場所，比如流控、協議轉發、日志、防刷等等。
在這里需要明確一點，服務網關并不是微服務出現后才有的！！！
常見的網關方案
Nginx + Lua： 性能和高可用是Nginx傲視群雄的資本
Kong：基于Nginx + Lua之上進行封裝，更簡單易用，但是需要付費才能使用
Tyk：開源的、輕量級、快速伸縮的服務網關，基于go語言開發
spring cloud zuul：也是基于Netflix提供的開源工具上進行封裝，天生服務于微服務，如果是基于Java開發的，結合spring cloud提供的微服務治理體系的話，zuul提供了認證、鑒權、限流、監控、彈性、安全、動態路由、負載均衡、協作單點壓測、靜態響應等等功能。但是性能方面肯定是比不上Nginx的。
個人覺得如果你是使用了spring cloud去開發微服務，那么使用zuul去做服務網關真的是非常合適的，而且特別適合快速上手，雖然其并發性能比不上Nginx，但是我們開發的可以靈活配置啊，Nginx+zuul 讓他們發揮各自的優點。
zuul的特點
路由+過濾器 = zuul，個人覺得zuul的核心就是由一系列的過濾器組成。
zuul的四種過濾器API
? ? 前置（Pre）：首先到達的是這里，注意這里是指Pre這種類型的過濾器，實際上不止一個過濾器，對請求路由前置加工，比如參數校驗、限流、鑒權
? ? 路由（route）：這里的是將請求轉發到具體的Origin Server（具體的微服務）上，可以在這里重寫http請求。
? ? 后置（Post）：這里是已經拿到請求的結果了，如果想對結果再加工一下，可以在這里，比如統計、日志
? ? 錯誤（Error）：Pre或者Route、Post出現異常就會來到Error，這里可以種統一異常處理
此外還有Custom（自定義過濾器），實際上它也歸屬于上面四類，看你自定義它是何種類型就是何種類型，上面的四種都支持自定義。
