---
schema_version: "1"
id: 593fac943bbbbc3c9117d2e86c1bf15208ae6f389c4e9b24ab825871b7d26c2b
title: 可用性和性能模式
collection: architect
version: current
locale: zh-cn
portal_url: https://docs.salesforce.com/architect/current/zh-cn/well-architected/guides/reliability-availability-performance-patterns.md
canonical_url: https://architect.salesforce.com/docs/architect/zh-cn/well-architected/guide/reliability-availability-performance-patterns.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: 0525a130fd091486851c5bffa1133d8109306da702eee80e5a37a6b877fed808
products:
  - 架构良好的框架
  - Architect Site Content Repo
---
# 可用性和性能模式

<br>

了解有关架构良好的[可靠性](/docs/architect/zh-cn/well-architected/guide/reliability.html)的更多信息 → [高可用性架构](/docs/architect/zh-cn/well-architected/guide/reliability.html#high-availability-architecture)

## 服务级别目标 (SLO)

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 业务影响分析      | ✅ 每个业务能力定义的 SLO（例如，“业务机会关闭流：99.9% 的可用性，p95 延迟不到 2 秒）），而不是每个技术组件 |
| 用户流文档       | ✅ 每个关键用户流都有可衡量的 SLO，涵盖可用性、延迟、吞吐量、错误率以及与实际用户体验相关的恢复时间 |
| 架构决策记录 | ✅ 可用性目标基于业务停机时间影响分析，并带有书面理由（例如，内部批处理报告 99% 与收入关键订单处理 99.95%） |
| SLO 规格            | ✅ 考虑架构复杂性的现实目标（99% = 标准平台功能，99.5% = 基本冗余和主动监控，99.9% = 多区域感知和自动故障切换，99.95% = 主动-主动模式和混沌测试，99.99% = 多组织架构） |
| 平台文档        | ✅ 解决方案 SLO 不如平台 SLA 严格（例如，平台 99.9% SLA → 解决方案 99.5% SLO），为应用程序层故障提供错误预算 |
| 监控配置      | ✅ 服务级别指标 (SLI) 可通过平台测试进行客观测量：trust.salesforce.com 正常运行时间、Experience Cloud Analytics、Event Monitoring API 响应时间、AsyncApex作业完成情况 |
| 用户体验度量       | ✅ SLO 反映完整的用户旅程（例如，“个案提交流：对于 p95 用户，所有 5 个步骤都在 8 秒内完成”）而不是个人 API 正常运行时间 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 架构文档 | ⚠ ⸏ "系统应快速可靠 " ( 不可测量,不会导致架构决策) |
| SLO 规格         | "一切都需要99.999%的正常运行时间 " ( 不合理的成本忽略了收入运营和内部管理工具之间的业务关键度差异) |
| 监控策略        | ⚏ 基础设施 CPU 监控作为主要 SLI（平台度量架构师无法操作，不反映面向用户的体验） |
| 平台容量规划 | ⚠ 解决方案 SLO 与平台 SLA 的匹配率达到 99.9%（应用程序层问题、集成失败或计划维护没有错误预算） |
| SLO 文档          | ⚠ 每个技术组件定义的 SLO，而不是每个面向用户的业务能力（组件可用性是必需的，但不足以保证用户体验的可靠性） |

## 高可用性架构

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 区域部署战略 | ✅ 具有平台管理的 Hyperforce 冗余的单区域部署(多个可用性区域、自动基础设施故障切换)为大多数解决方案提供了 99.9% 的 SLO |
| 多组织架构       | ✅ 多组织模式仅在业务需要超出平台功能的保证 RPO/RTO、监管地理数据隔离或完全区域独立性（主动-被动或主动-主动与数据同步）时适用 |
| 数据复制             | ✅ 关键数据的变更数据捕获（近实时 RPO，分钟）、近实时业务事件的平台事件、参考数据的预定批量 API 2.0 提取（24 小时 RPO） |
| 平台运行状况监控   | ✅ 订阅 trust.salesforce.com 状态通知和特定于实例的状态 API，支持主动响应事件、维护时段和性能影响 |
| 动态负载管理      | ✅ 解决方案通过减少降级期间的非关键批处理，在维护时段内延迟后台作业来响应平台运行状况 |
| 比例中心使用情况           | ✅ 每周规模中心审查确定消耗过多资源的长期事务和运营，在用户影响之前进行架构补救 |
| 故障检测层     | ✅ 多级检测：通过状态 API 的平台故障、通过超时监控的集成故障、通过异常日志记录的应用程序故障、通过延迟百分比的性能下降、通过 Proactive Monitoring 的容量警告 |
| 警报阈值             | ✅ 警报根据错误率模式触发（例如，60 秒内 5 次 API 超时）或持续降级，而不是分布式系统中常见的孤立故障 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 多组织设计           | ⚠ 实施多组织架构“以防万一”，但没有记录业务需求，说明数据同步、用户配置、部署协调的操作复杂性 |
| 平台运行状况监控 | 忽略 trust.salesforce.com 状态通知，在用户报告故障时发现维护时段（反应性而非主动响应） |
| 故障检测          | ⚠ 警报每个单独的错误，而不论频率如何（生成警报疲劳模糊关键信号）；单个 API 超时触发分页（对正常分布式系统行为的过度反应） |
| 数据复制           | 没有集成特定的监控，仅在用户报告阻止的操作（缺少外部系统运行状况的可见性）时发现集成失败 |
| 冗余策略        | ⚏ 同步调出外部丰富服务，没有超时或回退（在外部服务缓慢或不可用时阻止用户） |

## 延迟优化

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 真实用户监控 (rum)     | ✅ 通过 Experience Cloud 分析或自定义仪器测量的实际用户延迟，反映真实网络条件、设备性能、地理分布 |
| 合成监测           | ✅ 在用户报告问题之前，从多个位置自动验证可用性和性能（例如，来自 3 个地区的订单每 15 分钟提交一次） |
| 交易跟踪            | ✅ 多步骤操作，每个步骤都有时间确定瓶颈（例如，步骤 3 地址验证标注占总延迟的 70%） |
| 查询优化             | ✅ 具有索引筛选器的选择性查询、减少往返的关系查询、具有生产规模数据量的查询优化器注意事项（超过 1000 万条记录的行为发生显著变化） |
| 平台缓存利用率     | ✅ 会话或组织缓存分区提供频繁访问的参考数据，在成功操作期间预填充，在实时 API 不可用时提供过时但可用的数据 |
| 超时配置          | ✅ 面向用户的同步标注 5-10 秒（响应 UI），后台异步标注 30-60 秒（可变外部性能），批处理 120 秒（无用户等待）；每个事务多个标注的预算总额 |
| 集成延迟监控 | ✅ 每个端点与 SLO 的每次集成的 p50/p95/p99 延迟百分比；延迟异常（响应时间向上偏移）表示完全失败前的容量饱和 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 监控策略   | ⚠ 仅监控基础设施度量（服务器 CPU、网络带宽），而不进行面向用户的流测量（度量不反映实际用户体验） |
| 缓存策略        | ⚏ 频繁访问的参考数据没有平台缓存利用率（对相同数据的重复查询会增加延迟并消耗 SOQL 限制） |
| 超时配置 | ⚠ 同步流标注，超时 120 秒，导致用户盯着加载旋转器 2 分钟（应使用 5-10 秒的超时和回退） |
| 性能测试   | ⚠ 使用最少的数据量进行小规模测试（在 10M 以上的记录时，查询优化器的行为会发生显著变化，使小规模结果产生误导） |
| 集成设计    | 没有多步骤工作流的事务级跟踪（聚合度量中不可见的瓶颈步骤） |

## 吞吐量管理

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 水平缩放模式    | ✅ 跨多个资源分配的工作量：每个事务批量化处理多个记录，异步处理跨时间分配工作，数据分区跨边界分配负载 |
| 批处理配置 | ✅ 优化批处理大小平衡吞吐量和调控器限制（每个批处理 Apex 执行 2000 条记录，每个触发器调用 200 条记录，每个复合 API 调用 25 个请求） |
| API 流量管理            | ✅ 集成批处理和缓存减少了 API 消耗，按版本监控 24 小时 API 分配，容量规划在耗尽前添加许可证或限制增加 |
| 并发执行           | ✅ 分区域数据的并行批处理作业（同时运行 5 个区域汇总批次），平台事件订阅者同时处理流 |
| 队列深度监控         | ✅ 对于异步集成，队列深度趋势表明处理落后于生产速度，需要增加容量或优化吞吐量 |
| 体积异常检测       | ✅ 交易量显著高于/低于预期模式可能表明流程失控，需要调查和限制 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 批处理          | ⚏ 当数据量需要分区域并行执行时，按顺序处理所有记录（基于日期、基于记录类型或基于所有者的分区支持并发处理） |
| API 消耗           | ⚠ 集成模式在没有容量规划的情况下增加了 25% 的 API 消耗（突然出现的“超出 API 限制”错误会影响用户） |
| 队列监控          | ⚠ 没有异步集成队列深度的监控（处理落后于生产速度，没有可见性） |
| 调控器限制管理 | 处理大量达到堆大小或 CPU 时间限制的同步操作（应转移到具有专用限制的异步处理） |

## 故障缓解

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 功能关键度层次结构  | ✅ 定义的层次：关键（收入/合规性，永不降级）、重要（核心工作流，仅在主要事件期间降级）、支持（增强体验，在集成失败期间禁用）、可选（舒适，在高负载期间禁用） |
| 断路器实施 | ✅ 电路状态（关闭 = 正常，打开 = 阈值后立即失败，半打开 = 恢复探测）；平台缓存存储状态，平台事件广播更改；连续失败后打开（例如 10 次失败） |
| 重试逻辑                    | ✅ 暂时性故障的指数回退（1、2、4、8，上限为 30-60 秒）；使用回退重试网络超时和 5xx 错误，在重试后标题后重试 429 速率限制；在同一事务中不要重试客户端 4xx 错误或调控器限制错误 |
| 后备策略            | ✅ 备用数据源（实时 API 不可用时的平台缓存）、默认行为（个性化服务关闭时的标准规则）、手动流程（卡住事务的管理员界面）、重试队列（72 小时重放的平台事件） |
| 错误处理架构    | ✅ 快速失败（在条目时验证输入）、正常失败（200 个记录中的 197 个进程，其中 3 个验证失败）、信息性失败（记录事务 ID、用户上下文、堆栈跟踪）、安全失败（回滚部分事务，从不向用户公开内部事务） |
| 恢复自动化            | ✅ 平台监控触发自动恢复：异步重试机制、失败处理的死信队列、无需手动干预的快速恢复自愈工作流 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 集成依赖性   | ⚏ 当外部地址验证服务关闭时，订单提交完全失败（关键流被支持功能阻止；应该通过手动审核正常降级） |
| 断路器策略 | ⚠ 外部标注没有断路器，导致每个事务在外部系统停机时等待 120 秒超时（所有用户都受一次失败集成的影响） |
| 重试逻辑              | 在相同事务上下文中，立即重试 Apex CPU 限制超出错误（将再次失败；应作为具有专用限制的异步操作重新排队） |
| 重试逻辑              | 无限重试，直到成功（无限循环风险，事务永远不会完成；应限制最大重试尝试次数） |
| 错误处理           | ⚠ 尝试捕获块吞噬异常，没有日志记录（阻止诊断和补救的操作者看不到故障） |
| 错误处理           | 在 Lightning 页面中向最终用户显示堆栈跟踪（安全风险泄露实施细节，用户体验不佳） |
| 后备策略        | 税务计算服务无法阻止所有订单提交（无回退的关键功能；应排队等待手动处理或使用默认费率） |

## Proactive Monitoring

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 健康建模              | ✅ 聚合健康状况：服务运行状况（事务成功率 >99.5% 绿色、98-99.5% 黄色、<98% 红色）、集成运行状况（所有响应绿色、降级黄色、断路器打开红色）、数据运行状况（同步电流绿色、黄色后面、陈旧/失败红色）、容量运行状况（<70% 绿色、70-85% 黄色、>85% 红色） |
| 事件监控             | ✅ EventLogFile 对象，24 小时/1 小时交付被路由到外部 SIEM，以便保留到本机保留限制之外；捕获 API 调用、页面视图、报表导出、登录活动、Apex 执行 |
| Proactive Monitoring警报  | ✅ 持续评估显示 API 请求限制峰值（75% 阈值触发器调查）、并发 Apex 执行失败、SOQL 行限制问题、存储消耗趋势 |
| 集成健康仪表板 | ✅ 每个集成度量：错误率（<1% 的目标）、带 SLO 的延迟 p50/p95/p99、超时率（<0.1% 的目标）、断路器状态、异步队列深度；包含请求 ID、端点、响应代码、持续时间的结构化日志 |
| 可操作的警报设计      | ✅ 每个警报定义谁响应、他们检查什么、他们如何补救；包括跨越的阈值、当前值、最近趋势、仪表板链接、Runbook 链接；与紧急程度匹配的严重性（用户影响的关键页面、趋势问题的警告电子邮件） |
| 异常检测            | ✅ 数量异常（典型负载的 300%）、错误率异常（2% 与 0.5%，即使低于 5% 阈值）、延迟漂移（逐渐上升趋势）、行为异常（异常登录模式、批量作业超出计划）；用于指导调查不触发立即升级 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 事件监控       | 事件监控已启用，但未导出（本地保留不足以进行趋势分析，历史数据丢失） |
| 警报设计           | ⚏ 没有上下文、阈值或响应操作的警报消息“发生错误”（产生警报疲劳，运算符无法有效分类） |
| 警报严重性         | ⚠ 将所有异常视为关键警报（高误报率会导致警报疲劳，导致错过关键警报） |
| 健康监测      | ⚠ 没有聚合运行状况模型，操作员被单个技术指标淹没，缺少跨系统模式 |
| 集成监控 | 没有集成特定的错误率、延迟或断路器状态跟踪（通过用户报表被动发现的集成故障） |
| 容量监控    | 没有 Proactive Monitoring 或规模中心审查（资源密集型事务的可靠性风险直到生产受到影响才会被发现） |

---

有关内联示例和详细指导，请查看[可靠性支柱](/docs/architect/zh-cn/well-architected/guide/reliability.html)，或浏览[模式和反模式](/docs/architect/zh-cn/well-architected/guide/patterns-and-anti-patterns.html)资源管理器。