本文原始碼：GitHub·點這裡 || GitEE·點這裡
一、服務閘道器簡介
1、外觀模式
客戶端與各個業務子系統的通訊必須通過一個統一的外觀物件進行，外觀模式提供一個高層次的介面，使得子系統更易於使用：
簡單說一下外觀模式，閘道器和這個模式很像，但是比外觀模式複雜，模式，結構，原則這些都是通用的，在各種架構或元件中使用。
2、閘道器簡介
微服務閘道器從感覺上，很像是：攔截器+路由+過濾器，攔截請求，系列基礎處理，路由轉發到指定服務。
服務閘道器在整個架構體系上也是一個伺服器，作為請求的唯一入口，與外觀模式十分類似，在閘道器層處理所有的非業務功能，為客戶端提供定製的API，在閘道器層通常會執行如下操作：如許可權校驗、監控、負載均衡、快取、日誌、限流、等等。
二、閘道器模式
1、模式對比
這裡對比常用的請求服務管理模式，和閘道器模式，如圖：
常規模式
在沒有閘道器的情況下，微服務架構會在業務層服務上提供一個API服務，用來接收引數，例如Client-API，通常會根據系統模組劃分多個API，例如，運營系統，使用者系統等。
- 請求統一進入Client-API服務 ；
- Client-API經過鑑權，限流，路由等操作；
- 如果請求通過，會轉發到相應業務服務上；
- 如果請求被攔截，會直接返回給客戶端；
- Client-API整合所有業務服務的開放介面；
該模式下的缺點非常明顯，每個Client-API都需要實現一套非業務服務，程式碼冗餘，當系統膨脹之後，維護成本極高，適用於輕量級系統架構。
閘道器模式
在業務服務層上，新增一層閘道器控制，在服務閘道器中可以完成一系列的橫切非業務功能：
- 客戶端請求在閘道器層做統一攔截；
- 閘道器上執行：路由/鑑權/限流/降級等操作；
- 閘道器判斷是轉發請求還是直接響應客戶端；
閘道器服務層要執行很多非業務流程，作為系統的服務端唯一入口，承受所有服務的路由轉發，安全，限流，快取，日誌，監控，熔斷降級等功能，閘道器服務不僅要做到高可用，還要避免出現效能瓶頸。
2、多重閘道器
在大型複雜的系統中，通常會對閘道器做分層管理，把一類業務規劃到一個閘道器下，避免閘道器過於臃腫，方便維護和管理：
總閘道器：通用常用來做路由轉發功能；
模組閘道器：分類的業務服務聚合閘道器，對這類服務的做非業務性操作，最後請求轉發到具體服務上，在資料類平臺上，通常對資料通道(流入流出)做一層獨立的服務閘道器；對資料分析類服務做一層獨立閘道器；基本是根據服務的使用情況來劃分，這樣避免單層服務閘道器過於複雜的情況。
三、核心功能
1、配置層面
服務發現
閘道器應該有服務發現功能，通過統一註冊中心，獲取服務列表，這樣才能執行統一代理服務和路由轉發功能。
路由請求
植入閘道器層服務之後，客戶端不知道自己請求的是哪個具體的服務，只需要把請求轉發給閘道器，閘道器放行之後會把請求路由到指定業務服務上。
負載均衡
閘道器連線的服務例項可能是叢集模式存在，所以閘道器還可以對各個服務例項上執行負載均衡策略，常見的策略就是服務輪詢或者按權重路由。
2、定製開發
定製開發例如：許可權校驗，日誌整合，介面限流，等相關功能，需要和資料庫互動，可以做成獨立服務，在服務中實現具體的處理邏輯，閘道器層直接呼叫即可。
四、閘道器元件
1、Netflix-Zuul
Zuul閘道器主要提供動態路由，監控，彈性，安全管控等功能。在分散式的微服務系統中，系統被拆為了多個微服務模組，通過zuul閘道器對使用者的請求進行路由，轉發到具體的後微服務模組中，Netflix開源的一個基於JVM路由和服務端的負載均衡器。
2、Tyk元件
Tyk是一個開源的、輕量級的、快速可伸縮的API閘道器，支援配額和速度限制，支援認證和資料分析，支援多使用者多組織。基於go語言編寫，在Java架構系統中使用很少。
3、Kong元件
Kong是一款基於Nginx+Lua編寫的高可用，可擴充套件的開源閘道器專案，由Mashape公司開放。核心是實現資料庫抽象，路由和外掛管理，外掛可以存在於單獨的程式碼庫中，並且可以在幾行程式碼中注入到請求生命週期的任何位置。提供易於使用的RESTfulAPI來操作和配置API管理，並且可以水平擴充套件多個Kong伺服器，通過前置的負載均衡配置把請求均勻地分發到各個Server，來應對高併發的網路請求。
五、原始碼地址
GitHub·地址
https://github.com/cicadasmile/husky-spring-cloud
GitEE·地址
https://gitee.com/cicadasmile/husky-spring-cloud
推薦閱讀：微服務架構