您好,登录后才能下订单哦!
这篇文章主要介绍spring cloud中API网关的示例分析,文中介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们一定要看完!
客户端与各个业务子系统的通信必须通过一个统一的外观对象进行,外观模式提供一个高层次的接口,使得子系统更易于使用:
简单说一下外观模式,网关和这个模式很像,但是比外观模式复杂,模式,结构,原则这些都是通用的,在各种架构或组件中使用。
微服务网关从感觉上,很像是:拦截器+路由+过滤器,拦截请求,系列基础处理,路由转发到指定服务。
服务网关在整个架构体系上也是一个服务器,作为请求的唯一入口,与外观模式十分类似,在网关层处理所有的非业务功能,为客户端提供定制的API,在网关层通常会执行如下操作:如权限校验、监控、负载均衡、缓存、日志、限流、等等。
这里对比常用的请求服务管理模式,和网关模式,如图:
常规模式
在没有网关的情况下,微服务架构会在业务层服务上提供一个API服务,用来接收参数,例如Client-API,通常会根据系统模块划分多个API,例如,运营系统,用户系统等。
请求统一进入Client-API服务 ;
Client-API经过鉴权,限流,路由等操作;
如果请求通过,会转发到相应业务服务上;
如果请求被拦截,会直接返回给客户端;
Client-API集成所有业务服务的开放接口;
该模式下的缺点非常明显,每个Client-API都需要实现一套非业务服务,代码冗余,当系统膨胀之后,维护成本极高,适用于轻量级系统架构。
网关模式
在业务服务层上,添加一层网关控制,在服务网关中可以完成一系列的横切非业务功能:
客户端请求在网关层做统一拦截;
网关上执行:路由/鉴权/限流/降级等操作;
网关判断是转发请求还是直接响应客户端;
网关服务层要执行很多非业务流程,作为系统的服务端唯一入口,承受所有服务的路由转发,安全,限流,缓存,日志,监控,熔断降级等功能,网关服务不仅要做到高可用,还要避免出现性能瓶颈。
在大型复杂的系统中,通常会对网关做分层管理,把一类业务规划到一个网关下,避免网关过于臃肿,方便维护和管理:
总网关:通用常用来做路由转发功能;
模块网关:分类的业务服务聚合网关,对这类服务的做非业务性操作,最后请求转发到具体服务上,在数据类平台上,通常对数据通道(流入流出)做一层独立的服务网关;对数据分析类服务做一层独立网关;基本是根据服务的使用情况来划分,这样避免单层服务网关过于复杂的情况。
服务发现
网关应该有服务发现功能,通过统一注册中心,获取服务列表,这样才能执行统一代理服务和路由转发功能。
路由请求
植入网关层服务之后,客户端不知道自己请求的是哪个具体的服务,只需要把请求转发给网关,网关放行之后会把请求路由到指定业务服务上。
负载均衡
网关连接的服务实例可能是集群模式存在,所以网关还可以对各个服务实例上执行负载均衡策略,常见的策略就是服务轮询或者按权重路由。
定制开发例如:权限校验,日志集成,接口限流,等相关功能,需要和数据库交互,可以做成独立服务,在服务中实现具体的处理逻辑,网关层直接调用即可。
Zuul网关主要提供动态路由,监控,弹性,安全管控等功能。在分布式的微服务系统中,系统被拆为了多个微服务模块,通过zuul网关对用户的请求进行路由,转发到具体的后微服务模块中,Netflix开源的一个基于JVM路由和服务端的负载均衡器。
Tyk是一个开源的、轻量级的、快速可伸缩的API网关,支持配额和速度限制,支持认证和数据分析,支持多用户多组织。基于go语言编写,在Java架构系统中使用很少。
Kong是一款基于Nginx+Lua编写的高可用,可扩展的开源网关项目,由Mashape公司开放。核心是实现数据库抽象,路由和插件管理,插件可以存在于单独的代码库中,并且可以在几行代码中注入到请求生命周期的任何位置。提供易于使用的RESTfulAPI来操作和配置API管理,并且可以水平扩展多个Kong服务器,通过前置的负载均衡配置把请求均匀地分发到各个Server,来应对高并发的网络请求。
以上是“spring cloud中API网关的示例分析”这篇文章的所有内容,感谢各位的阅读!希望分享的内容对大家有帮助,更多相关知识,欢迎关注亿速云行业资讯频道!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。