目录
后台服务网关
Spring Cloud Gateway
基于Nacos实现Spring Cloud Gateway实现动态路由
Spring Gateway 如何搭建网关服务以及实现动态路由?
微服务spring cloud gateway 路由参数和过滤策略配置(yaml和json格式)
从0到1学SpringCloud——11 gateway网关路由配置详解
从0到1学SpringCloud——12 gateway 动态配置网关路由规则
springcloud gateway网关获取post请求参数,网关路由,网关限流,熔断降级等实际操作
重试配置
springcloud gateway 自定义路由filter Retry重试配置
遇到问题
1.get请求含有特殊字符报400 bad request问题解决
spring-boot.version: 2.7.5
spring-cloud.version: 2021.0.5
yml配置:
#tomcat公共配置
server:
tomcat:
relaxed-query-chars: '[,],{,},|'
relaxed-path-chars: '[,],{,},|'
Apache ShenYu
Apache ShenYu(incubating) 发布 2.4.3,异步高性能跨语言响应式 API 网关
docker 部署 shenyu
docker pull apache/shenyu-admin
docker network create shenyu
docker run --name sheny-admin -d -p 9095:9095 --net shenyu apache/shenyu-admin
docker network create shenyu
docker pull apache/shenyu-bootstrap
docker run --name sheny-bootstrap -d -p 9195:9195 --net shenyu apache/shenyu-bootstrap
默认账户admin/123456
Higress
fizz-gateway-community
fizz-gateway-community: 微服务API聚合网关
企业案例
阿里技术专家:“双11”亿级流量背后的API网关、微服务架构实践!
前台流量网关
APISIX
百万级 QPS 业务新宠,Apache APISIX 打造网关实践新体验
API网关介绍
API网关(API Gateway)是一个服务器集群,对外的唯一入口。从面向对象设计的角度看,它与外观模式类似。API网关封装了系统内部架构,对外提供REST/HTTP的访问API。同时还具有其它非业务相关的职责,如身份验证、监控、负载均衡、缓存、流量控制等。
API管理
API网关核心功能是 API 管理。提供 API 的完整生命周期管理,包括创建、维护、发布、运行、下线等基础功能;提供测试,预发布,发布等多种环境;提供版本管理,版本回滚。
API配置包括 前端配置 和 后端配置 。前端配置指的是Http相关的配置,如HTTP 方法、URL路径,请求参数等。后端配置指的是微服务的相关配置,如服务名称、服务参数等。这样通过API配置,就完成了前端Http到后端微服务的转换。
全异步
由于API网关主要处理的是网络I/O,那么通过非阻塞I/O以及I/O多路复用,就可以达到使用少量线程承载海量并发处理,避免线程上下文切换,大大增加系统吞吐量,减少机器成本。
常用解决方案有 Tomcat/Jetty+NIO+servlet3.1 和 Netty+NIO,这里推荐Netty+NIO,能实现更高的吞吐量。Spring 5.0 推出的WebFlux反应式编程模型,特点是异步的、事件驱动的、非阻塞,内部就是基于Netty+NIO 或者 Servlet 3.1 Non-Blocking IO容器 实现的。
链式处理
链式处理即通过责任链模式,基于 Filter 链的方式提供了网关基本的功能,例如:路由、协议转换、缓存、限流、监控、日志。也可以根据实际的业务需要进行扩展,但注意不要做耗时操作。
Spring cloud gateway (基于 Spring WebFlux)的工作机制大体如下:
Gateway 接收客户端请求。
客户端请求与路由信息进行匹配,匹配成功的才能够被发往相应的下游服务。
请求经过 Filter 过滤器链,执行 pre 处理逻辑,如修改请求头信息等。
请求被转发至下游服务并返回响应。
响应经过 Filter 过滤器链,执行 post 处理逻辑。
向客户端响应应答。
请求限流
请求限流是在面对未知流量的情况下,防止系统被冲垮的最后一道有效的防线。可以针对集群、业务系统和具体API维度进行限流。
具体实现可以分为集群版和单机版,区别就是集群版是使用后端统一缓存如Redis存储数据,但有一定的性能损耗;单机版则在本机内存中进行存储(推荐)。
常用的限流算法:计数器、漏桶、令牌桶(推荐)
熔断降级
服务熔断
当下游的服务因为某种原因突然变得不可用或响应过慢,上游服务为了保证自己整体服务的可用性,不再继续调用目标服务,直接返回,快速释放资源。如果目标服务情况好转则恢复调用。
熔断是为了解决服务雪崩,特别是在微服务体系下,通常在框架层面进行处理。内部机制采用的是断路器模式,其内部状态转换图如下:
服务降级
当负荷超出系统整体负载承受能力时,为了保证核心服务的可用,通常可以对非核心服务进行降级,如果返回缓存内容或者直接返回。
服务降级的粒度可以是API维度、功能维度、甚至是系统维度,但是都需要事前进行服务级别的梳理和定义。
真实场景下,通常是在服务器负载超出阈值报警之后,管理员决定是扩容还是降级。
业务隔离
API网关统一了非业务层面的处理,但如果有业务处理的逻辑,不同业务之间就可能会相互影响。要进行业务系统的隔离,通常可以采用线程池隔离和集群隔离,但对于Java而言,线程是比较重的资源,推荐使用集群隔离。
网关功能
1.用户鉴权和登陆校验,支持接口级别配置。
2.黑白名单,分全局和应用,以及 IP 维度,参数级别。
3.流量控制,支持自动和手动,自动是对超大流量自动拦截,通过令牌桶算法实现。
4.智能熔断,在 Histrix 的基础上做了改进,支持自动升降级,我们是全部自动的,也支持手动配置立即熔断,就是发现服务异常比例达到阀值,就自动触发熔断。
5.灰度发布,我对新启动的机器的流量支持类似 TCP 的慢启动机制,给机器一个预热的时间窗口。
6.统一降级,我们对所有转发失败的请求都会找统一降级的逻辑,只要业务方配了降级规则,都会降级,我们对降级规则是支持到参数级别的,包含请求头里的值,是非常细粒度的,另外我们还会和 varnish 打通,支持 varnish 的优雅降级。
7.流量调度,支持业务根据筛选规则,对流量筛选到对应的机器,也支持只让筛选的流量访问这台机器,这在查问题/新功能发布验证时非常用,可以先通过小部分流量验证再大面积发布上线。
8.流量 copy,我们支持对线上的原始请求根据规则 copy 一份,写入到 MQ 或者其他的 upstream,来做线上跨机房验证和压力测试。
9.请求日志采样,我们对所有的失败的请求都会采样落盘,提供业务方排查问题支持,也支持业务方根据规则进行个性化采样,我们采样了整个生命周期的数据,包含请求和响应相关的所有数据。