Harness层接口限流：防止恶意调用

一、 标题Harness 层接口限流实战从恶意调用防护到 DevOps 平台稳定性的铜墙铁壁二、 摘要/引言2.1 开门见山Hook假设你是一家拥有 500 开发者、日均 1000 CI/CD 流水线运行、每月发布 200 新特性的中型 SaaS 公司 DevOps 负责人。周一早上 9 点整你刚打开 Harness SaaS 控制台想检查昨天的 Feature Flag 灰度发布突然发现所有项目的流水线都卡壳在“初始化环境资源”阶段Feature Flag 触发的灰度请求 503 错误率飙升到 80%监控面板里 Harness API 的请求 QPS 居然冲到了平时的 150 倍运维同事排查了 20 分钟才找到原因上周离职的一个前端实习生忘了删除自己在本地开发环境里写的无限循环脚本——脚本每 10ms 就调用一次 Harness 的“获取所有 Feature Flag 实例状态”的通用公共 API。更可怕的是这个实习生用的是公司给离职人员预留的临时 API Key权限没完全回收虽然最后通过紧急禁用那个 API Key 恢复了服务但这 30 分钟的故障直接导致了公司核心 B2B 产品的 2 个客户投诉灰度发布延迟了 2 天甚至影响了运维团队本周的 OKR 进度。如果你在 Harness 平台不管是 SaaS 版本还是自托管的 Self-Managed Enterprise/Self-Managed Community Edition的对外/跨模块接口层也就是我们常说的Harness Core API 或 Harness Gateway 层提前配置好了合理的接口限流策略**这场完全可以避免的故障还会发生吗**答案显然是不会2.2 问题陈述Problem Statement在现代 DevOps 全链路平台如 Harness、GitLab CI/CD、Jenkins X的架构中Harness 层接口我们将其统一定义为“连接平台外部开发者/CI/CD 客户端与内部核心微服务集群的第一道或核心层网关服务”是整个系统的“咽喉要道”——所有的 CI/CD 触发、Feature Flag 查询/更新、Secret 管理、环境资源调度请求都必须经过这一层的认证、鉴权、日志、监控以及最重要的——流量控制限流、熔断、降级。然而很多 Harness 的用户特别是自托管版本的初级/中级运维/DevOps 工程师往往会忽略 Harness 层接口限流的重要性或者虽然知道要配置但配置策略不合理比如阈值设得太高/太低没有区分不同用户/API Key/项目/接口类型的优先级或者只配置了 SaaS 自带的基础限流但对自托管版本的自定义接口/扩展层接口没有覆盖或者没有结合监控和告警形成完整的“防护-发现-响应-优化”闭环。这些疏忽都可能导致以下严重问题外部恶意攻击DDoS/CC 攻击通过 Harness 层接口直接穿透到内部微服务集群导致整个 DevOps 平台瘫痪内部资源耗尽像我们开头提到的实习生无限循环脚本、或者某个开发团队的“批量查询所有跨区域流水线运行状态”的爬虫脚本占用了大量的 API 资源、数据库连接池资源、内存/CPU 资源导致正常的业务请求无法处理API Key 滥用权限过大的 API Key 被泄露或滥用导致大量非法操作比如批量删除 Feature Flag、批量触发高消耗的 CI/CD 流水线跨模块接口雪崩自托管版本中如果某个内部微服务比如 Harness Feature Flag Service出现响应延迟上游的 Harness Gateway 没有配置合理的熔断/限流策略可能会导致上游服务线程池耗尽进而引发整个系统的雪崩效应。2.3 核心价值Value Proposition本文将从理论到实战全方位讲解 Harness 层接口限流的相关知识帮助你理解 Harness 平台的架构模型明确“Harness 层接口”到底指的是哪些服务掌握接口限流的核心概念、算法和数学模型为配置合理的限流策略打下坚实的理论基础学会在 Harness SaaS 版本和自托管版本Self-Managed Enterprise/Self-Managed Community Edition中配置不同类型的限流策略包括 SaaS 自带的基础限流、自托管版本的 Nginx Ingress Controller 限流、Kong API Gateway 限流如果用 Kong 替代了默认的 Harness Gateway、以及 Harness 自定义 Java 服务层的限流结合监控和告警形成完整的“防护-发现-响应-优化”闭环了解接口限流的最佳实践和行业发展趋势避免踩坑。不管你是 Harness 的初级用户、中级运维/DevOps 工程师还是负责整个 DevOps 平台稳定性的高级架构师本文都能给你带来实实在在的收获。2.4 文章概述Roadmap本文的结构如下理论基础篇介绍 Harness 平台的架构模型、接口限流的核心概念包括边界与外延、常用的限流算法计数器、滑动窗口、漏桶、令牌桶及其数学模型和算法流程图、以及核心概念之间的关系对比表、ER 实体关系图、交互关系图Harness 平台限流实战篇分为 SaaS 版本和自托管版本两部分详细讲解如何配置不同类型的限流策略包括环境安装、系统功能设计、系统架构设计、系统接口设计、核心实现源代码监控与告警闭环篇介绍如何结合 Prometheus、Grafana、Harness Alert Manager 等工具监控限流的执行情况并及时发出告警最佳实践与行业发展篇分享 Harness 层接口限流的最佳实践 tips以及接口限流技术在 DevOps 平台领域的发展历史和未来趋势案例研究篇通过一个真实的中型 SaaS 公司的案例讲解如何从无到有搭建 Harness 层接口限流体系结论与展望篇总结本文的主要内容重申接口限流的重要性并鼓励读者尝试本文介绍的方法附加部分包括参考文献/延伸阅读、致谢、作者简介。三、 正文3.1 理论基础篇从架构到算法筑牢 Harness 层接口限流的根基3.1.1 核心概念什么是 Harness 层接口什么是接口限流3.1.1.1 核心概念 1Harness 平台的架构模型与 Harness 层接口的定义在深入讲解接口限流之前我们首先需要明确 Harness 平台的架构模型因为只有了解了架构我们才能知道“Harness 层接口”到底指的是哪些服务以及应该在哪些地方配置限流策略。Harness 平台不管是 SaaS 版本还是自托管版本采用的是微服务架构 多租户 SaaS 架构自托管版本也支持单租户部署。根据 Harness 官方文档的最新架构图截至 202X 年 X 月Harness 平台的核心架构可以分为以下 5 层接入层Access LayerHarness SaaS 版本由 Harness 官方运营的 Cloudflare CDN、AWS WAF、以及 Harness 自研的Public Gateway也叫 Harness Gateway组成Harness 自托管版本SME/SMC通常由用户自己配置的Nginx Ingress Controller默认方案、Kong API Gateway可选替代方案、或者HAProxy组成同时也可以配合用户自己的 CDN 和 WAF 使用核心功能接收来自外部的所有 HTTP/HTTPS 请求包括开发者通过浏览器访问的 Web 控制台请求、CI/CD 客户端如 Harness CLI、Jenkins Harness Plugin、GitHub Actions Harness Action发送的 API 请求、以及内部跨区域/跨集群的服务调用请求并进行HTTPS 终止、CDN 缓存、WAF 防护、认证令牌验证JWT/OAuth2.0/SAML/API Key、多租户路由将请求路由到对应的租户/项目/微服务、日志记录、监控指标采集以及最重要的——流量控制限流、熔断、降级。网关服务层Gateway Service Layer即我们本文重点讨论的Harness 层接口Harness SaaS 版本主要指 Harness 自研的Public Gateway和Internal GatewayHarness 自托管版本如果用的是默认的 Nginx Ingress Controller那么网关服务层就是 Nginx Ingress Controller 后面的 Harness 自研的Gateway ServiceJava 服务如果用的是 Kong API Gateway那么网关服务层就是 Kong 本身核心功能这是整个系统的“核心流量调度中心”除了继续执行接入层的部分功能比如更细粒度的认证、鉴权、日志、监控还负责跨微服务的请求聚合、协议转换比如将 HTTP 请求转换为 gRPC 请求发送给内部微服务、更细粒度的流量控制比如按用户/API Key/项目/接口类型/请求方法/请求参数进行限流、熔断、降级。核心微服务层Core Microservices Layer这是 Harness 平台的“业务逻辑核心”由几十个甚至上百个独立的微服务组成每个微服务负责一个特定的业务领域主要的核心微服务包括Pipeline Service负责 CI/CD 流水线的创建、编辑、触发、执行、监控Feature Flag ServiceFF Service负责 Feature Flag 的创建、编辑、查询、更新、灰度发布、A/B 测试Secret Manager Service负责 Secret如 API Key、数据库密码、SSH 密钥的存储、加密、解密、访问控制Cloud Provider Service负责云服务提供商如 AWS、Azure、GCP、阿里云、腾讯云的认证、资源调度、环境管理Identity and Access Management ServiceIAM Service负责用户、团队、角色、权限的管理Monitoring and Alerting Service负责监控指标的采集、存储、查询、告警内部通信协议大部分核心微服务之间采用gRPC协议通信少部分采用HTTP/HTTPS协议通信。数据存储层Data Storage Layer这是 Harness 平台的“数据仓库”负责存储所有的业务数据、监控数据、日志数据主要的存储组件包括PostgreSQL作为主要的关系型数据库存储用户、团队、角色、权限、流水线、Feature Flag、Secret 等结构化数据MongoDB作为主要的文档型数据库存储流水线执行日志、Feature Flag 灰度发布数据、A/B 测试数据等半结构化/非结构化数据Redis作为主要的缓存和消息队列存储用户会话、JWT 令牌、限流计数器、滑动窗口数据、令牌桶数据、Pipeline Service 和 FF Service 的实时数据Kafka作为主要的分布式消息队列负责微服务之间的异步通信、日志数据的收集、监控数据的转发Elasticsearch作为主要的搜索引擎和日志分析引擎存储和查询所有的日志数据Prometheus作为主要的时序数据库存储和查询所有的监控指标数据。基础设施层Infrastructure LayerHarness SaaS 版本由 Harness 官方运营的 AWS、Azure、GCP 等云服务提供商的基础设施组成Harness 自托管版本可以部署在用户自己的私有云、公有云、混合云、或者裸金属服务器上核心功能提供计算、存储、网络、容器编排Kubernetes自托管版本默认使用 Kubernetes 部署等基础设施服务。根据以上的架构模型我们可以给出本文对 Harness 层接口的统一定义Harness 层接口指的是 Harness 平台中连接外部请求方Web 控制台、CI/CD 客户端、第三方系统与内部核心微服务集群的第一道或核心层服务接口主要包括接入层的 CDN/WAF/Ingress Controller 接口以及网关服务层的 Public Gateway/Internal Gateway/Gateway Service/Kong API Gateway 接口。在本文的后续内容中我们将重点讨论网关服务层的接口限流因为接入层的限流比如 CDN 的限流、WAF 的限流通常是比较粗粒度的比如按 IP 地址限流而网关服务层的限流可以实现更细粒度、更灵活、更符合 DevOps 平台业务场景的限流策略比如按用户/API Key/项目/接口类型/请求方法/请求参数进行限流按优先级进行限流按动态阈值进行限流。3.1.1.2 核心概念 2接口限流的定义、边界与外延在明确了 Harness 层接口的定义之后我们接下来需要明确接口限流的定义、边界与外延。3.1.1.2.1 接口限流的定义接口限流Rate Limiting也叫流量控制Traffic Control、速率限制是指在一定的时间窗口内对某个接口的请求数量、请求频率、或者请求数据量进行限制以防止该接口被过度调用从而保护接口所在的服务以及下游的服务、数据库、缓存等组件的稳定性和可用性。接口限流的核心思想是“丢卒保车”——当请求量超过系统的承受能力时优先拒绝那些非核心的、低优先级的请求保证核心的、高优先级的请求能够正常处理。3.1.1.2.2 接口限流的边界接口限流的边界是指接口限流应该在哪些地方配置以及接口限流应该限制哪些内容。根据 Harness 平台的架构模型接口限流的配置边界通常包括以下几个地方接入层Access LayerCDN 限流按 IP 地址、URL 路径、请求方法、请求头、请求参数等进行粗粒度的限流比如限制某个 IP 地址每分钟最多访问 1000 次 Harness 控制台的首页WAF 限流按 IP 地址、URL 路径、请求方法、请求头、请求参数、攻击特征等进行限流比如限制某个 IP 地址每分钟最多发送 100 次带有 SQL 注入攻击特征的请求Ingress Controller 限流按 IP 地址、URL 路径、请求方法、请求头、请求参数、租户 ID 等进行限流比如限制某个租户 ID 每分钟最多发送 5000 次 API 请求网关服务层Gateway Service Layer即 Harness 层接口Public Gateway/Internal Gateway/Gateway Service 限流按用户 ID、API Key、团队 ID、项目 ID、接口类型比如 Pipeline API、FF API、Secret API、接口 URL 路径、请求方法、请求参数、优先级等进行细粒度、灵活的限流这是本文重点讨论的配置边界核心微服务层Core Microservices Layer微服务内部限流在每个核心微服务内部比如 Pipeline Service、FF Service配置限流比如限制 Pipeline Service 每分钟最多触发 1000 次高消耗的“构建 Docker 镜像并推送到 ECR”的 CI 流水线数据存储层Data Storage Layer数据库连接池限流限制每个微服务对 PostgreSQL/MongoDB 的连接池大小比如限制 Pipeline Service 对 PostgreSQL 的连接池大小为 100Redis 限流利用 Redis 的原子性操作比如 INCR、EXPIRE实现分布式限流这是网关服务层和核心微服务层常用的限流实现方式Kafka 限流限制每个微服务对 Kafka 主题的生产/消费速率比如限制 Pipeline Service 每分钟最多向 Kafka 的“pipeline-execution-logs”主题生产 10000 条日志消息。接口限流的限制内容通常包括以下几个方面请求数量Request Count在一定的时间窗口内限制某个接口的请求总数比如限制某个 API Key 每分钟最多发送 1000 次 API 请求请求频率Request Frequency限制两个连续请求之间的最小时间间隔比如限制某个 API Key 每 10ms 最多发送 1 次 API 请求请求数据量Request Payload Size限制某个接口的请求体大小比如限制“上传 CI/CD 流水线配置文件”的接口的请求体大小最多为 10MB并发请求数Concurrent Request Count限制某个接口同时处理的请求总数比如限制“获取所有跨区域流水线运行状态”的接口同时最多处理 100 个请求请求响应时间Request Response Time如果某个接口的平均响应时间超过了某个阈值就自动降低该接口的限流阈值这是一种动态限流策略。3.1.1.2.3 接口限流的外延接口限流的外延是指与接口限流相关的其他技术这些技术通常和接口限流一起使用形成完整的“流量防护体系”。与接口限流相关的主要技术包括熔断Circuit Breaker当某个接口的错误率超过了某个阈值比如 50%或者平均响应时间超过了某个阈值比如 5s就自动“熔断”该接口在一定的时间窗口内拒绝所有对该接口的请求一段时间后再“半打开”该接口允许少量请求通过如果这些请求都成功处理了就“关闭”熔断恢复正常的请求处理熔断的核心思想是“防止雪崩效应”——当某个下游服务出现故障时上游服务不要再继续发送请求以免浪费资源同时也给下游服务留出恢复的时间降级Degradation当系统的负载超过了某个阈值就自动“降级”某些非核心的功能比如关闭 A/B 测试的实时数据统计功能关闭 Feature Flag 的灰度发布监控面板的实时刷新功能只提供基础的查询功能降级的核心思想是“丢卒保车”——优先保证核心功能的可用性牺牲非核心功能的可用性WAFWeb Application FirewallWeb 应用防火墙用于识别和阻止 SQL 注入、XSS 攻击、CSRF 攻击、DDoS/CC 攻击等常见的 Web 攻击身份认证Authentication验证请求方的身份比如验证 JWT 令牌、OAuth2.0 令牌、SAML 断言、API Key权限控制Authorization验证请求方是否有权限访问某个接口或执行某个操作比如验证某个 API Key 是否有权限删除 Feature Flag监控Monitoring监控接口的请求量、请求频率、错误率、平均响应时间、限流次数、熔断次数、降级次数等指标告警Alerting当接口的某个指标超过了某个阈值就及时发出告警比如当某个 API Key 的限流次数每分钟超过 100 次时就发送邮件、短信、Slack 消息、或者钉钉消息给运维/DevOps 工程师日志Logging记录所有的请求包括被限流的请求、被熔断的请求、被降级的请求、成功处理的请求、失败处理的请求的详细信息比如请求方的 IP 地址、用户 ID、API Key、团队 ID、项目 ID、接口 URL 路径、请求方法、请求参数、请求体大小、响应状态码、响应时间、限流原因、熔断原因、降级原因分布式追踪Distributed Tracing追踪一个请求在整个系统中的调用链路比如从 Harness 控制台的前端到 Harness Gateway到 FF Service到 Redis到 MongoDB再返回前端的整个过程以便于排查故障和优化性能常用的分布式追踪工具包括 Jaeger、Zipkin、Harness Distributed Tracing。3.1.1.3 核心概念 3Harness 层接口限流的业务场景在 Harness 平台中接口限流主要用于以下几个业务场景防止外部 DDoS/CC 攻击比如某个竞争对手或者黑客通过大量的僵尸网络向 Harness 平台的 API 接口发送大量的请求试图瘫痪整个 DevOps 平台防止内部资源耗尽比如像我们开头提到的实习生无限循环脚本或者某个开发团队的“批量查询所有跨区域流水线运行状态”的爬虫脚本占用了大量的 API 资源、数据库连接池资源、内存/CPU 资源防止 API Key 滥用比如权限过大的 API Key 被泄露或滥用导致大量非法操作保证核心业务的可用性比如在灰度发布期间优先保证核心 Feature Flag 的查询/更新请求能够正常处理拒绝非核心的 A/B 测试数据统计请求控制云资源的消耗比如限制某个团队每月最多触发 10000 次高消耗的“构建大型 Docker 镜像并推送到 ECR”的 CI 流水线以控制 AWS EC2 实例和 ECR 存储的费用符合 API 管理的最佳实践比如对外提供的 Harness Public API供第三方系统集成使用通常需要配置合理的限流策略以防止第三方系统过度调用 API 导致平台不稳定。3.1.2 问题背景为什么 Harness 层接口限流如此重要在 3.1.1 节中我们已经提到了 Harness 层接口限流的一些重要性但为了让大家更深入地理解我们接下来将从DevOps 平台的特性、Harness 平台的用户规模和业务场景、以及接口限流缺失可能导致的严重后果三个方面详细讲解 Harness 层接口限流的问题背景。3.1.2.1 DevOps 平台的特性DevOps 平台如 Harness、GitLab CI/CD、Jenkins X具有以下几个特性这些特性使得接口限流变得尤为重要高并发、高吞吐量现代 DevOps 平台通常需要支持大量的开发者同时访问以及大量的 CI/CD 流水线同时运行比如一家大型互联网公司的 DevOps 平台可能需要支持 10000 开发者同时访问日均 100000 CI/CD 流水线运行QPS 可能达到 10000多租户现代 DevOps 平台通常支持多租户部署即多个不同的团队/公司共享同一个 DevOps 平台的基础设施这就需要对不同的租户进行流量隔离和流量控制防止某个租户的过度调用影响其他租户的正常使用多样化的请求方DevOps 平台的请求方不仅包括开发者通过浏览器访问的 Web 控制台还包括 CI/CD 客户端如 Harness CLI、Jenkins Harness Plugin、GitHub Actions Harness Action、第三方系统如 Jira、Slack、PagerDuty、以及内部跨区域/跨集群的服务调用请求不同的请求方需要不同的限流策略多样化的接口类型DevOps 平台的接口类型非常多样化包括低消耗的“查询单个 Feature Flag 状态”的接口、中等消耗的“触发单个 CI 流水线”的接口、高消耗的“批量查询所有跨区域流水线运行状态”的接口、以及超高消耗的“构建大型 Docker 镜像并推送到 ECR”的接口不同的接口类型需要不同的限流阈值业务连续性要求高DevOps 平台是现代软件开发生命周期的“基础设施”如果 DevOps 平台瘫痪了那么整个软件开发生命周期包括代码提交、代码审查、CI 构建、CD 部署、Feature Flag 灰度发布、监控告警都会停滞这将对公司的业务造成严重的影响API Key 广泛使用DevOps 平台通常提供大量的 Public API 供第三方系统集成使用以及供 CI/CD 客户端使用这些 API Key 通常具有较高的权限如果被泄露或滥用将导致大量非法操作。3.1.2.2 Harness 平台的用户规模和业务场景根据 Harness 官方网站的最新数据截至 202X 年 X 月Harness 平台已经拥有10000 企业客户包括一些知名的大型公司如 Capital One、Intuit、Lyft、Netflix、Shopify、Stripe、Uber 等这些客户的用户规模从几百人到几十万人不等日均 CI/CD 流水线运行次数从几千次到几百万次不等。同时Harness 平台的业务场景也非常多样化包括CI/CD 流水线的创建、编辑、触发、执行、监控Feature Flag 的创建、编辑、查询、更新、灰度发布、A/B 测试Secret 的存储、加密、解密、访问控制云服务提供商的认证、资源调度、环境管理用户、团队、角色、权限的管理监控指标的采集、存储、查询、告警第三方系统的集成如 Jira、Slack、PagerDuty、GitHub、GitLab、Bitbucket。如此庞大的用户规模和如此多样化的业务场景使得 Harness 层接口限流变得必不可少——如果没有合理的限流策略哪怕是一个小小的失误比如像我们开头提到的实习生无限循环脚本都可能导致整个 DevOps 平台瘫痪给客户造成严重的损失。3.1.2.3 接口限流缺失可能导致的严重后果如果 Harness 层接口没有配置合理的限流策略可能会导致以下严重后果外部恶意攻击导致的平台瘫痪比如某个竞争对手或者黑客通过大量的僵尸网络向 Harness 平台的 API 接口发送大量的请求试图瘫痪整个 DevOps 平台根据 Gartner 的最新数据截至 202X 年 X 月全球每年因 DDoS/CC 攻击导致的企业损失超过1000 亿美元内部资源耗尽导致的平台瘫痪比如像我们开头提到的实习生无限循环脚本或者某个开发团队的“批量查询所有跨区域流水线运行状态”的爬虫脚本占用了大量的 API 资源、数据库连接池资源、内存/CPU 资源导致正常的业务请求无法处理API Key 滥用导致的非法操作比如权限过大的 API Key 被泄露或滥用导致大量非法操作比如批量删除 Feature Flag、批量触发高消耗的 CI/CD 流水线、批量窃取 Secret根据 Verizon 的《202X 年数据泄露调查报告》全球每年因 API Key 泄露或滥用导致的数据泄露事件超过10000 起跨模块接口雪崩导致的平台瘫痪自托管版本中如果某个内部微服务比如 Harness Feature Flag Service出现响应延迟上游的 Harness Gateway 没有配置合理的熔断/限流策略可能会导致上游服务线程池耗尽进而引发整个系统的雪崩效应云资源费用超支比如某个团队每月触发了 100000 次高消耗的“构建大型 Docker 镜像并推送到 ECR”的 CI 流水线而公司原本的预算只有 10000 次这将导致云资源费用超支客户投诉和声誉损失如果 DevOps 平台瘫痪了导致客户的软件开发生命周期停滞灰度发布延迟甚至产品发布失败这将导致客户投诉和公司的声誉损失OKR 进度延迟如果 DevOps 平台瘫痪了导致开发团队和运维团队的工作无法正常进行这将导致他们的 OKR 进度延迟。3.1.3 问题描述Harness 层接口限流常见的问题有哪些在 3.1.1 和 3.1.2 节中我们已经讲解了 Harness 层接口限流的核心概念和重要性但在实际的使用过程中很多 Harness 的用户特别是自托管版本的初级/中级运维/DevOps 工程师往往会遇到以下几个常见的问题3.1.3.1 问题 1不知道在哪些地方配置限流策略很多 Harness 的用户特别是自托管版本的初级用户往往不知道 Harness 平台的架构模型因此不知道应该在哪些地方配置限流策略——是在接入层的 Nginx Ingress Controller 配置还是在网关服务层的 Harness Gateway Service 配置还是在核心微服务层的每个微服务内部配置3.1.3.2 问题 2限流阈值设置不合理很多 Harness 的用户虽然知道要配置限流策略但限流阈值设置得太高或太低限流阈值设置得太高起不到任何防护作用一旦有大量的请求过来还是会导致平台瘫痪限流阈值设置得太低会误杀很多正常的业务请求导致开发者无法正常使用 DevOps 平台影响工作效率。3.1.3.3 问题 3限流策略不够细粒度、不够灵活很多 Harness 的用户只配置了粗粒度的限流策略比如按 IP 地址限流或者按租户 ID 限流但没有配置细粒度、灵活的限流策略比如按用户 ID、API Key、团队 ID、项目 ID、接口类型、接口 URL 路径、请求方法、请求参数、优先级进行限流。比如某个开发团队的“批量查询所有跨区域流水线运行状态”的爬虫脚本虽然占用了大量的 API 资源但这个脚本是用于公司内部的 DevOps 效率监控的属于高优先级的请求而某个实习生的“无限循环查询单个 Feature Flag 状态”的脚本属于低优先级的请求——如果只配置了粗粒度的按团队 ID 限流那么这两个请求都会被同样对待要么都被允许要么都被拒绝这显然是不合理的。3.1.3.4 问题 4没有结合监控和告警形成完整的闭环很多 Harness 的用户虽然配置了限流策略但没有结合监控和告警——他们不知道限流策略是否生效不知道有多少请求被限流了不知道被限流的请求的原因是什么不知道什么时候应该调整限流阈值。比如某个 API Key 的限流阈值设置得太低导致大量正常的业务请求被误杀但如果没有监控和告警运维/DevOps 工程师可能要等到开发者投诉之后才知道这个问题。3.1.3.5 问题 5没有对自托管版本的自定义接口/扩展层接口进行限流很多 Harness 的自托管版本用户会在 Harness 平台的基础上开发一些自定义接口/扩展层接口比如用于和公司内部的其他系统集成的接口但他们往往会忘记对这些自定义接口/扩展层接口进行限流导致这些接口被过度调用影响整个 DevOps 平台的稳定性。3.1.3.6 问题 6没有测试限流策略很多 Harness 的用户虽然配置了限流策略但没有对限流策略进行测试——他们不知道限流策略是否真的能生效不知道限流策略在高并发场景下的表现如何不知道限流策略是否会误杀正常的业务请求。比如某个用户配置了按 API Key 每分钟最多发送 1000 次请求的限流策略但如果没有进行高并发测试他们可能不知道这个限流策略在 QPS 达到 10000 时是否能正常工作是否会误杀正常的业务请求。3.1.4 问题解决如何解决 Harness 层接口限流常见的问题在 3.1.3 节中我们已经列出了 Harness 层接口限流常见的 6 个问题接下来我们将针对每个问题给出相应的初步解决方案——在本文的后续内容中我们将更详细地讲解这些解决方案的具体实现。3.1.4.1 解决方案 1明确 Harness 平台的架构模型在合适的地方配置限流策略要解决“不知道在哪些地方配置限流策略”的问题首先需要明确 Harness 平台的架构模型我们已经在 3.1.1.1 节中详细讲解过然后根据不同的限流需求在合适的地方配置限流策略粗粒度的限流需求比如按 IP 地址限流、按租户 ID 限流、按请求数据量限流可以在接入层的 CDN/WAF/Ingress Controller配置细粒度、灵活的限流需求比如按用户 ID、API Key、团队 ID、项目 ID、接口类型、接口 URL 路径、请求方法、请求参数、优先级进行限流应该在网关服务层的 Harness Gateway Service/Kong API Gateway配置微服务内部的限流需求比如限制某个微服务内部的某个方法的调用次数可以在核心微服务层的每个微服务内部配置分布式限流需求因为 Harness 平台通常是分布式部署的所以需要分布式限流应该利用Redis的原子性操作比如 INCR、EXPIRE实现或者利用Kong API Gateway的 Redis 限流插件实现或者利用Harness Gateway Service的 Redis 限流实现。3.1.4.2 解决方案 2通过监控数据和压力测试设置合理的限流阈值要解决“限流阈值设置不合理”的问题首先需要收集足够的监控数据比如过去 1 个月、过去 3 个月、过去 6 个月的接口请求量、请求频率、错误率、平均响应时间、峰值 QPS、峰值并发请求数等然后根据监控数据和业务需求设置初始的限流阈值最后通过压力测试比如用 JMeter、Locust、k6 等工具进行高并发压力测试验证和调整限流阈值。一般来说初始的限流阈值可以设置为峰值 QPS 的 1.2 倍到 1.5 倍——这样既可以起到防护作用又不会误杀太多正常的业务请求。同时还可以设置动态限流阈值——比如当系统的负载CPU 使用率、内存使用率、数据库连接池使用率超过某个阈值时就自动降低限流阈值当系统的负载恢复正常时就自动恢复原来的限流阈值。3.1.4.3 解决方案 3配置细粒度、灵活的限流策略要解决“限流策略不够细粒度、不够灵活”的问题应该在网关服务层的 Harness Gateway Service/Kong API Gateway配置细粒度、灵活的限流策略比如按维度组合限流比如按“租户 ID API Key 接口 URL 路径 请求方法”的维度组合进行限流按优先级限流比如为不同的用户/API Key/团队/项目/接口设置不同的优先级当系统的负载超过某个阈值时优先拒绝低优先级的请求保证高优先级的请求能够正常处理按白名单/黑名单限流比如将公司内部的 CI/CD 服务器的 IP 地址加入白名单不对其进行限流将某个恶意攻击的 IP 地址加入黑名单直接拒绝其所有请求按动态阈值限流比如当某个接口的平均响应时间超过 5s 时就自动将该接口的限流阈值降低到原来的 50%当该接口的平均响应时间恢复到 1s 以下时就自动恢复原来的限流阈值。3.1.4.4 解决方案 4结合监控和告警形成完整的“防护-发现-响应-优化”闭环要解决“没有结合监控和告警形成完整的闭环”的问题应该配置监控利用 Prometheus、Grafana、Harness Monitoring 等工具监控接口的请求量、请求频率、错误率、平均响应时间、限流次数、熔断次数、降级次数等指标配置告警利用 Harness Alert Manager、Prometheus Alertmanager、PagerDuty、Slack、钉钉等工具当接口的某个指标超过了某个阈值时及时发出告警响应告警当收到告警时运维/DevOps 工程师应该及时排查故障原因比如是外部恶意攻击还是内部资源耗尽还是 API Key 滥用还是限流阈值设置不合理并采取相应的措施比如禁用恶意攻击的 IP 地址/API Key、调整限流阈值、扩容基础设施、优化接口性能优化限流策略根据监控数据和告警数据定期优化限流策略比如调整限流阈值、调整限流维度、调整优先级、调整动态阈值的规则。3.1.4.5 解决方案 5对自托管版本的自定义接口/扩展层接口进行限流要解决“没有对自托管版本的自定义接口/扩展层接口进行限流”的问题应该将自定义接口/扩展层接口注册到 Harness Gateway Service/Kong API Gateway为自定义接口/扩展层接口配置和 Harness 原生接口一样的限流策略比如按用户 ID、API Key、团队 ID、项目 ID、接口 URL 路径、请求方法、请求参数、优先级进行限流为自定义接口/扩展层接口配置和 Harness 原生接口一样的监控和告警。3.1.4.6 解决方案 6对限流策略进行充分的测试要解决“没有测试限流策略”的问题应该进行功能测试验证限流策略是否真的能生效比如用 Postman 或者 curl 发送超过限流阈值的请求检查是否会被拒绝进行高并发压力测试用 JMeter、Locust、k6 等工具进行高并发压力测试验证限流策略在高并发场景下的表现如何是否会误杀正常的业务请求是否会影响系统的性能进行故障注入测试比如故意将某个内部微服务的响应时间设置得很长验证熔断策略是否能生效故意将系统的负载设置得很高验证降级策略是否能生效进行灰度测试先将限流策略应用到一个小的测试租户/项目/团队验证没有问题之后再逐步应用到所有的租户/项目/团队。3.1.5 边界与外延Harness 层接口限流的边界与外延的详细说明我们已经在 3.1.1.2.2 和 3.1.1.2.3 节中简要介绍了 Harness 层接口限流的边界与外延接下来我们将对其进行更详细的说明。3.1.5.1 Harness 层接口限流的边界的详细说明3.1.5.1.1 配置边界的详细说明在配置边界方面我们需要注意以下几点分层配置层层防护不要只在某一层配置限流策略应该在接入层、网关服务层、核心微服务层、数据存储层都配置限流策略形成“层层防护”的体系——即使某一层的限流策略失效了还有其他层的限流策略作为 backup优先在网关服务层配置细粒度的限流策略因为网关服务层是整个系统的“核心流量调度中心”可以获取到所有的请求信息比如用户 ID、API Key、团队 ID、项目 ID、接口 URL 路径、请求方法、请求参数、优先级所以可以实现最细粒度、最灵活的限流策略利用分布式限流因为 Harness 平台通常是分布式部署的比如有多个 Harness Gateway Service 实例多个核心微服务实例所以需要分布式限流——不能只在单个实例内部配置限流策略因为这样每个实例的限流阈值是独立的如果有 N 个实例那么总的限流阈值就是单个实例的 N 倍起不到防护作用分布式限流的一致性在实现分布式限流时需要注意一致性——比如在 Redis 中存储限流计数器和滑动窗口数据时需要使用 Redis 的原子性操作比如 INCR、EXPIRE、Lua 脚本以防止并发问题导致的限流计数器不准确。3.1.5.1.2 限制内容的详细说明在限制内容方面我们需要注意以下几点根据接口类型设置不同的限制内容比如低消耗的“查询单个 Feature Flag 状态”的接口可以只限制请求数量中等消耗的“触发单个 CI 流水线”的接口可以限制请求数量和并发请求数高消耗的“批量查询所有跨区域流水线运行状态”的接口可以限制请求数量、并发请求数、请求数据量根据请求方类型设置不同的限制内容比如开发者通过浏览器访问的 Web 控制台请求可以限制请求数量和请求频率CI/CD 客户端发送的 API 请求可以限制请求数量、并发请求数、请求数据量第三方系统集成发送的 API 请求可以限制更严格的请求数量和请求频率动态调整限制内容比如当系统的负载超过某个阈值时就自动增加限制内容比如从只限制请求数量到同时限制请求数量、并发请求数、请求数据量当系统的负载恢复正常时就自动减少限制内容。3.1.5.2 Harness 层接口限流的外延的详细说明在 3.1.1.2.3 节中我们已经列出了与接口限流相关的 9 个主要技术接下来我们将重点讲解其中的3 个与 Harness 层接口限流最密切相关的技术熔断、降级、分布式追踪。3.1.5.2.1 熔断Circuit Breaker熔断的概念最早是由 Martin Fowler 在 2014 年的一篇博客文章中提出的它的灵感来自于我们家里的电路保险丝——当电路中的电流超过了保险丝的额定电流时保险丝就会自动熔断切断电路以防止电器被烧毁或者引发火灾一段时间后我们可以更换保险丝或者合上空气开关恢复电路的供电。在软件系统中熔断的工作原理也是类似的——它通常有以下 3 个状态关闭状态Closed系统正常运行熔断处于关闭状态允许所有请求通过同时熔断器会持续监控接口的错误率和平均响应时间打开状态Open当接口的错误率超过了某个阈值比如 50%或者平均响应时间超过了某个阈值比如 5s并且持续了一定的时间窗口比如 1 分钟熔断器就会自动切换到打开状态在一定的时间窗口比如 5 分钟内拒绝所有对该接口的请求半打开状态Half-Open当熔断器处于打开状态的时间超过了设定的时间窗口比如 5 分钟熔断器就会自动切换到半打开状态允许少量请求通过比如每分钟允许 10 个请求通过如果这些请求都成功处理了并且错误率和平均响应