微服务网关系统（微服务架构 网关）

本篇文章给大家谈谈微服务网关系统，以及微服务架构 网关对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享微服务网关系统的知识，其中也会对微服务架构 网关进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、Spring Cloud——微服务网关介绍
• 2、Spring Cloud Zuul 微服务网关
• 3、微服务核心组件 Zuul 网关原理剖析

Spring Cloud——微服务网关介绍

为了解决以上的问题，API网关应运而生，加入网关后应用架构变为下图所示。

当引入API网关后，在用户端与微服务之间建立了一道屏障，通过API网关对微服务提供了统一的访问入口，所有用户端的请求被API网关拦截，并在此基础上可以实现额外的功能：

OpenResty是一个强大的Web应用服务器，web开发人员可以使用Lua脚本语言调用Nginx支持的各种以C以及Lua模块。

在性能方面，OpenResty可以快速构造出足以胜任10K以上并发连接响应的超高性能Web应用系统。

在国内，360、阿里云、腾讯网、去哪儿、酷狗音乐、新浪等都是OpenResty的深度用户。

但OpenResty是一款独立的产品，与主流的注册中心，存在一定的兼容问题，需要架构师独立实现其服务注册、发现功能。

Zuul是Netflix开源的微服务网关，主要职责是对用户请求进行路由转发与过滤。早期Spring Cloud与Netflix合作，使用Zuul作为微服务架构网关首选产品。

Zuul是基于J2EE Servlet实现路由转发，网络通信采用同步方式。

zuul 是netflix开源的一个API Gateway 服务器，本质上是一个web servlet应用。

Zuul可以通过加载动态过滤机制，从而实现以下各项功能：

Zuul的核心是一系列的filters，其作用可以类比Servlet框架的Filter，或者AOP。工作原理如下图所示：

Zuul可以对Groovy过滤器进行动态的加载，编译，运行。

Zuul2.x设计更为先进，基于Netty 非阻塞和支持长连接， 但是 SpringCloud 目前没有整合。 Zuul2.x 的性能较 Zuul1.x 有较大的提升。

Zuul2.x引入了Netty和RxJava，正如之前的 ZuulFilter 分为了 Pre、Post、Route、Error，Zuul2的Filter分为三种类型：

Spring 自己开发的新一代API网关产品，基于NIO异步处理，摒弃了Zuul基于Servlet同步通信的设计。

Spring Cloud Gateway 作为 Spring Cloud 生态系统中的网关，目标是替代 Netflix Zuul，其不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/指标，和限流。

关键特征：

在性能方面，根据官方提供的基准测试， Spring Cloud Gateway 的 RPS（每秒请求数）是Zuul 的 1.6 倍。

Spring Cloud Gateway十分优秀，Spring Cloud Alibaba也默认选用该组件作为网关产品。

客户端向 Spring Cloud Gateway 发出请求。如果 Gateway Handler Mapping 中找到与请求相匹配的路由，将其发送到 Gateway Web Handler。Handler 再通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑，然后返回。 过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前（“pre”）或之后（“post”）执行业务逻辑。

Spring Cloud Gateway 的特征：

参考：
http://www.ityouknow.com/springcloud/2018/12/12/spring-cloud-gateway-start.html

http://www.likecs.com/show-50293.html

https://zhuanlan.zhihu.com/p/299608850?utm_source=wechat_session

https://juejin.cn/post/6844903965352525838

https://blog.csdn.net/weixin_38361347/article/details/114108368

http://www.zyiz.net/tech/detail-98256.html

Spring Cloud Zuul 微服务网关

Zuul is the front door for all requests from devices and web sites to the backend of the Netflix streaming application.

Zuul 是从设备和网站到后端应用程序或服务的所有请求的入口，为内部服务提供了可配置的对外URL到服务的映射关系。

Zuul 网关提供了如下功能：

1、路由转发：接收一切外界请求，转发到后端的微服务上去；

2、过滤器Filter：在服务网关中可以完成一系列的横切功能，例如权限校验、限流以及监控等，这些都可以通过过滤器完成（其实路由转发也是通过过滤器实现的）。

Zuul Server 工程中需要引入的依赖项

如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务

在Spring Boot主函数上通过注解 @EnableZuulProxy 来开启网关路由功能，这样可以将请求转发到对应的服务。 按照约定, 一个ID为"client"的服务会收到 /client 请求路径的代理请求(前缀会被剥离)。

Zuul使用Ribbon定位服务注册中的实例, 并且所有的请求都在hystrix的command中执行, 所以失败信息将会展现在Hystrix Dashboard中, 并且一旦断路器打开, 代理请求将不会尝试去链接服务。

如下是Eureka，Zuul，Ribbon 交互图：

微服务核心组件 Zuul 网关原理剖析

Zuul 网关是具体核心业务服务的看门神，相比具体实现业务的系统服务来说它是一个边缘服务，主要提供动态路由，监控，弹性，安全性等功能。在分布式的微服务系统中，系统被拆为了多套系统，通过zuul网关来对用户的请求进行路由，转发到具体的后台服务系统中。

本 Chat 主要内容如下：

网关是具体核心业务服务的看门神，相比具体实现业务的系统服务来说它是一个边缘服务，主要提供动态路由，监控，弹性，安全性等功能，下面我们从单体应用到多体应用的演化过程来讲解网关的演化历程。

一般业务系统发展历程都是基本相似的，从单体应用到多应用，从本地调用到远程调用。对应单体应用架构模式（如下图1），由于只需一个应用，所有业务模块的功能都打包为了一个 War 包进行部署，这样可以减少机器资源和部署的繁琐。

图1 单体应用

在单体应用中，网关模块是和应用部署到同一个jvm进程里面的，当外部移动设备或者web站点访问单体应用的功能时候，请求是先被应用的网关模块拦截的，网关模块对请求进行鉴权、限流等动作后在把具体的请求转发到当前应用对应的模块进行处理。

随着业务的发展，网站的流量会越来越大，在单体应用中简单的通过加机器的方式可以带来的承受流量冲击的能力也越来越低，这时候就会考虑根据业务将单体应用拆成若干个功能独立的应用，单体应用拆为多个应用后，由于不同的应用开发对应的功能，所以多应用开发之间可以独立开发而不用去理解对方的业务，另外不同的应用模块只承受对应业务流量的压力，不会对其他应用模块造成影响，这时候多体的分布式系统就出现了，如下图2。

图2 多体应用

如上图在多体应用中业务模块A和B单独起了个应用，每个应用里面有自己的网关模块，如果业务模块多了，那么每个应用都有自己的网关模块，这样复用性不好，所以可以考虑把网关模块提起出来，单独作为一个应用来做服务路由，如下图3：

如上图当移动设备发起请求时候是具体发送到网关应用的，经过鉴权后请求会被转发到具体的后端服务应用上，对应前端移动设备来说他们不在乎也不知道后端服务器应用是一个还是多个，他们只能感知到网关应用的存在。

Zuul是Netflix开源的一个网关组件，在Netflix内部系统中Zuul被用来作为内部系统的门面，如下图是Zuul在Netflix内部使用的一个架构图：

如上图最上层的移动设备或者网站首先通过aws负载均衡器把请求路由到zuul网关上，zuul网关则负责把请求路由到具体的后端service上。

Zuul开源地址 https://github.com/Netflix/zuul

Zuul网关的核心是一系列的过滤器，这些过滤器可以对请求或者响应结果做一系列过滤，Zuul 提供了一个框架可以支持动态加载，编译，运行这些过滤器，这些过滤器是使用责任链方式顺序对请求或者响应结果进行处理的，这些过滤器直接不会直接进行通信，但是通过责任链传递的RequestContext参数可以共享一些东西。

虽然Zuul 支持任何可以在jvm上跑的语言，但是目前zuul的过滤器只能使用Groovy脚本来编写。编写好的过滤器脚本一般放在zuul服务器的固定目录，zuul服务器会开启一个线程定时去轮询被修改或者新增的过滤器，然后动态进行编译，加载到内存，然后等后续有请求进来，新增或者修改后的过滤器就会生效了。

在zuul中过滤器分为四种：

如下图为zuul1.0的工作原理：

如上图，当zuul接受到请求后，首先会由前置过滤器进行处理，然后在由路由过滤器具体把请求转发到后端应用，然后在执行后置过滤器把执行结果写会到请求方，当上面任何一个类型过滤器执行出错时候执行该过滤器。

本节作者使用zuul的版本：

...

....

总结：zuul1.0时候当zuul接受到一个请求后会同步执行前置过滤器、路由过滤器、后置过滤器，等执行完毕后在同步把结果返回为调用方，调用方在整个过程中是阻塞的。其实SpringBoot集成的zuul就是自己实现了个前置过滤器做选择路由，然后自己实现了个路由过滤器根据前置过滤器选择的路由具体做路由转发。

Netty作为高性能异步网络通讯框架，在dubbo，rocketmq,sofa等知名开源框架中都有使用，如下图zuul2.0使用netty server作为网关监听服务器监听客户端发来的请求，然后把请求转发到前置过滤器（inbound filters）进行处理，处理完毕后在把请求使用netty client代理到具体的后端服务器进行处理，处理完毕后在把结果交给后者过滤器（outbound filters）进行处理，然后把处理结果通过nettyServer写回客户端。

...
总: 在zuul1.0时候客户端发起的请求后需要同步等待zuul网关返回，zuul网关这边对每个请求会分派一个线程来进行处理，这会导致并发请求数量有限。而zuul2.0使用netty作为异步通讯，可以大大加大并发请求量。 关于微服务网关系统和微服务架构 网关的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 微服务网关系统的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于微服务架构 网关、微服务网关系统的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。