Service Mesh 速率限制:本地限流与全局限流的架构组合

发布时间:2026/7/25 11:48:24
Service Mesh 速率限制:本地限流与全局限流的架构组合 Service Mesh 速率限制本地限流与全局限流的架构组合一、限流配在网关层但服务 B 被恶意重试搞垮了——因为网关限流看不见服务侧的实际负载速率限制Rate Limiting有两个典型的架构位置网关层入口限流和服务侧本地限流。网关层限流保护整体系统不被外部过载压垮基于请求的全局 QPS。服务侧限流保护单个服务实例不被内部调用方的异常行为如重试风暴压垮。二者缺一不可。如果只在网关做限流服务 A 调用服务 B 时如果出现无限重试Bug 导致网关看不到内部调用服务 B 被内部流量压垮。如果只在服务侧做限流外部突发流量到达网关后分散到服务实例——单实例的限流会触发大量 429 拒绝浪费了其他健康实例的容量。Service Mesh 在这两者的结合上有个独特优势Mesh 的 sidecarEnvoy同时承担了入口流量和出口流量的代理。可以在 sidecar 层面同时实现本地限流单 sidecar 级别和全局限流基于全局状态。二、底层机制与原理剖析两层限流的职责分工全局限流网关层 Envoy 集成保护的是集群的整体容量。QPS 1000 是集群最大承载量——网关把超过 1000 的请求拒之门外基于全局状态需要知道当前全集群已经处理了多少请求。需要外部状态存储Redis来记录全局计数特征Coarse-grained粗粒度基于外部 IP / API Key / 整体 QPS。响应用 429 Retry-After本地限流服务侧保护的是单个服务实例不被打垮。实例最大处理 500 QPS取决于 CPU/内存/数据库连接池基于本地状态不需要外部存储。Envoy 的local_rate_limitfilter 直接用令牌桶算法特征Fine-grained细粒度基于服务实例的实际容量。响应也用 429三、生产级代码实现# envoy-local-rate-limit.yaml # Envoy 本地限流配置 (EnvoyFilter) apiVersion: networking.istio.io/v1alpha3 kind: EnvoyFilter metadata: name: local-rate-limit namespace: production spec: workloadSelector: labels: app: agent-api configPatches: - applyTo: HTTP_FILTER match: context: SIDECAR_INBOUND listener: filterChain: filter: name: envoy.filters.network.http_connection_manager patch: operation: INSERT_BEFORE value: name: envoy.filters.http.local_ratelimit typed_config: type: type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit stat_prefix: http_local_rate_limiter # 令牌桶配置 token_bucket: max_tokens: 500 # 突发容量允许 500 个 token tokens_per_fill: 500 # 每次填充 500 个 token fill_interval: 1s # 每 1 秒填充一次 → 500 QPS # 返回 429 时的 header filter_enabled: runtime_key: local_rate_limit_enabled default_value: numerator: 100 denominator: HUNDRED filter_enforced: runtime_key: local_rate_limit_enforced default_value: numerator: 100 denominator: HUNDRED # 限流生效的请求条件仅对 /api/ 路径限流 request_headers_to_add_when_not_enforced: - header: key: x-local-rate-limit value: false# envoy-global-rate-limit.yaml # Envoy 全局限流配置集成外部 Rate Limit Service apiVersion: networking.istio.io/v1alpha3 kind: EnvoyFilter metadata: name: global-rate-limit namespace: production spec: workloadSelector: labels: app: agent-api configPatches: - applyTo: HTTP_FILTER match: context: SIDECAR_INBOUND listener: filterChain: filter: name: envoy.filters.network.http_connection_manager patch: operation: INSERT_BEFORE value: name: envoy.filters.http.ratelimit typed_config: type: type.googleapis.com/envoy.extensions.filters.http.ratelimit.v3.RateLimit domain: agent-api failure_mode_deny: false # 限流服务不可用时放行非安全场景 rate_limit_service: transport_api_version: V3 grpc_service: envoy_grpc: cluster_name: rate-limit-service # 基于 API Key 做全局限流 descriptors: - key: api_key value: # 动态填充 # 第二个 patch配置 rate-limit-service 的 cluster - applyTo: CLUSTER match: context: SIDECAR_OUTBOUND patch: operation: ADD value: name: rate-limit-service type: STRICT_DNS connect_timeout: 0.5s lb_policy: ROUND_ROBIN load_assignment: cluster_name: rate-limit-service endpoints: - lb_endpoints: - endpoint: address: socket_address: address: rate-limit-service.istio-system.svc.cluster.local port_value: 8081# rate-limit-service.py 全局限流服务——基于 Redis 的分布式限流 Envoy 通过 gRPC 调用此服务进行全局速率检查 import grpc import redis import time import logging from concurrent import futures from typing import Dict # 注需要安装 envoy_ratelimit proto 生成的 Python 代码 # pip install grpcio grpcio-tools logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) class GlobalRateLimiter: 基于 Redis 的全局限流实现 使用滑动窗口算法代替简单的固定窗口 - 固定窗口有边界突发问题窗口最后 1 秒 下一个窗口开始 1 秒 2 倍 QPS - 滑动窗口通过存储每次请求的时间戳来精确控制 def __init__(self, redis_host: str localhost, redis_port: int 6379): self.redis redis.Redis( hostredis_host, portredis_port, decode_responsesTrue, socket_connect_timeout2, socket_timeout2, ) # 限流规则从配置文件或管理 API 动态加载 self.rules: Dict[str, Dict] { # 按 API Key 限流 api-key: { free: {qps: 10, burst: 20}, pro: {qps: 100, burst: 200}, enterprise: {qps: 1000, burst: 2000}, }, # 按服务限流 service: { agent-api: {qps: 2000, burst: 3000}, agent-worker: {qps: 500, burst: 800}, }, } def check_rate_limit(self, domain: str, descriptors: list) - bool: 检查速率限制 参数: domain: 限流域如 agent-api descriptors: 限流描述符列表 [{key: api_key, value: sk-xxx}, ...] 返回: True: 允许通过, False: 触发限流 for descriptor in descriptors: key descriptor.get(key) value descriptor.get(value) if not key or not value: continue # 查找对应的限流规则 rule self._find_rule(key, value) if not rule: continue # 检查 Redis 中的滑动窗口计数 rl_key fratelimit:{domain}:{key}:{value} limit rule[qps] burst rule.get(burst, limit * 2) allowed self._check_sliding_window(rl_key, limit, burst) if not allowed: logger.debug(Rate limit hit: %s/%s QPS%d, key, value, limit) return False return True def _find_rule(self, descriptor_key: str, descriptor_value: str) - dict: 查找限流规则 if descriptor_key api_key: # 根据 API Key 的 tier 查找 # 生产环境从数据库查询 API Key 对应的 tier tier_map self.rules.get(api-key, {}) # 简化默认 free tier return tier_map.get(free, {qps: 10, burst: 20}) if descriptor_key service: service_rules self.rules.get(service, {}) return service_rules.get(descriptor_value, None) return None def _check_sliding_window(self, key: str, limit: int, burst: int) - bool: 滑动窗口限流检查 算法 1. 使用 Redis Sorted Set成员 请求时间戳微秒score 时间戳 2. 每次检查时删除窗口外的旧数据 3. 统计窗口内的请求数 4. 如果超过限制 → 拒绝否则 → 添加当前请求并允许 now_us int(time.time() * 1_000_000) # 微秒精度 window_us 1_000_000 # 1 秒窗口 pipe self.redis.pipeline() # 1. 删除窗口外的旧数据 pipe.zremrangebyscore(key, 0, now_us - window_us) # 2. 统计窗口内的请求数 pipe.zcard(key) try: _, current_count pipe.execute() except redis.RedisError as e: logger.error(Redis error in rate limiter: %s, e) # Redis 不可用时——放行取决于 failure_mode_deny 配置 return True current_count int(current_count) if current_count limit burst: return False # 触发限流 # 3. 记录本次请求 try: self.redis.zadd(key, {str(now_us): now_us}) self.redis.expire(key, 2) # 2 秒后自动过期 except redis.RedisError: pass # 记录失败不阻塞请求 return True # --------------------------------------------------------------------------- # gRPC 服务 # --------------------------------------------------------------------------- class RateLimitServicer: Envoy Rate Limit Service gRPC 接口实现 def __init__(self, limiter: GlobalRateLimiter): self.limiter limiter def ShouldRateLimit(self, request, context): 实现 Envoy RateLimitService.Check 接口 domain request.domain descriptors [] for desc in request.descriptors: for entry in desc.entries: descriptors.append({ key: entry.key, value: entry.value, }) # 全局限流检查 overall_code self.limiter.check_rate_limit(domain, descriptors) # 构建 gRPC 响应简化——实际需要导入 envoy proto 生成的代码 # response RateLimitResponse() # response.overall_code OK if overall_code else OVER_LIMIT # return response logger.debug(Rate limit check: domain%s allowed%s, domain, overall_code) return None # 实际返回 gRPC 响应对象 def start_server(limiter: GlobalRateLimiter, port: int 8081): 启动限流 gRPC 服务 server grpc.server(futures.ThreadPoolExecutor(max_workers10)) # rate_limit_pb2_grpc.add_RateLimitServiceServicer_to_server( # RateLimitServicer(limiter), server # ) server.add_insecure_port(f[::]:{port}) server.start() logger.info(Rate limit service started on port %d, port) return server if __name__ __main__: limiter GlobalRateLimiter(redis_hostredis.istio-system.svc) server start_server(limiter) try: import time while True: time.sleep(3600) except KeyboardInterrupt: server.stop(0)四、边界分析与架构权衡全局限流的 Redis 依赖如果 Redis 不可用全局限流失效。Envoy 的failure_mode_deny控制这种行为true安全优先——Redis 不可用时拒绝所有请求或 false可用优先——Redis 不可用时放行对于 API 计费场景推荐 deny防止免费用户绕过计费对于内部服务调用推荐 allow可用性优先本地限流的公平性多副本的本地限流在负载均衡不均时可能产生不公平——副本 A 被打到 500 QPS触发限流副本 B 只被打到 100 QPS大量容量浪费如果负载均衡算法是 Round Robin 或 Least Connection通常不会出现严重不均两层限流的协调本地限流的值应该是全局限额 / 副本数。如果全局限额 2000 QPS、3 副本每个副本本地限流 700 QPS略高于 2000/3666留 buffer优先触发本地限流延迟最低——不需要调 Redis全局限流作为兜底保护集群整体五、总结Service Mesh 的两层限流全局网关 Envoy Redis保护集群整体容量本地Envoy local_rate_limit filter保护单个实例。全局限流用滑动窗口算法基于 Redis Sorted Set避免固定窗口的边界突发问题。本地限流的值 全局限额 / 副本数 buffer。两层同时生效——本地优先触发低延迟全局作为兜底。Redis 不可用时根据场景选择 deny安全优先或 allow可用优先。