南京医院网站建设,网站制作模板过程,怎么做一考试网站,达县网站制作常见网关对比
目前常见的开源网关大致上按照语言分类有如下几类#xff1a; Nginxlua #xff1a;OpenResty、Kong、Orange、Abtesting gateway 等 Java #xff1a;Zuul/Zuul2、Spring Cloud Gateway、Kaazing KWG、gravitee、Dromara soul 等 Go #xff1a;Janus、fa…常见网关对比
目前常见的开源网关大致上按照语言分类有如下几类 Nginxlua OpenResty、Kong、Orange、Abtesting gateway 等 Java Zuul/Zuul2、Spring Cloud Gateway、Kaazing KWG、gravitee、Dromara soul 等 Go Janus、fagongzi、Grpc-gateway Dotnet Ocelot NodeJS Express Gateway、Micro Gateway
按照使用数量、成熟度等来划分主流的有 5个 OpenResty Kong Zuul、Zuul2 Spring Cloud Gateway
1. OpenResty
OpenResty是一个流量网关根据前面对流量网关的介绍就可以知道流量网关的指责。
OpenResty基于 Nginx与 Lua 的高性能 Web 平台其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。
通过揉和众多设计良好的 Nginx 模块OpenResty 有效地把 Nginx 服务器转变为一个强大的 Web 应用服务器基于它开发人员可以使用 Lua 编程语言对 Nginx 核心以及现有的各种 Nginx C 模块进行脚本编程构建出可以处理一万以上并发请求的极端高性能的 Web 应用
OpenResty 最早是顺应 OpenAPI 的潮流做的所以 Open 取自“开放”之意而Resty便是 REST 风格的意思。虽然后来也可以基于 ngx_openresty 实现任何形式的 web service 或者传统的 web 应用。
也就是说 Nginx 不再是一个简单的静态网页服务器也不再是一个简单的反向代理了。第二代的 openresty 致力于通过一系列 nginx 模块把nginx扩展为全功能的 web 应用服务器。
ngx_openresty 是用户驱动的项目后来也有不少国内用户的参与从 openresty.org 的点击量分布上看国内和国外的点击量基本持平。
ngx_openresty 目前有两大应用目标
通用目的的 web 应用服务器。在这个目标下现有的 web 应用技术都可以算是和 OpenResty 或多或少有些类似比如 Nodejs PHP 等等。ngx_openresty 的性能包括内存使用和 CPU 效率算是最大的卖点之一。Nginx 的脚本扩展编程用于构建灵活的 Web 应用网关和 Web 应用防火墙。有些类似的是 NetScaler。其优势在于 Lua 编程带来的巨大灵活性。
2. Kong
Kong基于OpenResty开发也是流量层网关 是一个云原生、快速、可扩展、分布式的Api 网关。继承了OpenResty的高性能、易扩展性等特点。Kong通过简单的增加机器节点可以很容易的水平扩展。同时功能插件化可通过插件来扩展其能力。而且在任何基础架构上都可以运行。具有以下特性 提供了多样化的认证层来保护Api。 可对出入流量进行管制。 提供了可视化的流量检查、监视分析Api。 能够及时的转换请求和相应。 提供log解决方案 可通过api调用Serverless 函数。
Kong解决了什么问题
当我们决定对应用进行微服务改造时应用客户端如何与微服务交互的问题也随之而来毕竟服务数量的增加会直接导致部署授权、负载均衡、通信管理、分析和改变的难度增加。
面对以上问题API GATEWAY是一个不错的解决方案其所提供的访问限制、安全、流量控制、分析监控、日志、请求转发、合成和协议转换功能可以解放开发者去把精力集中在具体逻辑的代码而不是把时间花费在考虑如何解决应用和其他微服务链接的问题上。 可以看到Kong解决的问题。专注于全局的Api管理策略全局流量监控、日志记录、全局限流、黑白名单控制、接入请求到业务系统的负载均衡等。
Kong的优点以及性能
在众多 API GATEWAY 框架中Mashape 开源的高性能高可用API网关和API服务管理层——KONG基于 NGINXLua特点尤为突出它可以通过插件扩展已有功能这些插件使用 lua 编写在API请求响应循环的生命周期中被执行。于此同时KONG本身提供包括 HTTP 基本认证、密钥认证、CORS、TCP、UDP、文件日志、API请求限流、请求转发及 NGINX 监控等基本功能。目前Kong 在 Mashape 管理了超过 15000 个 API为 200000 开发者提供了每月数十亿的请求支持。
Kong架构
Kong提供一些列的服务这就不得不谈谈内部的架构: 首先最底层是基于Nginx Nginx是高性能的基础层 一个良好的负载均衡、反向代理器然后在此基础上增加Lua脚本库形成了OpenResty拦截请求 响应生命周期可以通过Lua编写脚本所以插件比较丰富。
关于Kong的一些插件库以及如何配置可以参考简书:开源API网关系统Kong教程入门到精通 https://www.jianshu.com/p/a68e45bcadb6
3. Zuul1.0
Zuul是所有从设备和web站点到Netflix流媒体应用程序后端请求的前门。作为一个边缘服务应用程序Zuul被构建来支持动态路由、监视、弹性和安全性。它还可以根据需要将请求路由到多个Amazon自动伸缩组。
Zuul使用了一系列不同类型的过滤器使我们能够快速灵活地将功能应用到服务中。
过滤器
过滤器是Zuul的核心功能。它们负责应用程序的业务逻辑可以执行各种任务。 Type 通常定义过滤器应用在哪个阶段 Async 定义过滤器是同步还是异步 Execution Order 执行顺序 Criteria 过滤器执行的条件 Action 如果条件满足过滤器执行的动作
Zuul提供了一个动态读取、编译和运行这些过滤器的框架。过滤器之间不直接通信而是通过每个请求特有的RequestContext共享状态。
下面是Zuul的一些过滤器:
Incoming
Incoming过滤器在请求被代理到Origin之前执行。这通常是执行大部分业务逻辑的地方。例如:认证、动态路由、速率限制、DDoS保护、指标。
Endpoint
Endpoint过滤器负责基于incoming过滤器的执行来处理请求。Zuul有一个内置的过滤器ProxyEndpoint用于将请求代理到后端服务器因此这些过滤器的典型用途是用于静态端点。例如:健康检查响应静态错误响应404响应。
Outgoing
Outgoing过滤器在从后端接收到响应以后执行处理操作。通常情况下它们更多地用于形成响应和添加指标而不是用于任何繁重的工作。例如:存储统计信息、添加/剥离标准标题、向实时流发送事件、gziping响应。
过滤器类型
下面是与一个请求典型的生命周期对应的标准的过滤器类型
PRE 路由到Origin之前执行ROUTING 路由到Origin期间执行POST 请求被路由到Origin之后执行ERROR 发生错误的时候执行
这些过滤器帮助我们执行以下功能 身份验证和安全性 识别每个资源的身份验证需求并拒绝不满足它们的请求 监控 在边缘跟踪有意义的数据和统计数据以便给我们一个准确的生产视图 动态路由 动态路由请求到不同的后端集群 压力测试 逐渐增加集群的流量以评估性能 限流 为每种请求类型分配容量并丢弃超过限制的请求 静态响应处理 直接在边缘构建一些响应而不是将它们转发到内部集群
Zuul 1.0 请求生命周期 Netflix宣布了通用API网关Zuul的架构转型。Zuul原本采用同步阻塞架构转型后叫作Zuul2采用异步非阻塞架构。Zuul2和Zuul1在架构方面的主要区别在于Zuul2运行在异步非阻塞的框架上比如Netty。Zuul1依赖多线程来支持吞吐量的增长而Zuul 2使用的Netty框架依赖事件循环和回调函数。
4. Zuul2.0
Zuul 2.0 架构图 上图是Zuul2的架构和Zuul1没有本质区别两点变化
前端用Netty Server代替Servlet目的是支持前端异步。后端用Netty Client代替Http Client目的是支持后端异步。过滤器换了一下名字用Inbound Filters代替Pre-routing Filters用Endpoint Filter代替Routing Filter用Outbound Filters代替Post-routing Filters。
Inbound Filters 路由到 Origin 之前执行可以用于身份验证、路由和装饰请求
Endpoint Filters 可用于返回静态响应否则内置的ProxyEndpoint过滤器将请求路由到Origin
Outbound Filters 从Origin那里获取响应后执行可以用于度量、装饰用户的响应或添加自定义header
有两种类型的过滤器sync 和 async。因为Zuul是运行在一个事件循环之上的因此从来不要在过滤中阻塞。如果你非要阻塞可以在一个异步过滤器中这样做并且在一个单独的线程池上运行否则可以使用同步过滤器。
上文提到过Zuul2开始采用了异步模型
优势 是异步非阻塞模式启动的线程很少基本上一个CPU core上只需启一个事件环处理线程它使用的线程资源就很少上下文切换(Context Switch)开销也少。非阻塞模式可以接受的连接数大大增加可以简单理解为请求来了只需要进队列这个队列的容量可以设得很大只要不超时队列中的请求都会被依次处理。
不足 异步模式让编程模型变得复杂。一方面Zuul2本身的代码要比Zuul1复杂很多Zuul1的代码比较容易看懂Zuul2的代码看起来就比较费劲。另一方面异步模型没有一个明确清晰的请求-处理-响应执行流程(call flow)它的流程是通过事件触发的请求处理的流程随时可能被切换断开内部实现要通过一些关联id机制才能把整个执行流再串联起来这就给开发调试运维引入了很多复杂性比如你在IDE里头调试异步请求流就非常困难。另外ThreadLocal机制在这种异步模式下就不能简单工作因为只有一个事件环线程不是每个请求一个线程也就没有线程局部的概念所以对于CAT这种依赖于ThreadLocal才能工作的监控工具调用链埋点就不好搞(实际可以工作但需要进行特殊处理)。
总体上异步非阻塞模式比较适用于IO密集型(IO bound)场景这种场景下系统大部分时间在处理IOCPU计算比较轻少量事件环线程就能处理。
Zuul 与 Zuul 2 性能对比 Netflix给出了一个比较模糊的数据大致Zuul2的性能比Zuul1好20%左右 这里的性能主要指每节点每秒处理的请求数。为什么说模糊呢因为这个数据受实际测试环境流量场景模式等众多因素影响你很难复现这个测试数据。即便这个20%的性能提升是确实的其实这个性能提升也并不大和异步引入的复杂性相比这20%的提升是否值得是个问题。Netflix本身在其博文22和ppt11中也是有点含糊其词甚至自身都有一些疑问的。
5. Spring Cloud Gateway
SpringCloud Gateway 是 Spring Cloud 的一个全新项目该项目是基于 Spring 5.0Spring Boot 2.0 和 Project Reactor 等技术开发的网关它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。
SpringCloud Gateway 作为 Spring Cloud 生态系统中的网关目标是替代 Zuul在Spring Cloud 2.0以上版本中没有对新版本的Zuul 2.0以上最新高性能版本进行集成仍然还是使用的Zuul 2.0之前的非Reactor模式的老版本。而为了提升网关的性能SpringCloud Gateway是基于WebFlux框架实现的而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。
Spring Cloud Gateway 的目标不仅提供统一的路由方式并且基于 Filter 链的方式提供了网关基本的功能例如安全监控/指标和限流。
Spring Cloud Gateway 底层使用了高性能的通信框架Netty 。
SpringCloud Gateway 特征
SpringCloud官方对SpringCloud Gateway 特征介绍如下
1基于 Spring Framework 5Project Reactor 和 Spring Boot 2.0
2集成 Hystrix 断路器
3集成 Spring Cloud DiscoveryClient
4Predicates 和 Filters 作用于特定路由易于编写的 Predicates 和 Filters
5具备一些网关的高级功能动态路由、限流、路径重写
从以上的特征来说和Zuul的特征差别不大。SpringCloud Gateway和Zuul主要的区别还是在底层的通信框架上。
简单说明一下上文中的三个术语
Filter 过滤器
和Zuul的过滤器在概念上类似可以使用它拦截和修改请求并且对上游的响应进行二次处理。过滤器为org.springframework.cloud.gateway.filter.GatewayFilter类的实例。
Route 路由
网关配置的基本组成模块和Zuul的路由配置模块类似。一个Route模块 由一个 ID一个目标 URI一组断言和一组过滤器定义。如果断言为真则路由匹配目标URI会被访问。
Predicate 断言
这是一个 Java 8 的 Predicate可以使用它来匹配来自 HTTP 请求的任何内容例如 headers 或参数。断言的 输入类型是一个 ServerWebExchange。
几种网关的对比
