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

限流方式

集中式（全局）限流

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

目前，主流的网关层有以软件为代表的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的过期时间调小一点，让它能够近实时的更新单节点的qps。这里还需要考虑一下k8s的压力，因为每次都要获取副本数，这里也是需要做缓存的

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

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