限流 10 万 QPS、跨域、过滤器、令牌桶算法 - 网关 Gateway 内容都在这儿
一、微服务网关 Spring Cloud Gateway
1.1 导引
文中内容包含:微服务网关限流 10 万 QPS、跨域、过滤器、令牌桶算法。
在构建微服务系统中,必不可少的技术就是网关了,从早期的 Zuul,到现在的 Spring Cloud Gateway,网关我们用的不可少。
今天我就将沉淀下来的所有与网关相关的知识,用一篇文章总结清楚,希望对爱学习的小伙伴们有所帮助。
本篇文章主要介绍网关跨域配置,网关过滤器编写,网关的令牌桶算法限流【每秒 10 万 QPS】
首先我们来看什么是网关
1.2 什么是微服务网关 Gateway?
This project provides a library for building an API Gateway on top of Spring WebFlux.
gateway 官网:https://spring.io/projects/spring-cloud-gateway
实现微服务网关的技术有很多,
nginx Nginx (engine x) 是一个高性能的HTTP和反向代理web 服务器,同时也提供了 IMAP/POP3/SMTP 服务
zuul ,Zuul 是 Netflix 出品的一个基于 JVM 路由和服务端的负载均衡器。
spring-cloud-gateway, 是 spring 出品的 基于 spring 的网关项目,集成断路器,路径重写,性能比 Zuul 好。
我们使用 gateway 这个网关技术,无缝衔接到基于 spring cloud 的微服务开发中来。
1.3 微服务为什么要使用网关呢?
不同的微服务一般会有不同的网络地址,而外部客户端可能需要调用多个服务的接口才能完成一个业务需求,如果让客户端直接与各个微服务通信,会有以下的问题:
客户端会多次请求不同的微服务,增加了客户端的复杂性
存在跨域请求,在一定场景下处理相对复杂
认证复杂,每个服务都需要独立认证
难以重构,随着项目的迭代,可能需要重新划分微服务。例如,可能将多个服务合并成一个或者将一个服务拆分成多个。如果客户端直接与微服务通信,那么重构将会很难实施
某些微服务可能使用了防火墙 / 浏览器不友好的协议,直接访问会有一定的困难
以上这些问题可以借助网关解决。
网关是介于客户端和服务器端之间的中间层,所有的外部请求都会先经过 网关这一层。也就是说,API 的实现方面更多的考虑业务逻辑,而安全、性能、监控可以交由 网关来做,这样既提高业务灵活性又不缺安全性,典型的架构图如图所示:
1.4 微服务网关优点
安全 ,只有网关系统对外进行暴露,微服务可以隐藏在内网,通过防火墙保护。
易于监控。可以在网关收集监控数据并将其推送到外部系统进行分析。
易于认证。可以在网关上进行认证,然后再将请求转发到后端的微服务,而无须在每个微服务中进行认证。
减少了客户端与各个微服务之间的交互次数
易于统一授权。
1.5 总结
微服务网关就是一个系统,通过暴露该微服务网关系统,方便我们进行相关的鉴权,安全控制,日志统一处理,易于监控的相关功能。
二、微服务网关搭建及配置
2.1 微服务网关微服务搭建
由于我们开发的系统 有包括前台系统和后台系统,后台的系统给管理员使用。那么也需要调用各种微服务,所以我们针对管理后台搭建一个网关微服务。分析如下:
搭建步骤:
(1)依赖坐标 pom.xml:
(2)启动引导类:GatewayApplication
(3)在 resources 下创建 application.yml
参考官方手册:
2.2 微服务网关跨域
在启动类 GatewayApplication 中,加入跨域配置代码如下
三、微服务网关过滤器
我们可以通过网关过滤器,实现一些逻辑的处理,比如 ip 黑白名单拦截、特定地址的拦截等。下面的代码中做了两个过滤器,并且设定的先后顺序。
(1)在网关微服务中创建 IpFilter,无需配置其他,注册到 Spring 容器即可生效
(2)在网关微服务中创建 UrlFilter,无需配置其他,注册到 Spring 容器即可生效
四、网关限流每秒 10 万请求
我们之前说过,网关可以做很多的事情,比如,限流,当我们的系统 被频繁的请求的时候,就有可能 将系统压垮,所以 为了解决这个问题,需要在每一个微服务中做限流操作,但是如果有了网关,那么就可以在网关系统做限流,因为所有的请求都需要先通过网关系统才能路由到微服务中。
4.1 限流实现思路分析
看图就完了,非常简单!
4.2 令牌桶算法 介绍
令牌桶算法是比较常见的限流算法之一,大概描述如下:
1)所有的请求在处理之前都需要拿到一个可用的令牌才会被处理;2)根据限流大小,设置按照一定的速率往桶里添加令牌;3)桶设置最大的放置令牌限制,当桶满时、新添加的令牌就被丢弃或者拒绝;4)请求达到后首先要获取令牌桶中的令牌,拿着令牌才可以进行其他的业务逻辑,处理完业务逻辑之后,将令牌直接删除;5)令牌桶有最低限额,当桶中的令牌达到最低限额的时候,请求处理完之后将不会删除令牌,以此保证足够的限流
如下图:
这个算法的实现,有很多技术,Guava(读音: 瓜哇)是其中之一,redis 客户端也有其实现。
4.3 网关限流代码实现
需求:每个 ip 地址 1 秒内只能发送 10 万请求,多出来的请求返回 429 错误。
代码实现:
(1)spring cloud gateway 默认使用 redis 的 RateLimter 限流算法来实现。所以我们要使用首先需要引入 redis 的依赖
(2)定义 KeyResolver
在 GatewayApplicatioin 引导类中添加如下代码,KeyResolver 用于计算某一个类型的限流的 KEY 也就是说,可以通过 KeyResolver 来指定限流的 Key。
(3)修改 application.yml 中配置项,指定限制流量的配置以及 REDIS 的配置,修改后最终配置如下:
解释:
burstCapacity:令牌桶总容量。
replenishRate:令牌桶每秒填充平均速率。
key-resolver:用于限流的键的解析器的 Bean 对象的名字。它使用 SpEL 表达式根据 #{@beanName}从 Spring 容器中获取 Bean 对象。
通过在replenishRate
和中设置相同的值来实现稳定的速率burstCapacity
。设置burstCapacity
高于时,可以允许临时突发replenishRate
。在这种情况下,需要在突发之间允许速率限制器一段时间(根据replenishRate
),因为 2 次连续突发将导致请求被丢弃(HTTP 429 - Too Many Requests
)
key-resolver: "#{@userKeyResolver}" 用于通过 SPEL 表达式来指定使用哪一个 KeyResolver.
如上配置:
表示 一秒内,允许 一个请求通过,令牌桶的填充速率也是一秒钟添加一个令牌。
最大突发状况 也只允许 一秒内有一次请求,可以根据业务来调整 。
(4)测试时需要注意服务启动顺序,这里需要依赖于 Redis,所以首先要启动 redis
启动 redis
启动注册中心
启动商品微服务
启动 gateway 网关
打开浏览器 http://localhost:9999/open
快速刷新,当 1 秒内发送超过 10 万次请求,就会返回 429 错误。
那么问题来了:怎么发送 10 万次请求呢? 知道的同学,请在留言区评论。不知道下次我写篇压测来个百万 QPS!
原文链接:https://juejin.im/post/6895201419805392909
欢迎大家扫码来关注公众号博主,此公众号会持续更新技术干货、不定期分享 Java 进阶面试宝典、Java 核心知识、架构书籍电子版
版权声明: 本文为 InfoQ 作者【周老师】的原创文章。
原文链接:【http://xie.infoq.cn/article/169c7a9237b9a3154b74058bb】。文章转载请联系作者。
评论