本篇文章给大家谈谈有哪些微服务网关,以及什么是微服务网关对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。
今天给各位分享有哪些微服务网关的知识,其中也会对什么是微服务网关进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!
本文目录一览:
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 交互图:
微服务 六:服务网关
服务除了内部相互之间调用和通信之外,最终要以某种方式暴露出去,才能让外界系统(例如客户的浏览器、移动设备等等)访问到,这就涉及服务的前端路由,对应的组件是服务网关(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)简化的微服务架构图
服务网关Zuul
在前面的学习中
有哪些微服务网关,
有哪些微服务网关我们使用Spring Cloud实现微服务的架构基本成型,大致是这样的:
我们使用Spring Cloud Netflix中的Eureka实现了服务注册中心以及服务注册与发现;而服务间通过Ribbon或Feign实现服务的消费以及负载均衡;为了使得服务集群更为健壮,使用Hystrix的熔断机制 来避免在微服务架构中个别服务出现异常时引起的故障蔓延。
在该架构中,我们的服务集群包括:内部服务Service A和Service B,他们都会注册与订阅服务至Eureka Server,而Open Servc时一个对外的服务,通过负载均衡公开至服务调用方。我们把焦点聚集在对外服务这块,这种实现方式是否合理,有没有更好的实现方式呢?
这种架构不足之处:
对于上面的问题,最好的解决方法是——服务网关。
为了解决上面的问题,我们需要将权限控制这样的东西从我们的服务单元中抽离出去,而最适合这些逻辑的地方就是处于对外访问最前端的地方,我们需要一个更加强大的负载均衡器——服务网关。
服务网关是微服务架构中不可或缺的的部分。通过服务网关统一向外系统提供REST API的过程中,除了具备服务路由、负载均衡之外,它还具备了权限控制等功能。Spring Cloud NetFlix中的Zuul就具备这样的功能。
Zuul是NetFlix开源的微服务网关,它可以和Eureka、Ribbon、Hystrix等组件配合使用。Zuul的核心是一些列的过滤器,这些过滤器可以完成以下功能。
Spring Cloud对Zuul进行了整合与增强。目前,Zuul使用的默认HTTP客户端是Apache HTTP Client,也可以使用使用其他的。
使用Zuul之后的架构如图所示:
从图中可以看出,客户端请求微服务时,先经过Zuul之后再请求,这样就可以将一些类似于校验的业务逻辑放到zuul中去完成,而微服务本身只需要关注自己的业务逻辑即可。
首先新建一个gateway模块,并且导入相关的依赖
然后再编写启动类增加@EnableZuulProxy注解。
接着编写application.yml文件,并添加路由规则
然后启动测试,发现可以通过zuul访问到商品微服务地址
在上面的配置中,我们通过路由规则的配置,访问到了商品微服务。但是如果商品微服务的地址发生变化,我们要修改配置问题。所以,我们应该通过走Eureka注册中心来获取地址。首先,我们需要添加Eureka依赖。
然后修改application.yml配置文件,将自己注册到注册中心。
随后,通过测试发现可以通过zuul访问商品微服务,一切正常。
过滤器是Zuul的重要组件。在我们的一般的单体应用中,也会使用过滤器过滤请求,或者完成相关的权限配置等,例如shiro框架就是用过滤器管理权限的。Zuul中的过滤器名为ZuulFilter:
ZuulFilter是一个抽象类,其实现类需要实现4个方法:
过滤器的执行流程如图所示:
需求:通过编写过滤器实现用户是否登录的检查
实现:通过判断请求中是否有token,如果有认为就是已经登录的,如果没有就认为时非法请求,响应401.
接下来,我们需要编写一个UserLoginZuulFilter,逻辑如下:
随后,我们打开浏览器进行测试,可以看到过滤器已经生效:
主流的微服务框架
目前比较火的主流微服务框架
1)Spring Cloud , 来自Spring,具有Spring 社区的强大支撑,还有Netflix强大的后盾与技术输出。Netflix作为一家成功实践微服务架构的互联网公司在几年前就把几乎整个微服务框架栈开源贡献给了社区,这些框架开源的整套服务架构套件是Spring Cloud的核心。
- Eureka:服务注册发现框架;
- Zuul:服务网关;
- Karyon:服务端框架;
- Ribbon:客户端框架;
- Hystrix:服务容错组件;
- Archaius:服务配置组件;
- Servo:Metrics组件;
- Blitz4j:日志组件;
2)Dobbo是一个分布式服务框架,是阿里开放的微服务化治理框架,致力于提高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案。其核心部分(官网)
- 远程通讯: 提供对多种基于长连接的NIO框架抽象封装,包括多种线程模型,序列化,以及“请求-响应”模式的信息交换方式;
- 集群容错: 提供基于接口方法的透明远程过程调用,包括多协议支持,以及软负载均衡,失败容错,地址路由,动态配置等集群支持;
- 自动发现: 基于注册中心目录服务,使服务消费方能动态的查找服务提供方,使地址透明,使服务提供方可以平滑增加或减少机器。
Dubbo 也是采用全 Spring 配置方式,透明化接入应用,对应用没有任何 API 侵入,只需用 Spring 加载 Dubbo的配置即可,Dubbo 基于 Spring 的 Schema 扩展进行加载。当然也支持官方不推荐的 API 调用方式。
3)lstio 作为用于微服务聚合层管理的新锐项目,是Google、IBM、Lyft(海外共享出行公司、Uber劲敌),首个共同联合开源的项目,提供了统一的连接,安全,管理和监控微服务的方案。
目前首个测试版是针对Kubernetes环境的,社区宣称在未来几个月内会为虚拟机和Cloud Foundry 等其他环境增加支持。lstio将 流量管理添加到微服务中,并为增值功能(如安全性、监控、路由、连接管理和策略)创造了基础。
- HTTP、gRPC 和 TCP 网络流量自动负载均衡;
- 提供了丰富的路由规则,实现细颗粒度的网络流量行为控制;
- 流量加密、服务件认证,以及强身份声明;
- 全范围(Fleet-wide)的策略执行;
- 深度遥测和报告。
开源社区情况:现如今企业在采用云计算首选开源,而选择一个开源框架,社区的活跃度将作为重要参考选项。
查看下在 Github 上的更新时间,截止 2017 年 8 月 31 日:
可见,项目在社区活跃度上,Istio Spring Cloud Dubbo,结合稳定性来看,对于使用 Java 系开发业务较多的企业,Spring Cloud 是相对更优的选择,对于更多企业来说,与语言几乎无绑定的 Istio 也是可以好好期待一下其在社区的发展。
同时,随着近几年微服务架构和 Docker 容器概念的火爆,也会让 Spring Cloud 在未来越来越“云”化的软件开发风格中立有一席之地
关于有哪些微服务网关和什么是微服务网关的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。
有哪些微服务网关的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于什么是微服务网关、有哪些微服务网关的信息别忘了在本站进行查找喔。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
暂时没有评论,来抢沙发吧~