Harness 中的细粒度熔断：按 API 按租户一、引言 (Introduction)1.1 钩子 (The Hook)想象一下：你运营着一个服务于 1000+ 租户的 SaaS 电商平台。周一清晨，租户 A 的客户端因 Bug 导致对/paymentAPI 持续重试——10 分钟内，你的整个支付服务崩溃了。租户 B、C、D 都无法处理订单，客服电话被打爆，营收损失以每分钟数万元计算。更糟的是，你用的传统熔断器是粗粒度的——它只知道“支付服务挂了”，却不知道“只有租户 A 的/payment请求有问题。这不是虚构的场景——这是 90% 以上多租户微服务架构都遇到过的噩梦。传统粗粒度熔断的“一刀切，全家遭殃”，让我们不得不思考：我们能不能让熔断器更“聪明”一点？只隔离出问题的租户和 API，而不影响其他人？答案是肯定的——这正是 Harness 细粒度熔断（按 API + 按租户）要解决的核心问题。1.2 定义问题/阐述背景 (The “Why”)在分布式系统中，熔断器模式 (Circuit Breaker Pattern)是防止级联故障的第一道防线：当目标服务错误率或延迟超过阈值时，熔断器会“跳闸”，暂时停止向该服务发送请求，给系统留出恢复时间。但传统熔断器（如 Hystrix、早期 Resilience4j）存在三个致命缺陷，尤其在多租户 SaaS 场景下：租户隔离缺失：一个租户的异常请求会触发整个服务的熔断，导致所有租户受影响。API 级粒度不足：无法区分同一个服务下不同 API 的故障——比如/payment挂了，但/user-profile还好好的，粗粒度熔断会把整个服务都关掉。可见性与调试困难：你不知道是“哪个租户”、“哪个 API”出了问题，只能靠日志大海捞针。而 Harness 作为一站式 DevOps/CD 平台，其服务可靠性管理 (Service Reliability Management, SRM)模块提供了细粒度熔断能力——支持按API 路径+租户 ID双重维度定义熔断规则，实现真正的“故障隔离，精准熔断”。1.3 亮明观点/文章目标 (The “What” “How”)读完这篇文章，你将：彻底理解细粒度熔断的核心概念，以及它与粗粒度熔断的本质区别；掌握Harness SRM 中按 API + 按租户配置熔断规则的完整流程；学会如何将细粒度熔断集成到你的多租户微服务中（包括 Harness SDK、服务网格 Istio 集成）；深入了解细粒度熔断的数学模型、算法流程；获得生产环境的最佳实践与避坑指南；一窥熔断器技术的演进历史与未来趋势。我们会从基础概念讲起，逐步深入到实战配置、代码实现、架构设计，最后用一个真实的 SaaS 电商案例收尾——让你不仅“懂理论”，更能“落地用”。二、基础知识/背景铺垫 (Foundational Concepts)在开始实战之前，我们需要先搞清楚几个核心概念——否则后面的配置和代码都是“空中楼阁”。2.1 核心概念定义2.1.1 熔断器模式 (Circuit Breaker Pattern)熔断器模式的灵感来自于电路断路器：当电路负载过高时，断路器会自动断开，保护电器不被烧坏。在软件系统中，它的作用是防止级联故障——当下游服务故障时，停止向它发送请求，避免故障向上游蔓延。熔断器有三个核心状态（状态机）：闭合状态 (Closed)：正常工作状态——请求正常转发到下游服务，熔断器持续收集 metrics（错误率、延迟、请求数）。打开状态 (Open)：故障触发状态——当 metrics 超过阈值（如错误率 ≥ 50%），熔断器跳闸，**直接拒绝所有请求（或返回降级响应），并启动“冷却时间”（Cool-down Period）。半打开状态 (Half-Open)：恢复测试状态——冷却时间结束后，熔断器允许少量测试请求到下游服务。如果测试请求成功，熔断器回到闭合状态；如果失败，重新回到打开状态。2.1.2 细粒度熔断 vs 粗粒度熔断我们用一张表来对比两者的核心差异：维度粗粒度熔断细粒度熔断（按 API + 按租户）熔断粒度整个服务(tenant_id, api_path)元组租户隔离无——一个租户故障，所有租户受影响有——只隔离故障租户的故障 APIAPI 隔离无——一个 API 故障，整个服务熔断有——只隔离故障 API，其他 API 正常可见性只能看到“服务级” metrics可以看到“租户+API”级 metrics适用场景单租户、简单微服务多租户 SaaS、复杂微服务典型工具Hystrix、早期 Resilience4jHarness SRM、Resilience4j（最新版）、Istio + 自定义规则举个例子：粗粒度熔断：租户 A 的/payment错误率 80% → 整个支付服务熔断 → 租户 B、C、D 都无法用/payment和/user-profile。细粒度熔断：租户 A 的/payment错误率 80% → 只熔断(租户 A, /payment)→ 租户 A 还能用/user-profile，租户 B、C、D 所有 API 都正常。2.1.3 Harness 平台与 SRM 模块Harness 是一个一站式 DevOps/持续交付 (CD) 平台，它的核心能力包括：持续集成 (CI)：代码构建、测试、打包；持续交付 (CD)：自动化部署到 Kubernetes、VM、Serverless；服务可靠性管理 (SRM)：监控、故障排查、熔断、SLO 管理、混沌工程；云成本管理 (CCM)：优化云资源成本。我们今天要讲的细粒度熔断，就是 Harness SRM 模块的核心功能之一。Harness SRM 的定位是“全栈可靠性管理平台”——它不仅提供了从 metrics 收集、规则引擎、状态机管理、强制执行点（Enforcement Point）到可视化监控的完整闭环。2.2 相关工具/技术概览在细粒度熔断的实现中，我们会用到以下工具/技术：**Harness SRM：核心平台，负责规则配置、状态管理、监控；**Harness Collector：轻量级代理，负责从你的服务中收集 metrics（请求数、错误数、延迟）；**服务网格 (Istio/Linkerd)：可选，用于在边缘层（Sidecar）强制执行熔断规则，无需修改业务代码；**Harness SDK：可选，用于在业务代码中集成细粒度熔断（适合无法使用服务网格的场景）；**Prometheus：可选，用于存储 metrics（Harness SRM 也自带 metrics 存储）。三、核心内容/实战演练 (The Core - “How-To”)现在我们进入实战环节——我们将以一个多租户 SaaS 电商平台为例，一步步教你如何在 Harness 中配置按 API + 按租户的细粒度熔断。3.1 项目背景与场景设定我们的电商平台叫EcomSaaS，有以下特点：多租户架构：每个租户有唯一的tenant_id（从 JWT Token 的tenant_idclaim 中获取）；核心服务：payment-service（支付服务），有两个 API：POST /api/v1/payment/charge：处理支付请求；GET /api/v1/payment/history：查询支付历史；问题场景：租户tenant-123的客户端有 Bug，当支付失败时会重试 10 次，导致(tenant-123, /api/v1/payment/charge)的错误率飙升到 90%；目标：只熔断(tenant-123, /api/v1/payment/charge)，不影响其他租户和其他 API。3.2 步骤一：准备 Harness 环境首先，你需要一个 Harness 账号——你可以去 Harness 官网 注册免费试用账号（Free Tier），支持 14 天免费使用所有功能。3.2.1 创建 Harness 项目登录 Harness 控制台，点击左上角的“Create Project；填写项目名称：EcomSaaS-Reliability；选择项目类型：“Service Reliability”（因为我们主要用 SRM 模块）；点击“Create”。3.2.2 启用 Harness SRM 模块在 Harness 中，SRM 模块默认是启用的——你只需要在左侧导航栏中点击“Service Reliability”即可进入 SRM 控制台。3.3 步骤二：连接你的服务到 Harness SRM接下来，我们需要把payment-service连接到 Harness SRM——这样 Harness 才能收集 metrics 并应用熔断规则。Harness 支持两种连接方式：**Kubernetes 部署（推荐）：如果你的服务部署在 Kubernetes 上，Harness 可以自动发现服务并安装 Collector；**非 Kubernetes 部署（VM/Serverless）：手动安装 Harness Collector 到你的服务所在的环境。我们这里以Kubernetes + Istio为例——这是生产环境最常用的组合。3.3.1 安装 Harness Kubernetes 代理在 Harness SRM 控制台，点击 **“Setup” → “Agents” → “Add Agent”；选择“Kubernetes”；按照提示下载 YAML 配置文件，使用kubectl apply -f harness-agent.yaml安装到你的 Kubernetes 集群；等待代理状态变为“Connected”。3.3.2 发现服务并配置 metrics 收集在 Harness SRM 控制台，点击 **“Services” → “Add Service”；选择 **“Kubernetes”，选择你的集群；选择payment-service所在的命名空间；选择payment-service，点击“Add”；配置 metrics 收集：选择“Istio Metrics”（因为我们用了 Istio，Sidecar 会自动收集 HTTP metrics）；配置 metrics 维度：添加tenant_id（从 HTTP HeaderX-Tenant-ID或 JWT Claim 中获取）；配置 metrics 指标：request_count：请求数；error_count：错误数（HTTP 状态码 ≥ 400）；latency_p95：95分位延迟。关键点：这里我们要确保tenant_id被正确采集——如果你的服务用 JWT Token，你需要在 Istio 中配置“Extract JWT Claim 到 HTTP Header，或者在 Harness Collector 中配置从 JWT 中提取tenant_id。3.4 步骤三：配置细粒度熔断规则（按 API + 按租户）现在，我们来创建核心的熔断规则——只针对(tenant_id, api_path)元组生效。3.4.1 进入熔断规则配置页面在 Harness SRM 控制台，点击“Circuit Breakers” → “Add Circuit Breaker”。3.4.2 定义熔断规则的基本信息名称：payment-service-tenant-api-circuit-breaker；描述：按租户 + 按 API 的细粒度熔断规则；关联服务：payment-service。3.4.3 配置熔断粒度（关键步骤！）这一步是细粒度熔断的核心——我们要选择“Custom Dimensions”（自定义维度）来定义熔断粒度：点击“Add Dimension”；选择“API Path（从 Istio metrics 的request.path中获取）；点击“Add Dimension”；选择“Tenant ID”（从我们刚才配置的tenant_id维度中获取）；点击“Next”。这样，Harness 就会为每一个(api_path, tenant_id)元组维护一个独立的熔断器状态机——这就是“细粒度”的本质！3.4.4 配置熔断阈值接下来，我们配置触发熔断的 metrics 阈值——我们用错误率和95分位延迟两个指标：阈值 1：错误率指标：error_rate（计算方式：error_count / request_count）；时间窗口：60s（最近 60 秒的 metrics）；阈值：50%（错误率 ≥ 50% 触发熔断）；最小请求数：10（时间窗口内至少有 10 个请求才会触发熔断——避免误判）。阈值 2：95分位延迟指标：latency_p95；时间窗口：60s；阈值：2000ms（95分位延迟 ≥ 2s 触发熔断）；最小请求数：10。3.4.5 配置状态机参数接下来，我们配置熔断器状态机的参数：冷却时间（Cool-down Period）：30s（熔断器打开后，等待 30 秒再进入半打开状态）；半打开状态测试请求数：5（半打开状态时，允许 5 个测试请求）；半打开状态成功阈值：80%（测试请求的成功率 ≥ 80% 才会回到闭合状态）；降级响应（Fallback Response）：可选，当熔断器打开时，返回自定义的降级响应——比如：{"code":429,"message":"Your tenant's payment API is temporarily unavailable due to high error rate. Please try again later.","tenant_id":"{ {tenant_id}}","api_path":"{ {api_path}}"}3.4.6 配置强制执行点（Enforcement Point）最后，我们选择在哪里强制执行熔断规则——有两个选项：Istio Sidecar（推荐）：在 Istio 的 Envoy Sidecar 中强制执行——无需修改业务代码，性能最优；Harness SDK：在业务代码中强制执行——适合无法使用服务网格的场景。我们这里选择Istio Sidecar：点击“Enforcement Point”→“Istio”；选择你的 Istio 集群；选择payment-service的 Sidecar；点击“Save”。3.5 步骤四：集成细粒度熔断到业务代码（可选，适合无服务网格场景）如果你无法使用 Istio 或其他服务网格，你可以用Harness SRM SDK在业务代码中集成细粒度熔断。我们以 Python 为例：3.5.1 安装 Harness SRM SDKpipinstallharness-srm3.5.2 Python 代码实现我们来写一个payment-service的 Python 代码示例，集成细粒度熔断：fromfastapiimportFastAPI,Request,HTTPExceptionfromharness_srmimportHarnessSRM,CircuitBreakerConfig,Dimensionimportosimportjwt# 初始化 FastAPI 应用app=FastAPI()# 初始化 Harness SRM 客户端harness_srm=HarnessSRM(api_key=os.getenv("HARNESS_SRM_API_KEY"),project_id=os.getenv("HARNESS_PROJECT_ID"),org_id=os.getenv("HARNESS_ORG_ID"))# 定义细粒度熔断配置circuit_breaker_config=CircuitBreakerConfig(name="payment-service-tenant-api-circuit-breaker",dimensions=[
Harness 中的细粒度熔断：按 API 按租户
Harness 中的细粒度熔断：按 API 按租户一、引言 (Introduction)1.1 钩子 (The Hook)想象一下：你运营着一个服务于 1000+ 租户的 SaaS 电商平台。周一清晨，租户 A 的客户端因 Bug 导致对/paymentAPI 持续重试——10 分钟内，你的整个支付服务崩溃了。租户 B、C、D 都无法处理订单，客服电话被打爆，营收损失以每分钟数万元计算。更糟的是，你用的传统熔断器是粗粒度的——它只知道“支付服务挂了”，却不知道“只有租户 A 的/payment请求有问题。这不是虚构的场景——这是 90% 以上多租户微服务架构都遇到过的噩梦。传统粗粒度熔断的“一刀切，全家遭殃”，让我们不得不思考：我们能不能让熔断器更“聪明”一点？只隔离出问题的租户和 API，而不影响其他人？答案是肯定的——这正是 Harness 细粒度熔断（按 API + 按租户）要解决的核心问题。1.2 定义问题/阐述背景 (The “Why”)在分布式系统中，熔断器模式 (Circuit Breaker Pattern)是防止级联故障的第一道防线：当目标服务错误率或延迟超过阈值时，熔断器会“跳闸”，暂时停止向该服务发送请求，给系统留出恢复时间。但传统熔断器（如 Hystrix、早期 Resilience4j）存在三个致命缺陷，尤其在多租户 SaaS 场景下：租户隔离缺失：一个租户的异常请求会触发整个服务的熔断，导致所有租户受影响。API 级粒度不足：无法区分同一个服务下不同 API 的故障——比如/payment挂了，但/user-profile还好好的，粗粒度熔断会把整个服务都关掉。可见性与调试困难：你不知道是“哪个租户”、“哪个 API”出了问题，只能靠日志大海捞针。而 Harness 作为一站式 DevOps/CD 平台，其服务可靠性管理 (Service Reliability Management, SRM)模块提供了细粒度熔断能力——支持按API 路径+租户 ID双重维度定义熔断规则，实现真正的“故障隔离，精准熔断”。1.3 亮明观点/文章目标 (The “What” “How”)读完这篇文章，你将：彻底理解细粒度熔断的核心概念，以及它与粗粒度熔断的本质区别；掌握Harness SRM 中按 API + 按租户配置熔断规则的完整流程；学会如何将细粒度熔断集成到你的多租户微服务中（包括 Harness SDK、服务网格 Istio 集成）；深入了解细粒度熔断的数学模型、算法流程；获得生产环境的最佳实践与避坑指南；一窥熔断器技术的演进历史与未来趋势。我们会从基础概念讲起，逐步深入到实战配置、代码实现、架构设计，最后用一个真实的 SaaS 电商案例收尾——让你不仅“懂理论”，更能“落地用”。二、基础知识/背景铺垫 (Foundational Concepts)在开始实战之前，我们需要先搞清楚几个核心概念——否则后面的配置和代码都是“空中楼阁”。2.1 核心概念定义2.1.1 熔断器模式 (Circuit Breaker Pattern)熔断器模式的灵感来自于电路断路器：当电路负载过高时，断路器会自动断开，保护电器不被烧坏。在软件系统中，它的作用是防止级联故障——当下游服务故障时，停止向它发送请求，避免故障向上游蔓延。熔断器有三个核心状态（状态机）：闭合状态 (Closed)：正常工作状态——请求正常转发到下游服务，熔断器持续收集 metrics（错误率、延迟、请求数）。打开状态 (Open)：故障触发状态——当 metrics 超过阈值（如错误率 ≥ 50%），熔断器跳闸，**直接拒绝所有请求（或返回降级响应），并启动“冷却时间”（Cool-down Period）。半打开状态 (Half-Open)：恢复测试状态——冷却时间结束后，熔断器允许少量测试请求到下游服务。如果测试请求成功，熔断器回到闭合状态；如果失败，重新回到打开状态。2.1.2 细粒度熔断 vs 粗粒度熔断我们用一张表来对比两者的核心差异：维度粗粒度熔断细粒度熔断（按 API + 按租户）熔断粒度整个服务(tenant_id, api_path)元组租户隔离无——一个租户故障，所有租户受影响有——只隔离故障租户的故障 APIAPI 隔离无——一个 API 故障，整个服务熔断有——只隔离故障 API，其他 API 正常可见性只能看到“服务级” metrics可以看到“租户+API”级 metrics适用场景单租户、简单微服务多租户 SaaS、复杂微服务典型工具Hystrix、早期 Resilience4jHarness SRM、Resilience4j（最新版）、Istio + 自定义规则举个例子：粗粒度熔断：租户 A 的/payment错误率 80% → 整个支付服务熔断 → 租户 B、C、D 都无法用/payment和/user-profile。细粒度熔断：租户 A 的/payment错误率 80% → 只熔断(租户 A, /payment)→ 租户 A 还能用/user-profile，租户 B、C、D 所有 API 都正常。2.1.3 Harness 平台与 SRM 模块Harness 是一个一站式 DevOps/持续交付 (CD) 平台，它的核心能力包括：持续集成 (CI)：代码构建、测试、打包；持续交付 (CD)：自动化部署到 Kubernetes、VM、Serverless；服务可靠性管理 (SRM)：监控、故障排查、熔断、SLO 管理、混沌工程；云成本管理 (CCM)：优化云资源成本。我们今天要讲的细粒度熔断，就是 Harness SRM 模块的核心功能之一。Harness SRM 的定位是“全栈可靠性管理平台”——它不仅提供了从 metrics 收集、规则引擎、状态机管理、强制执行点（Enforcement Point）到可视化监控的完整闭环。2.2 相关工具/技术概览在细粒度熔断的实现中，我们会用到以下工具/技术：**Harness SRM：核心平台，负责规则配置、状态管理、监控；**Harness Collector：轻量级代理，负责从你的服务中收集 metrics（请求数、错误数、延迟）；**服务网格 (Istio/Linkerd)：可选，用于在边缘层（Sidecar）强制执行熔断规则，无需修改业务代码；**Harness SDK：可选，用于在业务代码中集成细粒度熔断（适合无法使用服务网格的场景）；**Prometheus：可选，用于存储 metrics（Harness SRM 也自带 metrics 存储）。三、核心内容/实战演练 (The Core - “How-To”)现在我们进入实战环节——我们将以一个多租户 SaaS 电商平台为例，一步步教你如何在 Harness 中配置按 API + 按租户的细粒度熔断。3.1 项目背景与场景设定我们的电商平台叫EcomSaaS，有以下特点：多租户架构：每个租户有唯一的tenant_id（从 JWT Token 的tenant_idclaim 中获取）；核心服务：payment-service（支付服务），有两个 API：POST /api/v1/payment/charge：处理支付请求；GET /api/v1/payment/history：查询支付历史；问题场景：租户tenant-123的客户端有 Bug，当支付失败时会重试 10 次，导致(tenant-123, /api/v1/payment/charge)的错误率飙升到 90%；目标：只熔断(tenant-123, /api/v1/payment/charge)，不影响其他租户和其他 API。3.2 步骤一：准备 Harness 环境首先，你需要一个 Harness 账号——你可以去 Harness 官网 注册免费试用账号（Free Tier），支持 14 天免费使用所有功能。3.2.1 创建 Harness 项目登录 Harness 控制台，点击左上角的“Create Project；填写项目名称：EcomSaaS-Reliability；选择项目类型：“Service Reliability”（因为我们主要用 SRM 模块）；点击“Create”。3.2.2 启用 Harness SRM 模块在 Harness 中，SRM 模块默认是启用的——你只需要在左侧导航栏中点击“Service Reliability”即可进入 SRM 控制台。3.3 步骤二：连接你的服务到 Harness SRM接下来，我们需要把payment-service连接到 Harness SRM——这样 Harness 才能收集 metrics 并应用熔断规则。Harness 支持两种连接方式：**Kubernetes 部署（推荐）：如果你的服务部署在 Kubernetes 上，Harness 可以自动发现服务并安装 Collector；**非 Kubernetes 部署（VM/Serverless）：手动安装 Harness Collector 到你的服务所在的环境。我们这里以Kubernetes + Istio为例——这是生产环境最常用的组合。3.3.1 安装 Harness Kubernetes 代理在 Harness SRM 控制台，点击 **“Setup” → “Agents” → “Add Agent”；选择“Kubernetes”；按照提示下载 YAML 配置文件，使用kubectl apply -f harness-agent.yaml安装到你的 Kubernetes 集群；等待代理状态变为“Connected”。3.3.2 发现服务并配置 metrics 收集在 Harness SRM 控制台，点击 **“Services” → “Add Service”；选择 **“Kubernetes”，选择你的集群；选择payment-service所在的命名空间；选择payment-service，点击“Add”；配置 metrics 收集：选择“Istio Metrics”（因为我们用了 Istio，Sidecar 会自动收集 HTTP metrics）；配置 metrics 维度：添加tenant_id（从 HTTP HeaderX-Tenant-ID或 JWT Claim 中获取）；配置 metrics 指标：request_count：请求数；error_count：错误数（HTTP 状态码 ≥ 400）；latency_p95：95分位延迟。关键点：这里我们要确保tenant_id被正确采集——如果你的服务用 JWT Token，你需要在 Istio 中配置“Extract JWT Claim 到 HTTP Header，或者在 Harness Collector 中配置从 JWT 中提取tenant_id。3.4 步骤三：配置细粒度熔断规则（按 API + 按租户）现在，我们来创建核心的熔断规则——只针对(tenant_id, api_path)元组生效。3.4.1 进入熔断规则配置页面在 Harness SRM 控制台，点击“Circuit Breakers” → “Add Circuit Breaker”。3.4.2 定义熔断规则的基本信息名称：payment-service-tenant-api-circuit-breaker；描述：按租户 + 按 API 的细粒度熔断规则；关联服务：payment-service。3.4.3 配置熔断粒度（关键步骤！）这一步是细粒度熔断的核心——我们要选择“Custom Dimensions”（自定义维度）来定义熔断粒度：点击“Add Dimension”；选择“API Path（从 Istio metrics 的request.path中获取）；点击“Add Dimension”；选择“Tenant ID”（从我们刚才配置的tenant_id维度中获取）；点击“Next”。这样，Harness 就会为每一个(api_path, tenant_id)元组维护一个独立的熔断器状态机——这就是“细粒度”的本质！3.4.4 配置熔断阈值接下来，我们配置触发熔断的 metrics 阈值——我们用错误率和95分位延迟两个指标：阈值 1：错误率指标：error_rate（计算方式：error_count / request_count）；时间窗口：60s（最近 60 秒的 metrics）；阈值：50%（错误率 ≥ 50% 触发熔断）；最小请求数：10（时间窗口内至少有 10 个请求才会触发熔断——避免误判）。阈值 2：95分位延迟指标：latency_p95；时间窗口：60s；阈值：2000ms（95分位延迟 ≥ 2s 触发熔断）；最小请求数：10。3.4.5 配置状态机参数接下来，我们配置熔断器状态机的参数：冷却时间（Cool-down Period）：30s（熔断器打开后，等待 30 秒再进入半打开状态）；半打开状态测试请求数：5（半打开状态时，允许 5 个测试请求）；半打开状态成功阈值：80%（测试请求的成功率 ≥ 80% 才会回到闭合状态）；降级响应（Fallback Response）：可选，当熔断器打开时，返回自定义的降级响应——比如：{"code":429,"message":"Your tenant's payment API is temporarily unavailable due to high error rate. Please try again later.","tenant_id":"{ {tenant_id}}","api_path":"{ {api_path}}"}3.4.6 配置强制执行点（Enforcement Point）最后，我们选择在哪里强制执行熔断规则——有两个选项：Istio Sidecar（推荐）：在 Istio 的 Envoy Sidecar 中强制执行——无需修改业务代码，性能最优；Harness SDK：在业务代码中强制执行——适合无法使用服务网格的场景。我们这里选择Istio Sidecar：点击“Enforcement Point”→“Istio”；选择你的 Istio 集群；选择payment-service的 Sidecar；点击“Save”。3.5 步骤四：集成细粒度熔断到业务代码（可选，适合无服务网格场景）如果你无法使用 Istio 或其他服务网格，你可以用Harness SRM SDK在业务代码中集成细粒度熔断。我们以 Python 为例：3.5.1 安装 Harness SRM SDKpipinstallharness-srm3.5.2 Python 代码实现我们来写一个payment-service的 Python 代码示例，集成细粒度熔断：fromfastapiimportFastAPI,Request,HTTPExceptionfromharness_srmimportHarnessSRM,CircuitBreakerConfig,Dimensionimportosimportjwt# 初始化 FastAPI 应用app=FastAPI()# 初始化 Harness SRM 客户端harness_srm=HarnessSRM(api_key=os.getenv("HARNESS_SRM_API_KEY"),project_id=os.getenv("HARNESS_PROJECT_ID"),org_id=os.getenv("HARNESS_ORG_ID"))# 定义细粒度熔断配置circuit_breaker_config=CircuitBreakerConfig(name="payment-service-tenant-api-circuit-breaker",dimensions=[
