网关:就是服务的统一入口;比如说一个城池, 城门相当于网关;
那么我们为什么使用网关?:在微服务架构下单体应用被切割成多个微服务,如果讲所有的微服务直接对外暴露,势必会出现安全方面的各种问题,另外内外耦合严重。
服务网关分为 流量网关 、 业务网关。
流量网关: 顾名思义就是可控制流程进入集群的网关,有很多工作需要在这里做,对于一个服务集群,势必会有很多非法请求、无效请求,这个时候就可以在流量网关这里讲这些请求拒之门外,降低集群的请求压力。流量网关是定义全局性的跟具体的后台业务无关的策略网关。流量网关通常只专注于全局的api 管理策略,比如全局流量监控、日志记录、全局限流、黑名单控制、接入请求到业务系统的负载均衡等。
业务网关: 当一个单体应用被拆分成多个为微服务应用后,也会出现很多问题,比如说 权限控制、日志输出、数据加密、熔断限流等这些功能大部分服务都需要这些功能都是重复的,会出现大量冗余代码,增加维护成本,无法集中管理,就出现了业务网关来解决这些问题。
业务网关作为微服务体系中的核心基础功能一般需要具备接口管理、协议适配、熔断降级、安全防护等功能。
流量网关: OpenResty、Kong
业务网关: Zuul/Zuul2、Spring Cloud Gateway
OpenResty: OpenResty基于 Nginx 与 Lua 的高性能 Web 平台,其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。
也就是说 Nginx 不再是一个简单的静态网页服务器,也不再是一个简单的反向代理了。第二代的 openresty 致力于通过一系列 nginx 模块,把nginx扩展为全功能的 web 应用服务器。
Kong: Kong基于OpenResty开发,也是流量层网关, 是一个云原生、快速、可扩展、分布式的Api 网关。继承了OpenResty的高性能、易扩展性等特点。Kong通过简单的增加机器节点,可以很容易的水平扩展。同时功能插件化,可通过插件来扩展其能力。而且在任何基础架构上都可以运行。具有以下特性:
Zuul(同步阻塞架构):Zuul是Spring Cloud全家桶中的微服务API网关。
所有从设备或网站来的请求都会经过Zuul到达后端的Netflix应用程序。作为一个边界性质的应用程序,Zuul提供了动态路由、监控、弹性负载和安全功能。Zuul底层利用各种filter实现如下功能:
Zuul2(异步非阻塞架构):Zuul2的设计相对比较复杂,代码也不太容易读懂,它采用了Netty实现异步非阻塞编程模型
Zuul原本采用同步阻塞架构,转型后叫作Zuul2,采用异步非阻塞架构。
Netflix给出了一个比较模糊的数据,大致Zuul2的性能比Zuul1好20%左右
Spring Cloud Gateway(异步非阻塞架构):Spring Cloud GateWay天⽣就是异步⾮阻塞的,基于Reactor模型;
网关对比
网关 | 限流 | 鉴权 | 监控 | 易用性 | 维护性 | 成熟性 |
---|---|---|---|---|---|---|
Zuul/Zuul2 | 可以通过配置文件配置集群限流和单服务器限流也可以通过filter实现限流扩展 | filter中实现 | filter中实现 | 参考资料较少 | 可维护性较差 | 资料少 |
Spring Cloud Gateway | 可以通过IP、用户、集群限流、提供的相应的接口进行扩展 | 普通鉴权、auth2.0 | Gate way Metrics Filter | 简单易用 | spring系列可扩展,已配置 可维护性好 | spring社区成熟但是gateway资源较少 |
OpenResty | 需要lua开发 | 需要lua开发 | 需要开发 | 简单易用,但需要进行lua开发的很多 | 可维护性较差,将来需要维护大量的lua脚本 | 很成熟,资料很多 |
Kong | 根据 秒、分、时、天、月、年,用户进行限流,可在源码的基础上进行开发 | 普通鉴权,keyAuth鉴权,HmacAuth2.0 | 上报的 datalog,记录请求数量,数据量 ,应答数据量,接受发送时间,状态码数量,kong内运行时间 | 简单易用 | 可维护性较差,将来需要维护大量的lua脚本 | 相对成熟 |