【微服务】springboot 通用限流方案设计与实现

目录

一、背景

二、限流概述

2.1 dubbo 服务治理模式

2.1.1 dubbo框架级限流

2.1.2 线程池设置

2.1.3 集成第三方组件

2.2 springcloud 服务治理模式

2.2.1 hystrix

2.2.2 sentinel

2.3 网关层限流

三、常用限流策略

3.1 限流常用的算法

3.1.1 令牌桶算法

3.1.2 漏桶算法

3.1.3 滑动时间窗口

四、通用限流实现方案

4.1 基于guava限流实现

4.1.1 引入guava依赖

4.1.2 自定义限流注解

4.1.3 限流AOP类

4.1.4 测试接口

4.2 基于sentinel限流实现

4.2.1 引入sentinel核心依赖包

4.2.2 自定义限流注解

4.2.3 自定义AOP类实现限流

4.2.4 自定义测试接口

4.3 基于redis+lua限流实现

4.3.1 引入redis依赖

4.3.2 自定义注解

4.3.3 自定义redis配置类

4.3.4 自定义限流AOP类

4.3.5 自定义lua脚本

4.3.6 添加测试接口

五、自定义starter限流实现

5.1 前置准备

5.2 代码整合完成步骤

5.2.1 导入基础的依赖

5.2.2 自定义注解

5.2.3 限流实现AOP类

5.2.4 配置自动装配AOP实现

5.2.5 将工程打成jar进行安装

5.2.6 在其他的工程中引入上述SDK

5.2.7 编写测试接口

5.2.8 功能测试

六、写在文末

---

一、背景

限流对于一个微服务架构系统来说具有非常重要的意义，否则其中的某个微服务将成为整个系统隐藏的雪崩因素，为什么这么说？举例来讲，某个SAAS平台有100多个微服务应用，但是作为底层的某个或某几个应用来说，将会被所有上层应用频繁调用，业务高峰期时，如果底层应用不做限流处理，该应用必将面临着巨大的压力，尤其是那些个别被高频调用的接口来说，最直接的表现就是导致后续新进来的请求阻塞、排队、响应超时...最后直到该服务所在JVM资源被耗尽。

二、限流概述

在大多数的微服务架构在设计之初，比如在技术选型阶段，架构师会从一个全局的视角去规划技术栈的组合，比如结合当前产品的现状考虑是使用dubbo？还是springcloud？作为微服务治理的底层框架。甚至为了满足快速的上线、迭代和交付，直接以springboot为基座进行开发，后续再引入新的技术栈等...

所以在谈论某个业务场景具体的技术解决方案时不可一概而论，而是需要结合产品和业务的现状综合评估，以限流来说，在下面的不同的技术架构下具体在选择的时候可能也不一样。

2.1 dubbo 服务治理模式