为什么要用微服务网关（微服务统一网关）

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

本文目录一览：

• 1、什么是网关，为什么要用网关？
• 2、Spring Cloud
• 3、Spring Cloud——微服务网关介绍
• 4、微服务 六：服务网关

什么是网关，为什么要用网关？

网关(Gateway)又称网间连接器、协议转换器。网关在网络层以上实现网络互连，是最复杂的网络互连设备，仅用于两个高层协议不同的网络互连。网关既可以用于广域网互连，也可以用于局域网互连。 网关是一种充当转换重任的计算机系统或设备。使用在不同的通信协议、数据格式或语言，甚至体系结构完全不同的两种系统之间，网关是一个翻译器。与网桥只是简单地传达信息不同，网关对收到的信息要重新打包，以适应目的系统的需求。同层--应用层。

扩展资料

大家都知道，从一个房间走到另一个房间，必然要经过一扇门。同样，从一个网络向另一个网络发送信息，也必须经过一道“关口”，这道关口就是网关。顾名思义，网关（Gateway） [1]  就是一个网络连接到另一个网络的“关口”。也就是网络关卡。

网关(Gateway)又称网间连接器、协议转换器。默认网关在网络层上以实现网络互连，是最复杂的网络互连设备，仅用于两个高层协议不同的网络互连。网关的结构也和路由器类似，不同的是互连层。网关既可以用于广域网互连，也可以用于局域网互连。

Spring Cloud

本文中为什么要用微服务网关我们主要介绍微服务开发框架——Spring Cloud。尽管Spring Cloud带有"Cloud"的字样为什么要用微服务网关，但它并不是云计算解决方案为什么要用微服务网关，而是Spring Boot的基础上构建的，用于快速构建分布式系统的通用模式的工具集。

Spring Cloud有以下特点:

由上图可知，Spring Cloud是以 英文单词+SR+数字 的形式命名版本号的。那么英文单词和SR分别表示什么呢为什么要用微服务网关？
因为Spring Cloud是一个综合项目，它包含很多子项目。由于子项目也维护着自己的版本号，Spring Cloud采用了这种命名方式，从而避免与子项目的版本混淆。其中英文单词如Edware是伦敦某地铁站名，它们按照字母顺序发行，可以将其理解为主版本的演进。SR表示"Service Release"，一般表示Bug修复。

版本兼容性如下

版本内容

可参考官方文档： https://spring.io/projects/spring-cloud#overview

我的上一篇博客(微服务理论篇)中谈到，对单体应用进行服务拆分得到各个微服务，而这些服务又是相互独立的，那么我们如何知道各个微服务的健康状态、如何知道某个微服务的存在呢？由此、一个拥有服务发现的框架显得尤为重要。这也就是Eureka诞生的原因。

综上，Eureka通过心跳检查、客户端缓存等机制，确保了系统的高可用性、灵活性和可伸缩性。

通过使用Eureka已经实现了微服务的注册与发现。启动各个微服务时，Eureka Client会把自己的网络信息注册到Eureka Server上。似乎一切更美好了一些。然而，这样的架构依然有一些问题，如负载均衡。一般来说，各个微服务都会部署多个实例。那么服务消费者要如何将请求分摊到多个服务提供实例上呢？

如果服务提供者相应非常慢，那么消费者对提供者的请求就会被强制等待，知道提供者响应或超时。在高负载场景下，如果不作任何处理，此类问题可能会导致服务消费者的资源耗竭甚至整个系统崩溃。
微服务架构的应用系统通常包含多个服务层。微服务之间通过网络进行通信，从而支撑起整个应用系统，因此，微服务之间难免存在依赖关系。而这种由于"基础服务故障"导致"级联故障"的现象称为雪崩效应。

如图所示，A最为服务提供者（基础服务），B为A的服务消费者，C和D是B的服务消费者。当A不可用引起了B的不可用，并将不可用像滚雪球一样放大到C和D时，雪崩效应就形成了。
那么Hystrix是如何容错的呢？

以下对该图做个简单讲解：

Zuul作为微服务架构中的微服务网关。微服务架构经过前几个组件的组合，已经有了基本的雏形了，那么我们为什么还要使用微服务网关呢？我们可以想象，一般情况下我们一个业务并不是只调用一个接口就可以完成一个业务需求。
如果让客户端直接与各个微服务通信，会有以下问题：

如图，微服务网关封装了应用程序的内部结构，客户端只须跟网关交互，而无须直接调用特定微服务接口。同时，还有以下优点：

为什么要同一管理微服务配置？
对于传统的单体应用，常常使用配置文件管理所有配置。例如一个Spring Boot 项目开发的单体应用，可以将配置内容放到application.yml文件中。如果需要切换环境，可以设置多个Profile,并在启用应用时指定spring.profile.active={profile}。
而在微服务架构中，微服务的配置管理一般有以下需求：

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

微服务 六：服务网关

服务除为什么要用微服务网关了内部相互之间调用和通信之外为什么要用微服务网关，最终要以某种方式暴露出去，才能让外界系统（例如客户的浏览器、移动设备等等）访问到，这就涉及服务的前端路由，对应的组件是服务网关(Service Gateway)，见图（15），网关是连接企业内部和外部系统的一道门，有如下关键作用：

服务反向路由，网关要负责将外部请求反向路由到内部具体的微服务，这样虽然企业内部是复杂的分布式微服务结构，但是外部系统从网关上看到的就像是一个统一的完整服务，网关屏蔽了后台服务的复杂性，同时也屏蔽了后台服务的升级和变化。安全认证和防爬虫，所有外部请求必须经过网关，网关可以集中对访问进行安全控制，比如用户认证和授权，同时还可以分析访问模式实现防爬虫功能，网关是连接企业内外系统的安全之门。

限流和容错，在流量高峰期，网关可以限制流量，保护后台系统不被大流量冲垮，在内部系统出现故障时，网关可以集中做容错，保持外部良好的用户体验。

监控，网关可以集中监控访问量，调用延迟，错误计数和访问模式，为后端的性能优化或者扩容提供数据支持。

日志，网关可以收集所有的访问日志，进入后台系统做进一步分析。

图（15）gateway服务图

除以上基本能力外，网关还可以实现线上引流，线上压测，线上调试(Surgical debugging)，金丝雀测试(Canary Testing)，数据中心双活(Active-Active HA)等高级功能。

网关通常工作在7层，有一定的计算逻辑，一般以集群方式部署，前置LB进行负载均衡。

开源的网关组件有Netflix的Zuul，其工作原理如下图。

图（16）zuul工作原理图

在介绍过服务注册表和网关等组件之后，为什么要用微服务网关我们可以通过一个简化的微服务架构图(17)来更加直观地展示整个微服务体系内的服务注册发现和路由机制，该图假定采用进程内LB服务发现和负载均衡机制。在图（17）的微服务架构中，服务简化为两层，后端通用服务（也称中间层服务Middle Tier Service）和前端服务（也称边缘服务Edge Service，前端服务的作用是对后端服务做必要的聚合和裁剪后暴露给外部不同的设备，如PC，Pad或者Phone）。后端服务启动时会将地址信息注册到服务注册表，前端服务通过查询服务注册表就可以发现然后调用后端服务；前端服务启动时也会将地址信息注册到服务注册表，这样网关通过查询服务注册表就可以将请求路由到目标前端服务，这样整个微服务体系的服务自注册自发现和软路由就通过服务注册表和网关串联起来了。如果以面向对象设计模式的视角来看，网关类似Proxy代理或者Façade门面模式，而服务注册表和服务自注册自发现类似IoC依赖注入模式，微服务可以理解为基于网关代理和注册表IoC构建的分布式系统。

图（17）简化的微服务架构图 关于为什么要用微服务网关和微服务统一网关的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 为什么要用微服务网关的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于微服务统一网关、为什么要用微服务网关的信息别忘了在本站进行查找喔。

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