微服务架构分布式限流策略

Posted 2023-04-02 curd_boy

文章目录

• 限流方式
• • 集中式（全局）限流
  • 进程内限流
  • • 单机限流
    • 依赖配置中心
    • go-zero基于redis设计的两款分布式限流器
• kubernetes怎么实现分布式限流
• • istio
  • ingress rate limiting
  • k8s获取pod副本数做限流

限流方式

集中式（全局）限流

网关层限流服务网关，作为整个分布式链路中的第一道关卡，承接了所有用户来访请求。我们在网关层进行限流，就可以达到了整体限流的目的了。

目前，主流的网关层有以软件为代表的nginx，还有Spring Cloud中的Gateway和Zuul这类网关层组件，也有以硬件为代表的F5。

进程内限流

单机限流

漏斗桶，令牌桶等算法限流

依赖配置中心

如果有注册中心（consul、nacos、etcd），可以实时获取注册中心节点数
如果服务的节点动态调整，单个服务的qps也能动态调整。

go-zero基于redis设计的两款分布式限流器

https://github.com/zeromicro/go-zero/tree/master/core/limit

优点：设计、实现简单，拿来即用
缺点：qps较高，redis内存消耗严重

其中，ping redis大概6-7ms左右，对应的，每次请求需要访问redis，时延都有大概6-7ms，性能下降明显

对于极致追求高性能的服务不需要考虑熔断、降级来说，是需要尽量减少网络之间的IO

kubernetes怎么实现分布式限流

istio

https://cloud.tencent.com/developer/article/1468273

ingress rate limiting

https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#rate-limiting

k8s获取pod副本数做限流

在实际的服务中，数据上报服务一般无法确定客户端的上报时间、上报量，特别是对于这种要求高性能，服务一般都会用到HPA来实现动态扩缩容，所以，需要去间隔一段时间去获取服务的副本数。

import (
	"context"
	"github.com/why19970628/k8s-cheatsheet/models"
	"github.com/why19970628/k8s-cheatsheet/utils"
	corev1 "k8s.io/api/core/v1"
	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
	"k8s.io/client-go/kubernetes"
	"log"
	"strings"
)

func CountDeploymentSize(c kubernetes.Interface, namespace string, deploymentName string) *int32 
	deployment, err := c.AppsV1().Deployments(namespace).Get(context.TODO(), deploymentName, metav1.GetOptions)
	utils.HandlerCheck(err)
	return deployment.Spec.Replicas

• 对于保证qps限频准确的时候，应该怎么解决呢？
  在k8s中，服务是动态扩缩容的，相应的，每个节点应该都要有所变化，如果对外宣称限频100qps，而且后续业务方真的要求百分百准确，只能把LoadingCache<String, RateLimiter>的过期时间调小一点，让它能够近实时的更新单节点的qps。这里还需要考虑一下k8s的压力，因为每次都要获取副本数，这里也是需要做缓存的

• 服务从1个节点动态扩为4个节点，这个时候新节点识别为4，但其实有些并没有启动完，会不会造成某个节点承受了太大的压力
  理论上是存在这个可能的，这个时候需要考虑一下初始的副本数的，扩缩容不能一蹴而就，一下子从1变为4变为几十个这种。一般的话，生产环境肯定是不能只有一个节点，并且要考虑扩缩容的话，至于要有多个副本预备的

• 如果有多个副本，怎么保证请求是均匀的
  这个是依赖于k8s的service负载均衡策略的，流量是能够均匀的落到节点上的。整个限流都是基于k8s的，如果k8s出现问题，那就是整个集群所有服务都有可能出现问题了。

微服务架构 Sentinel 的服务限流及熔断

前言

参考资料：
《Spring Microservices in Action》
《Spring Cloud Alibaba 微服务原理与实战》
《B站 尚硅谷 SpringCloud 框架开发教程 周阳》
《Sentinel GitHub 官网》
《Sentinel 官网》

Sentinel 是面向分布式服务架构的轻量级流量控制组件，主要以流量为切入点，从限流、流量整形、服务降级、系统负载保护等多个维度来帮助我们保障微服务的稳定性；

---

1. Sentinel 基础知识

1.1 Sentinel 的特性

• 丰富的应用场景：几乎涵盖所有的应用场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制等；
• 实时监控：开发者可以在控制台中看到接入应用的单台机器秒级数据，甚至500台以下规模的集群汇总运行情况；
• 开源生态支持：Sentine提供开箱即用的与其他开源框架/库的整合，例如与Spring Cloud、Dubbo、gRPC的整合；
• SPI 扩展点支持：提供了 SPI