gateway与zuul区别，api网关和服务网关

gateway与zuul区别

内部实现不同、支持异步不同、框架设计的角度不同、性能不同。

内部实现不同：gateway对比zuul多依赖了spring-webflux，在spring的支持下，功能更强大，内部实现了限流、负载均衡等，扩展性也更强，但同时也限制了仅适合于Spring Cloud套件zuul则可以扩展至其他微服务框架中。

是否支持异步：zuul仅支持同步gateway支持异步。理论上gateway则更适合于提高系统吞吐量（但不一定能有更好的性能），最终性能还需要通过严密的压测来决定。

框架设计的角度：gateway具有更好的扩展性，并且其已经发布了2.0.0的RELESE版本，稳定性也是非常好的。

性能：WebFlux模块的名称是spring-webflux，名称中的Flux来源于Reactor中的类 Flux。Spring webflux 有一个全新的非堵塞的函数式Reactive Web框架，可以用来构建异步的、非堵塞的、事件驱动的服务，在伸缩性方面表现非常好。使用非阻塞API。Websockets得到支持，并且由于它与Spring紧密集成，所以将会是一个更好的 开发 体验。Zuul1.x，是一个基于阻塞io的API Gateway。Zuul已经发布了Zuul 2.x，基于Netty，也是非阻塞的，支持长连接，但Spring Cloud暂时还没有整合计划。

api网关和服务网关

Zuul 1(阻塞)的应用场景

.cpu密集型任务

.简单操作的需求

.开发简单的需求

.实时请求高的

Zuul 2（非阻塞）的应用场景

.io密集的任务

.大请求或者大文件

.队列的流式数据

.超大量的连接

gateway其实就是相当于Zuul 2的，gateway就是因为Zuul 2停止维护，基于Zuul2的原理实现springcloud自己的网关gateway。

高可用集群部署

上一篇 <<

下一篇 >>> Gateway的谓词配置实例

推荐阅读：

<<<网关背景分类及常用框架

<<<微服务网关与过滤器的区别

<<

<<

<<

<<<如何保证微服务接口的安全

<<

<<

<<

<<

spring gateway源码解析

Spring Cloud提供了两套方便我们编写网关的中间件，分别是zuul和Spring GateWay,在zuul1的IO模型是使用BIO(图1-1)。而zuul2对IO模型使用NIO进行了重构(图1-2)。而Spring GateWay的IO模型是使用NIO。而在Netflix发布zuul2的时候Spring Cloud已经开始不集成到Spring Cloud中，因为Spring Cloud 等着zuul2集成太久，才有了Spring Gateway。Spring GateWay的架构是基于Spring webflux的基础上开发的。而对webflux的RP中涉及的Back Pressure、Stream、asynchronous好处不多说哈哈。

在Spring mvc是通过HandlerMapping解析请求链接，然后根据请求链接找到执行这个请求Controller类 。而在Spring GateWay中也是使用HandlerMapping对请求的链接进行解析匹配对应的Route进行代理转发到对应的服务。图2-1为整个请求的流程，用户请求先通过DispatcherHandler找到对应GateWwayHandlerMapping,再通过GateWwayHandlerMapping解析匹配到对应的Handler。Handler处理完后，再经过Filter，最终到Proxied Service.

1.请求先由DispatcherHanlder进行处理，DispatcherHanlder初始化的时候会从IOC中查找实现HandlerMapping接口的实现类。然后保存到内部变量handlerMappings中，DispatcerHandler调用Handler方法迭代handler

Mappings中的HandlerMapping,

2.这里只讲解RoutePredicateHandlerMapping，因此然后调用RoutePredicateHandlerMapping中的获取路由的方法，当RoutePredicateHandlerMapping获取到对应的路由的时候会将Route存储到ServerWebExchanges的属性中，然后返回实现了WebHandler接口的FilteringWebHandler。FilteringWebHandler是一个存放过滤器的Handler。

3.最后DispatcherHanlder通过SimpleHandlerAdapter适配器的方式调用FilteringWebHandler的handler方法，FilteringWebHandler调用所有的过滤器，包括proxy filter。通过proxyFilter请求被代理的服务。处理完毕后，并将Response响应回去。

图3-1为handler类关系图。这里主要涉及到Spring GateWay相关类的探讨。如：Spring Webflux使用到的RouteFuntionMapping和SimpleUrlHandlerMapping等不做探讨。

HandlerMapping和Ordered接口主要定义了获取getHandler和当前hanler加载顺序。AbstractHandlerMapping在getHanlder封装了CORS处理。因为所有Handler都可能会涉及到CORS的处理，抽象到AbstractHandlerMapping处理，再提供了getHandlerInternal让子类实现具体的查找Handler的方法。

RoutePredicateHandlerMapping是处理获取路由的hanlder。Route

PredicateHandlerMapping中的RouteLocator是存储了我们启动的时候加载的路由对象信息。获取路由的时候，调用RoutePredicateHanlderMapping的getHandlerInternal方法从RouteLocator获取路由存放在ServerWebExchange中，返回webFilter。

RouteLocator主要作用是提供获取路由的类型。我们在分析Route

PredicateHandlerMapping的时候，知道RoutePredicateHandlerMapping获取路由是通过RouteLocator进行获取的。那么我们这里分析下RouteLocator加载路由。

Route主要为三部分：

最总的 RouteLocator是CachingRoutelocator。加载过程是自上而下进行创建。

第二种方式是通过Properties文件进行创建路由。Properties路由的创建包括：PropertiesRouteDefinitionLocator和DiscoveryClientRouteDefinitionLocator.

第三种方式是通过MYSQL或者Reids、内存（InMemoryRouteDefinitionRepository）方式创建路由。实现RouteDefinitionRepository接口实现接口中的方式。InMemoryRouteDefinitionRepository为默认方式。

Filter我们区分为全局Filter和RouteFilter

在转发过程分析中我们知道最终的代理请求是通过一个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 为开发人员提供了快速构建分布式系统中一些常见模式的工具（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线）。分布式系统的协调导致了样板模式, 使用 Spring Cloud 开发人员可以快速地支持实现这些模式的服务和应用程序。他们将在任何分布式环境中运行良好，包括开发人员自己的笔记本电脑，裸机数据中心，以及 Cloud Foundry 等托管平台。

目前业界对 Spring Cloud 使用最广的就是 Spring Cloud Netflix 了。后来 采用 Spring Cloud Alibaba 方案来替代 Spring Cloud Netflix

2018 年 12 月 12 日，Netflix 宣布 Spring Cloud Netflix 系列技术栈进入维护模式（不再添加新特性）

最近， Netflix 宣布 Hystrix 正在进入维护模式。自 2016 年以来， Ribbon 已处于类似状态。虽然 Hystrix 和 Ribbon 现已处于维护模式，但它们仍然在 Netflix 大规模部署。

Hystrix Dashboard 和 Turbine 已被 Atlas 取代。这些项目的最后一次提交分别是 2 年前和 4 年前。 Zuul1 和 Archaius1 都被后来不兼容的版本所取代。

以下 Spring Cloud Netflix 模块和相应的 Starter 将进入维护模式：

将模块置于维护模式，意味着 Spring Cloud 团队将不会再向模块添加新功能。我们将修复 block 级别的 bug 以及安全问题，我们也会考虑并审查社区的小型 pull request。

我们建议对这些模块提供的功能进行以下替换

并发限制模块，它是 Netflix 开源的限流器项目，Spring Cloud 在 Greenwich 版本中引入 spring-cloud-netflix-concurrency-limits

有些人对它可能比较陌生，也是 Netflix 公司开源项目，基于 Java 的配置管理类库（apache common configuration 类库的扩展），主要用于多配置存储的动态获取。它主要的特性：

目前还中孵化中，Spring 可能是要抽象一个断路器的统一规范，让不同的断路器（Hystrix、Resilience4j、 Sentinel（阿里开源） ）选择使用

Spring Boot 2 中的 Spring Boot Actuator 底层用的就是 Micrometer，它是 Pivotal 公司（也就是 Spring 所在的公司）开源的监控门面，类似于监控世界的 Slf4j。 Resilience4j 自带整合了 Micrometer ；目前还无法判断是否比 Hystrix Dashboard /Turbine 的更强大，更好用。

目前还中孵化中，使用上和 Ribbon 区别不大

Zuul 持续跳票 1 年多，1.x 是一个基于阻塞 IO 的 API Gateway 以及 Servlet；直到 2018 年 5 月，Zuul 2.x（基于 Netty，也是非阻塞的，支持长连接）才发布，但 Spring Cloud 暂时还没有整合计划。Spring Cloud Gateway 比 Zuul 1.x 系列的性能和功能整体要好。

Netflix 开源的组件（Archaius 1/Ribbon/Hystrix）都没有使用 Spring Boot 的规范（spring-boot-configuration-processor），根本没有 metadata.json 文件，于是这部分配置 IDE 无法给你提示

以上就是关于gateway与zuul区别，api网关和服务网关的全部内容，以及gateway与zuul区别的相关内容,希望能够帮到您。

本文链接：http://www.afey.cn/smjk/27118.html
版权声明：本文来自用户投稿，不代表本站立场，如有侵犯到您的权益，请联系我们，我们将及时处理，共同维护良好的网络创作环境。