本文源碼:GitHub·點這裏 || GitEE·點這裏git
客戶端與各個業務子系統的通訊必須經過一個統一的外觀對象進行,外觀模式提供一個高層次的接口,使得子系統更易於使用:github
簡單說一下外觀模式,網關和這個模式很像,可是比外觀模式複雜,模式,結構,原則這些都是通用的,在各類架構或組件中使用。算法
微服務網關從感受上,很像是:攔截器+路由+過濾器,攔截請求,系列基礎處理,路由轉發到指定服務。spring
服務網關在整個架構體系上也是一個服務器,做爲請求的惟一入口,與外觀模式十分相似,在網關層處理全部的非業務功能,爲客戶端提供定製的API,在網關層一般會執行以下操做:如權限校驗、監控、負載均衡、緩存、日誌、限流、等等。數據庫
這裏對比經常使用的請求服務管理模式,和網關模式,如圖:segmentfault
常規模式緩存
在沒有網關的狀況下,微服務架構會在業務層服務上提供一個API服務,用來接收參數,例如Client-API,一般會根據系統模塊劃分多個API,例如,運營系統,用戶系統等。安全
該模式下的缺點很是明顯,每一個Client-API都須要實現一套非業務服務,代碼冗餘,當系統膨脹以後,維護成本極高,適用於輕量級系統架構。服務器
網關模式網絡
在業務服務層上,添加一層網關控制,在服務網關中能夠完成一系列的橫切非業務功能:
網關服務層要執行不少非業務流程,做爲系統的服務端惟一入口,承受全部服務的路由轉發,安全,限流,緩存,日誌,監控,熔斷降級等功能,網關服務不只要作到高可用,還要避免出現性能瓶頸。
在大型複雜的系統中,一般會對網關作分層管理,把一類業務規劃到一個網關下,避免網關過於臃腫,方便維護和管理:
總網關:通用經常使用來作路由轉發功能;
模塊網關:分類的業務服務聚合網關,對這類服務的作非業務性操做,最後請求轉發到具體服務上,在數據類平臺上,一般對數據通道(流入流出)作一層獨立的服務網關;對數據分析類服務作一層獨立網關;基本是根據服務的使用狀況來劃分,這樣避免單層服務網關過於複雜的狀況。
服務發現
網關應該有服務發現功能,經過統一註冊中心,獲取服務列表,這樣才能執行統一代理服務和路由轉發功能。
路由請求
植入網關層服務以後,客戶端不知道本身請求的是哪一個具體的服務,只須要把請求轉發給網關,網關放行以後會把請求路由到指定業務服務上。
負載均衡
網關鏈接的服務實例多是集羣模式存在,因此網關還能夠對各個服務實例上執行負載均衡策略,常見的策略就是服務輪詢或者按權重路由。
定製開發例如:權限校驗,日誌集成,接口限流,等相關功能,須要和數據庫交互,能夠作成獨立服務,在服務中實現具體的處理邏輯,網關層直接調用便可。
Zuul網關主要提供動態路由,監控,彈性,安全管控等功能。在分佈式的微服務系統中,系統被拆爲了多個微服務模塊,經過zuul網關對用戶的請求進行路由,轉發到具體的後微服務模塊中,Netflix開源的一個基於JVM路由和服務端的負載均衡器。
Tyk是一個開源的、輕量級的、快速可伸縮的API網關,支持配額和速度限制,支持認證和數據分析,支持多用戶多組織。基於go語言編寫,在Java架構系統中使用不多。
Kong是一款基於Nginx+Lua編寫的高可用,可擴展的開源網關項目,由Mashape公司開放。核心是實現數據庫抽象,路由和插件管理,插件能夠存在於單獨的代碼庫中,而且能夠在幾行代碼中注入到請求生命週期的任何位置。提供易於使用的RESTfulAPI來操做和配置API管理,而且能夠水平擴展多個Kong服務器,經過前置的負載均衡配置把請求均勻地分發到各個Server,來應對高併發的網絡請求。
GitHub·地址 https://github.com/cicadasmile/husky-spring-cloud GitEE·地址 https://gitee.com/cicadasmile/husky-spring-cloud
推薦閱讀:微服務架構