建站
咨詢
售后
建站咨詢
新聞中心
在《SpringCloud Alibaba實戰(zhàn)》專欄前面的文章中，我們實現了用戶微服務、商品微服務和訂單微服務之間的遠程調用，并且實現了服務調用的負載均衡。也基于阿里開源的Sentinel實現了服務的限流與容錯，并詳細介紹了Sentinel的核心技術與配置規(guī)則 。今天，我們正式進入服務網關章節(jié)的學習，首先，我們對服務網關進行簡要的概述并對其核心架構進行簡要的剖析。
創(chuàng)新互聯建站是由多位在大型網絡公司、廣告設計公司的優(yōu)秀設計人員和策劃人員組成的一個具有豐富經驗的團隊，其中包括網站策劃、網頁美工、網站程序員、網頁設計師、平面廣告設計師、網絡營銷人員及形象策劃。承接：網站建設、成都做網站、網站改版、網頁設計制作、網站建設與維護、網絡推廣、數據庫開發(fā),以高性價比制作企業(yè)網站、行業(yè)門戶平臺等全方位的服務。
本章總覽
網關概述
當采用分布式、微服務的架構模式開發(fā)系統中，服務網關是整個系統中必不可少的一部分。
沒有網關的弊端
當一個系統使用分布式、微服務架構后，系統會被拆分為一個個小的微服務，每個微服務專注一個小的業(yè)務。那么，客戶端如何調用這么多微服務的接口呢?如果不做任何處理，沒有服務網關，就只能在客戶端記錄下每個微服務的每個接口地址，然后根據實際需要去調用相應的接口。
這種直接使用客戶端記錄并管理每個微服務的每個接口的方式，存在著太多的問題。比如，這里我列舉幾個常見的問題。
- 由客戶端記錄并管理所有的接口缺乏安全性。
- 由客戶端直接請求不同的微服務，會增加客戶端程序編寫的復雜性。
- 涉及到服務認證與鑒權規(guī)則時，需要在每個微服務中實現這些邏輯，增加了代碼的冗余性。
- 客戶端調用多個微服務，由于每個微服務可能部署的服務器和域名不同，存在跨域的風險。
- 當客戶端比較多時，每個客戶端上都管理和配置所有的接口，維護起來相對比較復雜。
引入API網關
API網關，其實就是整個系統的統一入口。網關會封裝微服務的內部結構，為客戶端提供統一的入口服務，同時，一些與具體業(yè)務邏輯無關的通用邏輯可以在網關中實現，比如認證、授權、路由轉發(fā)、限流、監(jiān)控等。引入API網關后，如下所示。
可以看到，引入API網關后，客戶端只需要連接API網關，由API網關根據實際情況進行路由轉發(fā)，將請求轉發(fā)到具體的微服務，同時，API網關會提供認證、授權、限流和監(jiān)控等功能。
主流的API網關
當系統采用分布式、微服務的架構模式后，API網關就成了整個系統不可分割的一部分。業(yè)界通過不斷的探索與創(chuàng)新，實現了多種API網關的解決方案。目前，比較主流的API網關有：Nginx+Lua、Kong官網、Zuul網關、Apache Shenyu網關、SpringCloud Gateway網關。
Nginx+Lua
Nginx的一些插件本身就實現了限流、緩存、黑白名單和灰度發(fā)布，再加上Nginx的反向代理和負載均衡，能夠實現對服務接口的負載均衡和高可用。而Lua語言可以實現一些簡單的業(yè)務邏輯，Nginx又支持Lua語言。所以，可以基于Nginx+Lua腳本實現網關。
Kong網關
Kong網關基于Nginx與Lua腳本開發(fā)，性能高，比較穩(wěn)定，提供多個限流、鑒權等插件，這些插件支持熱插拔，開箱即用。Kong網關提供了管理頁面，但是，目前基于Kong網關二次開發(fā)比較困難。
Zuul網關
Zuul網關是Netflix開源的網關，功能比較豐富，主要基于Java語言開發(fā)，便于在Zuul網關的基礎上進行二次開發(fā)。但是Zuul網關無法實現動態(tài)配置規(guī)則，依賴的組件相對來說也比較多，在性能上不如Nginx。
Apache Shenyu網關
Dromara社區(qū)開發(fā)的網關框架，ShenYu 的前名是 soul，最近正式加入了 Apache 的孵化器，因此改名為 ShenYu。其是一個異步的，高性能的，跨語言的，響應式的API網關，并在此基礎上提供了非常豐富的擴展功能：
- 支持各種語言(http協議)，支持Dubbo, Spring-Cloud, Grpc, Motan, Sofa, Tars等協議。
- 插件化設計思想，插件熱插拔，易擴展。
- 靈活的流量篩選，能滿足各種流量控制。
- 內置豐富的插件支持，鑒權，限流，熔斷，防火墻等等。
- 流量配置動態(tài)化，性能極高。
- 支持集群部署，支持 A/B Test，藍綠發(fā)布。
SpringCloud Gateway網關
Spring為了替換Zuul而開發(fā)的網關，SpringCloud Alibaba技術棧中，并沒有單獨實現網關的組件。在后續(xù)的案例實現中，我們會使用SpringCloud Gateway實現網關功能。
SpringCloud Gateway網關
Spring Cloud Gateway是Spring公司基于Spring 5.0， Spring Boot 2.0 和 Project Reactor 等技術開發(fā)的網關，它旨在為微服務架構提供一種簡單有效的統一的 API 路由管理方式。
它的目標是替代Netflix Zuul，其不僅提供統一的路由方式，并且基于 Filter 鏈的方式提供了網關基本的功能，例如：安全，監(jiān)控和限流、重試等。
SpringCloud Gateway概述
Spring Cloud Gateway是Spring Cloud的一個全新項目，基于Spring 5.0 + Spring Boot 2.0和Project Reactor等技術開發(fā)的網關，它旨在為微服務架構提供一種簡單有效的統一的API路由管理方式。
Spring Cloud Geteway作為Spring Cloud生態(tài)系統中的網關，目標是替代Zuul，在Spring Cloud2.0以上版本中，沒有對新版本的Zuul 2.0以上最新高性能版本進行集成，仍然還是使用的Zuul 1.x非Reactor模式的老版本。
為了提升網關性能，Spring Cloud Gateway是基于WebFlux框架實現的，而WebFlux框架底層則使用了高性能的Reactor模式通信框架Netty。
Spring Cloud Gateway的目標提供統一的路由方式且基于Filter鏈的方式提供了網關基本的功能，例如：安全，監(jiān)控/指標，和限流。
總結一句話：Spring Cloud Gateway使用的Webflux中的reactor-netty響應式編程組件，底層使用Netty通訊框架。
SpringCloud Gateway核心架構
客戶端請求到 Gateway 網關，會先經過 Gateway Handler Mapping 進行請求和路由匹配。匹配成功后再發(fā)送到 Gateway Web Handler 處理，然后會經過特定的過濾器鏈，經過所有前置過濾后，會發(fā)送代理請求。請求結果返回后，最后會執(zhí)行所有的后置過濾器。
由上圖可以看出，SpringCloud Gateway的主要流程為：客戶端請求會先打到Gateway，具體的講應該是DispacherHandler(因為Gateway引入了WebFlux，作用可以類比MVC的DispacherServlet)。
Gateway根據用戶的請求找到相應的HandlerMapping，請求和具體的handler之間有一個映射關系，網關會對請求進行路由，handler會匹配到RoutePredicateHandlerMapping，匹配請求對應的Route，然后到達Web處理器。
WebHandler代理了一系列網關過濾器和全局過濾器的實例，這些過濾器可以對請求和響應進行修改，最后由代理服務完成用戶請求，并將結果返回。
注：SpringCloud Gateway部分
網站名稱：服務網關：網關概述與核心架構
標題網址：http://www.dlmjj.cn/article/cdpchgo.html
