日本免费全黄少妇一区二区三区-高清无码一区二区三区四区-欧美中文字幕日韩在线观看-国产福利诱惑在线网站-国产中文字幕一区在线-亚洲欧美精品日韩一区-久久国产精品国产精品国产-国产精久久久久久一区二区三区-欧美亚洲国产精品久久久久

  1. 首頁 > 云知道 > >

gateway與zuul區(qū)別，api網關和服務網關

云知道網關

gateway與zuul區(qū)別

gateway與zuul區(qū)別，api網關和服務網關


內部實現(xiàn)不同、支持異步不同、框架設計的角度不同、性能不同 。
內部實現(xiàn)不同：gateway對比zuul多依賴了spring-webflux，在spring的支持下 ， 功能更強大，內部實現(xiàn)了限流、負載均衡等，擴展性也更強，但同時也限制了僅適合于Spring Cloud套件zuul則可以擴展至其他微服務框架中 。
是否支持異步：zuul僅支持同步gateway支持異步 。理論上gateway則更適合于提高系統(tǒng)吞吐量（但不一定能有更好的性能），最終性能還需要通過嚴密的壓測來決定 。
【gateway與zuul區(qū)別，api網關和服務網關】框架設計的角度：gateway具有更好的擴展性，并且其已經發(fā)布了2.0.0的RELESE版本，穩(wěn)定性也是非常好的 。
性能：WebFlux模塊的名稱是spring-webflux，名稱中的Flux來源于Reactor中的類 Flux 。Spring webflux 有一個全新的非堵塞的函數(shù)式Reactive Web框架，可以用來構建異步的、非堵塞的、事件驅動的服務，在伸縮性方面表現(xiàn)非常好 。使用非阻塞API 。Websockets得到支持，并且由于它與Spring緊密集成，所以將會是一個更好的 開發(fā) 體驗 。Zuul1.x，是一個基于阻塞io的API Gateway 。Zuul已經發(fā)布了Zuul 2.x ， 基于Netty，也是非阻塞的，支持長連接，但Spring Cloud暫時還沒有整合計劃 。
api網關和服務網關Zuul 1(阻塞)的應用場景
.cpu密集型任務
.簡單操作的需求
.開發(fā)簡單的需求
.實時請求高的
Zuul 2（非阻塞）的應用場景
.io密集的任務
.大請求或者大文件
.隊列的流式數(shù)據(jù)
.超大量的連接
gateway其實就是相當于Zuul 2的，gateway就是因為Zuul 2停止維護，基于Zuul2的原理實現(xiàn)springcloud自己的網關gateway 。
高可用集群部署上一篇 << 下一篇 >>> Gateway的謂詞配置實例
推薦閱讀：
<<<網關背景分類及常用框架
<<<微服務網關與過濾器的區(qū)別
<<<< <<<<<如何保證微服務接口的安全
<< << << << spring gateway源碼解析Spring Cloud提供了兩套方便我們編寫網關的中間件，分別是zuul和Spring GateWay,在zuul1的IO模型是使用BIO(圖1-1) 。而zuul2對IO模型使用NIO進行了重構(圖1-2) 。而Spring GateWay的IO模型是使用NIO 。而在Netflix發(fā)布zuul2的時候Spring Cloud已經開始不集成到Spring Cloud中，因為Spring Cloud 等著zuul2集成太久，才有了Spring Gateway 。Spring GateWay的架構是基于Spring webflux的基礎上開發(fā)的 。而對webflux的RP中涉及的Back Pressure、Stream、asynchronous好處不多說哈哈 。
在Spring mvc是通過HandlerMapping解析請求鏈接，然后根據(jù)請求鏈接找到執(zhí)行這個請求Controller類。而在Spring GateWay中也是使用HandlerMapping對請求的鏈接進行解析匹配對應的Route進行代理轉發(fā)到對應的服務 。圖2-1為整個請求的流程，用戶請求先通過DispatcherHandler找到對應GateWwayHandlerMapping,再通過GateWwayHandlerMapping解析匹配到對應的Handler 。Handler處理完后，再經過Filter，最終到Proxied Service.
1.請求先由DispatcherHanlder進行處理，DispatcherHanlder初始化的時候會從IOC中查找實現(xiàn)HandlerMapping接口的實現(xiàn)類 。然后保存到內部變量handlerMappings中，DispatcerHandler調用Handler方法迭代handler
Mappings中的HandlerMapping,
2.這里只講解RoutePredicateHandlerMapping，因此然后調用RoutePredicateHandlerMapping中的獲取路由的方法，當RoutePredicateHandlerMapping獲取到對應的路由的時候會將Route存儲到ServerWebExchanges的屬性中，然后返回實現(xiàn)了WebHandler接口的FilteringWebHandler 。FilteringWebHandler是一個存放過濾器的Handler 。
3.最后DispatcherHanlder通過SimpleHandlerAdapter適配器的方式調用FilteringWebHandler的handler方法，F(xiàn)ilteringWebHandler調用所有的過濾器，包括proxy filter 。通過proxyFilter請求被代理的服務 。處理完畢后 ， 并將Response響應回去 。
圖3-1為handler類關系圖 。這里主要涉及到Spring GateWay相關類的探討 。如：Spring Webflux使用到的RouteFuntionMapping和SimpleUrlHandlerMapping等不做探討 。
HandlerMapping和Ordered接口主要定義了獲取getHandler和當前hanler加載順序 。AbstractHandlerMapping在getHanlder封裝了CORS處理 。因為所有Handler都可能會涉及到CORS的處理 ， 抽象到AbstractHandlerMapping處理，再提供了getHandlerInternal讓子類實現(xiàn)具體的查找Handler的方法 。
RoutePredicateHandlerMapping是處理獲取路由的hanlder 。Route
PredicateHandlerMapping中的RouteLocator是存儲了我們啟動的時候加載的路由對象信息 。獲取路由的時候，調用RoutePredicateHanlderMapping的getHandlerInternal方法從RouteLocator獲取路由存放在ServerWebExchange中 ， 返回webFilter 。
RouteLocator主要作用是提供獲取路由的類型 。我們在分析Route
PredicateHandlerMapping的時候，知道RoutePredicateHandlerMapping獲取路由是通過RouteLocator進行獲取的 。那么我們這里分析下RouteLocator加載路由 。
Route主要為三部分：
最總的 RouteLocator是CachingRoutelocator 。加載過程是自上而下進行創(chuàng)建 。
第二種方式是通過Properties文件進行創(chuàng)建路由 。Properties路由的創(chuàng)建包括：PropertiesRouteDefinitionLocator和DiscoveryClientRouteDefinitionLocator.
第三種方式是通過MYSQL或者Reids、內存（InMemoryRouteDefinitionRepository）方式創(chuàng)建路由 。實現(xiàn)RouteDefinitionRepository接口實現(xiàn)接口中的方式 。InMemoryRouteDefinitionRepository為默認方式 。
Filter我們區(qū)分為全局Filter和RouteFilter
在轉發(fā)過程分析中我們知道最終的代理請求是通過一個Proxy Filter進行請求Proxy Service ， 那么這個Proxy Filter就是NettyRoutingFilter 。通過下面的源碼我們可以看到在 proxyRequest.sendHeaders() .send(request.getBody().map(dataBuffer -> ((NettyDataBuffer) dataBuffer).getNativeBuffer())); 中請求Proxy Service.
Spring Cloud Netflix 替代方案目前市場上主流的 第一套微服務架構解決方案：Spring Boot + Spring Cloud Netflix
Spring Cloud 為開發(fā)人員提供了快速構建分布式系統(tǒng)中一些常見模式的工具（例如配置管理，服務發(fā)現(xiàn)，斷路器，智能路由 ， 微代理，控制總線） 。分布式系統(tǒng)的協(xié)調導致了樣板模式, 使用 Spring Cloud 開發(fā)人員可以快速地支持實現(xiàn)這些模式的服務和應用程序 。他們將在任何分布式環(huán)境中運行良好，包括開發(fā)人員自己的筆記本電腦，裸機數(shù)據(jù)中心，以及 Cloud Foundry 等托管平臺 。
目前業(yè)界對 Spring Cloud 使用最廣的就是 Spring Cloud Netflix 了 。后來 采用 Spring Cloud Alibaba 方案來替代 Spring Cloud Netflix
2018 年 12 月 12 日，Netflix 宣布 Spring Cloud Netflix 系列技術棧進入維護模式（不再添加新特性）
最近， Netflix 宣布 Hystrix 正在進入維護模式 。自 2016 年以來， Ribbon 已處于類似狀態(tài) 。雖然 Hystrix 和 Ribbon 現(xiàn)已處于維護模式，但它們仍然在 Netflix 大規(guī)模部署 。
Hystrix Dashboard 和 Turbine 已被 Atlas 取代 。這些項目的最后一次提交分別是 2 年前和 4 年前 。Zuul1 和 Archaius1 都被后來不兼容的版本所取代 。
以下 Spring Cloud Netflix 模塊和相應的 Starter 將進入維護模式：
將模塊置于維護模式 ， 意味著 Spring Cloud 團隊將不會再向模塊添加新功能 。我們將修復 block 級別的 bug 以及安全問題 ， 我們也會考慮并審查社區(qū)的小型 pull request 。
我們建議對這些模塊提供的功能進行以下替換
并發(fā)限制模塊，它是 Netflix 開源的限流器項目，Spring Cloud 在 Greenwich 版本中引入 spring-cloud-netflix-concurrency-limits
有些人對它可能比較陌生，也是 Netflix 公司開源項目，基于 Java 的配置管理類庫（apache common configuration 類庫的擴展），主要用于多配置存儲的動態(tài)獲取 。它主要的特性：
目前還中孵化中 ， Spring 可能是要抽象一個斷路器的統(tǒng)一規(guī)范，讓不同的斷路器（Hystrix、Resilience4j、 Sentinel（阿里開源） ）選擇使用
Spring Boot 2 中的 Spring Boot Actuator 底層用的就是 Micrometer，它是 Pivotal 公司（也就是 Spring 所在的公司）開源的監(jiān)控門面，類似于監(jiān)控世界的 Slf4j 。Resilience4j 自帶整合了 Micrometer ；目前還無法判斷是否比 Hystrix Dashboard /Turbine 的更強大，更好用 。
目前還中孵化中，使用上和 Ribbon 區(qū)別不大
Zuul 持續(xù)跳票 1 年多，1.x 是一個基于阻塞 IO 的 API Gateway 以及 Servlet；直到 2018 年 5 月，Zuul 2.x（基于 Netty，也是非阻塞的，支持長連接）才發(fā)布，但 Spring Cloud 暫時還沒有整合計劃 。Spring Cloud Gateway 比 Zuul 1.x 系列的性能和功能整體要好 。
Netflix 開源的組件（Archaius 1/Ribbon/Hystrix）都沒有使用 Spring Boot 的規(guī)范（spring-boot-configuration-processor），根本沒有 metadata.json 文件，于是這部分配置 IDE 無法給你提示

    推薦閱讀