微服务网关与普通网关(微服务网关的功能有哪些)

网友投稿 247 2022-12-30


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

本文目录一览:

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

微服务网关

1、路由转发微服务网关与普通网关:接收一切外界请求微服务网关与普通网关,转发到后端的微服务上去微服务网关与普通网关
2、 过滤器 微服务网关与普通网关:在服务网关中可以完成一系列的横切功能,例如权限校验、限流以及监控等,这些都可以通过过滤器完成(其实路由转发也是通过过滤器实现的)。

https://zhuanlan.zhihu.com/p/101341556
https://blog.csdn.net/ztemt_sw2/article/details/106208946
https://studygolang.com/articles/13254
https://blog.csdn.net/micl200110041/article/details/82013032

5、微服务网关

目前常见的开源网关大致上按照语言分类有如下几类:

按照使用数量、成熟度等来划分,主流的有 4 个:

摘自: 百亿流量 API 网关设计与实践

微服务网关层

API网关是所有客户端的统一入口。路由服务可以被用于很多目的微服务网关与普通网关,例如日志、限流、认证,从而做到应用无感知。API网关对于任意一种处理请求有两种方式处理。一部分请求只要简单路由到相应的服务;还有一些请求需要拆分到多个服务。API Gateway是实现微服务重要的组件之一,常用的网关Zuul, Nginx, Spring Cloud, Linkerd,Envoy,UnderTow。

为了评估API网关各自的性能,微服务网关与普通网关我们使用Apache的ab作为压测工具。(另外还可以用Gatling做性能测试)

测试结果和心得如下:

【分享】什么是API网关?大公司为什么都有API网关?

在这篇文章中将微服务网关与普通网关我们一起来探讨当前的API网关的作用。
一、API网关的用处
API网关我的分析中会用到以下三种场景。

二、API网关在企业整体架构中的地位
一个企业随着信息系统复杂度的提高微服务网关与普通网关,必然出现外部合作伙伴应用、企业自身的公网应用、企业内网应用等微服务网关与普通网关,在架构上应该将这三种应用区别开,三种应用的安排级别、访问方式也不一样。
因此在我的设计中将这三种应用分别用不同的网关进行API管理,分别是:API网关(OpenAPI合伙伙伴应用)、API网关(内部应用)、API网关(内部公网应用)。

三、企业中在如何应用API网关
1、对于OpenAPI使用的API网关来说,一般合作伙伴要以应用的形式接入到OpenAPI平台,合作伙伴需要到 OpenAPI平台申请应用。
因此在OpenAPI网关之外,需要有一个面向合作伙伴的使用的平台用于合作伙伴,这就要求OpenAPI网关需要提供API给这个用户平台进行访问。
如下架构:

当然如果是在简单的场景下,可能并不需要提供一个面向合作伙伴的门户,只需要由公司的运营人员直接添加合作伙伴应用id/密钥等,这种情况下也就不需要合作伙伴门户子系统。
2、对于内网的API网关,在起到的作用上来说可以认为是微服务网关,也可以认为是内网的API服务治理平台。
当企业将所有的应用使用微服务的架构管理起来,那么API网关就起到了微服务网关的作用。
而当企业只是将系统与系统之间的调用使用rest api的方式进行访问时使用API网关对调用进行管理,那么API网关起到的就是API服务治理的作用。
架构参考如下:

3、对于公司内部公网应用(如APP、公司的网站),如果管理上比较细致,在架构上是可能由独立的API网关来处理这部分内部公网应用,如果想比较简单的处理,也可以是使用面向合作伙伴的API网关。
如果使用独立的API网关,有以下的好处:
• 面向合作伙伴和面向公司主体业务的优先级不一样,不同的API网关可以做到业务影响的隔离。
• 内部API使用的管理流程和面向合作伙伴的管理流程可能不一样。
• 内部的API在功能扩展等方面的需求一般会大于OpenAPI对于功能的要求。
基于以上的分析,如果公司有能力,那么还是建议分开使用合作伙伴OPEN API网关和内部公网应用网关。

四、API网关解决方案
私有云解决方案如下:
• Kong是基于Nginx+Lua进行二次开发的方案
https://konghq.com/
• Eolinker和Kong比较接近,但是因为是国内公司开发的,后续的技术支持和培训比较友好。
https://www.eolinker.com
• Netflix Zuul,zuul是spring cloud的一个推荐组件, https://github.com/Netflix/zuul
• orange,这个开源程序也是国人开发的,不过这个是个人开发不是公司。
http://orange.sumory.com/
公有云解决方案:
• Amazon API Gateway, https://aws.amazon.com/cn/api-gateway/
• 阿里云API网关, https://www.aliyun.com/product/apigateway/
• 腾讯云API网关, https://cloud.tencent.com/product/apigateway
自开发解决方案:
• 基于Nginx+Lua+ OpenResty的方案,可以看到Eolinker,Kong,orange都是基于这个方案。
• 基于Netty、非阻塞IO模型。通过网上搜索可以看到国内的宜人贷等一些公司是基于这种方案。
• 基于Node.js的方案。这种方案是应用了Node.js天生的非阻塞的特性。
• 基于java Servlet的方案。zuul基于的就是这种方案,这种方案的效率不高,这也是zuul总是被诟病的原因。
五、企业怎么选择API网关
现在的亚马逊、阿里、腾讯云都在提供基础公有云的API网关,当然这些网关的基础功能肯定是没有问题,但是二次开发,扩展功能、监控功能可能就不能满足部分用户的定制需求了。
另外很多企业因为自身信息安全的原因,不能使用外网公有网的API网关服务,这样就只有选择私有云的方案了。
在需求上如果基于公有云的API网关只能做到由内部人员为外网人员申请应用,无法做到定制的合作伙伴门户,这也不适合于部分企业的需求。
如果作为微服务网关,大多数情况下是希望网关服务器和服务提供方服务器是要在内网的,在这里情况下也只有私有云的API网关才能满足需求。
综合上面的分析,基础公有云的API网关只有满足一部分简单客户的需求,对于很多企业来说私有云的API网关才是正确的选择。

微服务之网关聚合模式

使用网关可以将多个单独的请求聚合到一个请求中。当客户端必须对多个不同的后端系统进行多次调用操作时,此模式很有用。

有时候执行单个任务时,客户端可能必须对不同的各个后端服务进行多次调用。因为微服务网关与普通网关他们依赖于多个服务,那么客户端必须调用不同的服务接口以完成这次请求,这样就会导致请求过多而浪费很多的资源。当任何新功能或服务添加到应用程序时,从而会进一步增加资源需求和网络调用。客户端和后端之间的这种混乱调用可能会对应用程序的性能和规模产生负面影响。微服务架构使这个问题变得更加普遍,因为围绕许多小型服务构建的应用程序自然会有更多的跨服务调用。

在下图中,客户端向每个服务发送请求(1,2,3)。每个服务处理请求并将响应发送回应用程序(4,5,6)。通常具有高延迟的蜂窝网络上,以这种方式使用单独的请求是低效的并且可能导致连接中断或请求不完整。虽然每个请求可以并行完成,但应用程序必须为每个请求发送,等待和处理数据,所有这些都在不同的连接上,从而增加微服务网关与普通网关了失败的可能性。

使用网关来减少客户端和服务之间的干扰。网关接收客户端请求,将请求分派给各种后端系统,然后聚合结果并将它们发送回请求客户端。
这种模式可以有效减少应用程序对后端服务的调用请求数,而且在高延迟网络上的应用程序的性能有大的提升。

在下图中,应用程序向网关发送请求(1)。该请求包含一组附加请求。网关分解这些请求并通过将每个请求发送到相关服务来处理每个请求(2)。每个服务都返回对网关的响应(3)。网关聚合每个服务的响应并将响应发送到应用程序(4)。应用程序发出单个请求,并且只从网关接收一个响应。

1.网关不应该在后端服务中引入服务耦合
2.网关应该和后端服务位置很近,以尽可能减少延迟。
3.网关服务可能须要做ha。确保网关设计合理,以满足您的应用程序的可用性要求。
4.网关可能是性能瓶颈。确保网关具有足够的性能来处理负载,并且可以扩展以满足您的预期增长。
5.对网关执行负载测试,以确保不会导致服务的级联故障。
6.使用隔板,断路,重试和超时等技术实现弹性设计。
7.如果一个或多个服务调用花费的时间太长,则可以接受超时并返回部分数据集。考虑您的应用程序将如何处理此方案。
8.使用异步I / O来提升程序的吞吐量。
9.通过分布式跟踪对全链路进行监控。
10.监控请求指标和响应大小。
11.考虑将缓存数据作为故障转移策略来处理故障。
12.不要将聚合构建到网关中,而是考虑在网关后面放置聚合服务。请求聚合可能具有与网关中的其他服务不同的资源要求,并且可能影响网关的路由和卸载功能。

1.客户端需要与多个后端服务通信才能完成操作
2.客户端可以使用具有明显延迟的网络,例如蜂窝网络。

1.您希望客户端对单个服务的请求次数(比如获取10个学生的信息,你只有一个单个查询学生信息的接口)。在这种情况下,最好向服务添加批处理操作。
2.客户端或应用程序位于后端服务附近,延迟不是一个重要因素。

以下示例是教你如何使用Lua创建简单的网关聚合NGINX服务。

关于微服务网关与普通网关和微服务网关的功能有哪些的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。 微服务网关与普通网关的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于微服务网关的功能有哪些、微服务网关与普通网关的信息别忘了在本站进行查找喔。

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

上一篇:Java的垃圾强制回收实例分析
下一篇:Java的垃圾回收机制实例分析
相关文章

 发表评论

暂时没有评论,来抢沙发吧~