在这里阅读我们的更新计划。

可靠的解决方案有效和可靠地运行。它们可用、表现一致，并且能够扩展以支持不断增长的业务。

可靠的系统不会出错，行为如预期，并及时提供结果。相反，不可靠的系统速度缓慢，行为不如预期，或者在关键时刻出现故障。不可靠的系统提供的信息不准确，因此利益相关者不能 Trust 它们来做出业务决策。

系统可靠性不是恒定的。如果不为增长而设计，如今可靠的系统可能会变得不可靠。不可靠的系统可能需要昂贵的维护、重构或重新实施，从而将资金从战略项目中转移。

通过关注三个原则：可用性、性能和可扩展性，提高 Salesforce 解决方案的可靠性。Salesforce 的可扩展性产品套件提供本机功能，帮助架构师实施可靠的实施。

可用性是衡量系统运行时间的百分比。Salesforce 平台处理大多数基础设施级可用性问题。但是，您在平台上构建的解决方案的可用性以及您的客户所体验的解决方案的可用性是一项共同的责任。重要的是要了解,即使 Salesforce 具有高可用性,服务中断的风险也永远不会为零。

架构师必须为 Salesforce 服务中断做好准备，例如计划的维护或不可预见的情况。除了服务中断之外，还要考虑如何保持高性能并与业务一起发展。狭隘的架构选择会导致长期可用性问题。

在构建解决方案之前，请考虑设计阶段的可用性。延迟可用性架构的时间越长，可用性问题的实际成本从长远来看就越高。为了降低潜在风险，请在测试环境中使用 Salesforce 扩展测试。在该环境中，您可以在生产中部署代码之前在生产规模上进行测试。

架构师使用业务语言，为业务利益相关者构建技术问题，以获得支持并确定可用性工作的优先级。为了降低潜在风险，请在测试环境中使用 Salesforce 扩展测试。在该环境中，在生产中部署代码之前，您可以在生产规模上进行测试。

通过风险管理和故障缓解，您可以构建 Salesforce 解决方案的高可用性。

在 Salesforce 架构的上下文中管理风险涉及识别对系统运行、用户（包括员工、合作伙伴和客户）以及业务流程的潜在危害。通常，进行风险分析的正式过程属于项目经理的职责范围。作为架构师，确保风险分析充分代表技术和业务利益相关者的关注。您还负责确定需要根据生产高峰热点进行规模测试的关键业务用例。

风险管理中一些最大的陷阱来自没有投入足够的时间和思考。团队通常会跳过风险评估，或者将解决备份和还原问题与全面的风险评估和缓解措施混为一谈，而备份和还原是降低数据完整性风险的重要部分。

要评估 Salesforce 解决方案的风险，使用这些方法：

• 使用风险评估框架。一些大型企业可能已经建立了相关的风险矩阵。如果您有，请使用它们来确定如何分类危险、要收集哪类信息、您需要为补救准备什么等等。如果您还没有风险评估框架，请从信誉良好的来源找到并使用它。
• 从客户的角度评估影响严重性和风险类别Proactive Monitoring 和规模中心提供可配置的警报和仪表板。它们不断评估性能和可扩展性风险，并减少您对手动核对清单的依赖。Customer Trust 和感知是每个业务的关键。就业务影响而言，对于联系到客户的问题，风险通常大于联系不到客户的问题。客户可能不会像内部团队那样思考或感知风险。如果客户无法登录帐户，他们可能不关心问题的根本原因。他们最关心自己的即时体验。
• 确定风险优先级。理想情况下，每个风险都与可靠的缓解和应对计划相关联。实际上，您将需要随着时间的推移解决一些差距。采用“尽早交付价值并迭代”的方法非常重要。您和您的交付和维护团队在指定时间只能承担这么多工作。在 Salesforce 中，常见的说法是“如果一切都重要，没有什么是重要的。”我们使用 V2MOM 来确定整个公司、团队以及每个人工作的优先级和一致性。(您可以在 Trailhead 上了解更多关于 V2MOM 的信息。 )使用您的风险评估，这让您有机会与利益相关者合作，确定最重要的风险管理工作的优先级并致力于这项工作。使用扩展测试 - 创建测试计划来识别风险，以便使用扩展测试确定优先级并缓解这些风险。

使用 Proactive Monitoring 检测早期可用性风险。它显示异常，例如 API 请求限制峰值、行锁定错误或并发 Apex 失败，在问题升级为服务中断之前提供可操作的见解。

可用性模式和反模式显示了 Salesforce 解决方案中正确和糟糕的风险管理。在构建或确定系统中的重构区域之前，请使用模式来验证您的设计。

要了解有关风险管理的 Salesforce 工具的更多信息，请参阅Salesforce Tools for Reliability。

故障点是使系统不可靠的漏洞。良好的故障缓解不是精确定位每个潜在的故障点。相反，它涉及快速分类并确定故障点的优先级，以便维护和支持团队可以做出有效响应。请参阅事件响应。

要制定更好的故障缓解策略：

• **从人员、流程和技术的角度对失败点的触发器进行分类。**正如您从人员、流程和技术的角度对风险进行分类一样，将相同的思维应用于如何触发高优先级故障点。这种方法可以帮助您识别潜在的失败触发器，并制定和组织对它们的响应。有时，您可以根据触发器的分类方式，使用类似的缓解方法缓解看似不同的故障触发器。

• 确定基本、中级和成熟的缓解措施是什么样子制定缓解战略需要时间。定义缓解级别，以帮助您和团队了解您可以立即将控制放在何处，以及如何随着时间的推移集中精力。请始终寻找在缓解方法中使用自动化的机会，尽可能早。为了说明这种方法在实践中是什么样子，本示例显示了以人为本的触发器，以及基于策略的缓解在基本、中级和成熟级别上是什么样子。

除了使用架构行动手册和连续性计划之外，还要使用 Proactive Monitoring。通过 Proactive Monitoring，您可以设置对失败触发器的实时提醒，例如登录失败、CPU 超时异常或并发 API 请求错误。这种警报方法通过确保技术和业务利益相关者及时了解情况以减少故障的影响来增强故障缓解。

可用性的模式和反模式显示了 Salesforce 解决方案中正确和较差的故障缓解措施。在构建之前，使用它们来验证您的设计，或者确定要重构的系统的位置。

要了解有关适用于故障缓解的 Salesforce 工具的更多信息，请参见工具相关可靠。

此表显示了要在贵组织中查找或构建的模式选择，以及要避免或针对补救的反模式。

✨ 在模式和反模式探索器中，发现更多可用性模式。

系统架构性能是衡量系统处理量（吞吐量）和响应速度（延迟）的度量。您通常通过生产测试和监控了解系统的性能。

绩效系统会在每个预期的需求级别及时完成流程。

性能不佳与更高的延迟和更低的吞吐量并存，这将导致更低的生产力和更高的用户挫折感。修复性能问题迫在眉睫，因为它们会导致失去客户 Trust 和经济损失。

您可以通过优化吞吐量和延迟来提高解决方案的性能。

注意：吞吐量和延迟优化是改善系统处理和响应的基本方面。然而,重要的是要记住,整体系统性能还取决于您构建规模的能力。您必须在设计时考虑这两个维度。

在 Salesforce 架构的上下文中，吞吐量是系统在给定时间间隔内可以完成的并发请求的数量。专为吞吐量设计和优化的客户 Salesforce 解决方案在 Salesforce Platform 的内置调控器限制内运行得更好。

在 Salesforce 中优化吞吐量首先要准确计算系统中的工作负载，并规划其增长。如果没有对系统需求的准确预测，您就无法准确定位系统吞吐量的潜在问题。

在考虑工作量时，请考虑这三个维度。

• 系统必须在指定时间内处理的交易数量
• 必须同时访问系统的用户数量
• 系统中事务逻辑的总体复杂性

在考虑性能时，团队有时会过于狭隘地关注计算和对最大 CPU 时间的限制，这些是平台的调控器限制之一。专注于 CPU 时间的团队忽略了优化吞吐量的其他方法。扩展重点并应用这些方法可以提高 Salesforce 架构的整体吞吐量和效率。这些改进反过来将有助于减少延迟并提高整体系统性能。ApexGuru 会主动检测吞吐量限制的反模式，例如循环中的 SOQL、循环中的 DML、低效 GGD 调用和昂贵的方法。这些见解有助于团队消除限制吞吐量的调控器限制风险。

要优化系统中的吞吐量：

• 支持异步处理。Salesforce 平台使用事务上下文来控制数据完整性和限制失控代码。请参阅架构基础中的事务。因此，尽可能使用异步（异步）处理有助于最大限度地减少同步执行上下文中的潜在瓶颈。请参阅数据处理。使用异步计算并非解决每种性能问题的良药，您需要在合并异步进程时考虑延迟。某些平台功能，例如可排队 Apex，可能会在流量高峰期间增加延迟，因为它们会导致消息在队列中等待更长时间。根据您的用例，您可以决定容忍响应性的潜在下降，以保持或提高吞吐量。在其他情况下，您可能决定增加的延迟是不可接受的。通过扩展测试，您可以通过在完全 Sandbox 中模拟流量峰值来验证这些权衡。您可在此处测量作业如何影响吞吐量和延迟。
• 始终使用批量化。在高级别，批量化意味着对集合执行操作。通常，讨论 Salesforce 解决方案批量化的团队会重点关注针对集合简化数据操作。请参阅操作逻辑。但是，系统级别的批量化不仅仅涉及数据操作。还要考虑某些任务，例如标注或复杂计算，作为批量化的候选项。适当的批量化减少了开销。它执行多个操作，每个操作有一个请求，而不是一个请求。ApexGuru 在循环内显示 DML 或 SOQL 等反批量化模式，您可以在扩展到生产前修复它们。请参阅批量操作。
• **使用 SOSL 进行搜索，并将 SOQL 视为数据操作。**显然，使用过于复杂的 SOQL 语句会增加系统检索记录的时间。SOQL 增加了基础关系数据库的开销，降低了处理速度。在使用文本或通配符条件时，SOSL 的性能更好。SOSL 使用平台的搜索引擎，该引擎针对全文索引和通用搜索进行了优化。要优化记录检索模式，请确保您的设计标准指定何时使用 SOSL 在系统中查找数据。还要确保他们指定如何使用 SOQL 进行高效的数据操作。请参阅操作逻辑）。
• 使用平台缓存和 ApexGuru。Lightning 平台缓存层在缓存 Salesforce 会话和组织数据时提供了更快的性能和更好的可靠性。平台缓存通过分配缓存空间来提高性能，这样一些应用程序或操作就不会从其他应用程序或操作中窃取容量。ApexGuru 检测错过的缓存重复查询的机会（例如，平台缓存 SOQL 结果），从而提高了大规模环境中的吞吐量。

性能的模式和反模式显示了 Salesforce 组织中正确和较差的吞吐量。在构建之前，使用它们来验证您的设计，或者确定进一步优化的机会。

要了解有关适用于吞吐量优化的 Salesforce 工具的更多信息，请参阅适用于可靠性的 Salesforce 工具。

延迟是衡量系统完成执行路径的速度。优化系统的吞吐量将有助于改善延迟。延迟的另一个维度是感知的性能，或者系统对用户的反应。

人们不想等待页面加载或进程完成。如果用户在尝试导航列表视图、记录页面、报表等时经常遇到漫长的加载时间，系统用户会感到沮丧。当出现这种情况时，客户或合作伙伴可能会决定将他们的业务转移到其他地方，而不是处理性能不佳的系统。在内部，员工可能会创建解决方法来避免使用设计的系统，这可能会导致下游的安全性和数据完整性问题。

感知的性能很难诊断。当用户报告性能缓慢时，支持团队可能无法重现该问题。延迟的增加通常是相互依靠的较小问题的组合的结果，这可能会使诊断感知的性能问题的确切原因变得困难。

要减少 Salesforce 系统中的延迟并提高响应能力：

• 优化报表。确保每个报表服务于一个特定的目的。清楚地确定系统中每个报表的受众和目的。在报表中，仅包含受众成员决策所需的最少数据量。删除与报表目的不一致的列将通过减少需要检索和显示的数据量来提高报表性能。
• 优化筛选器。有效的筛选器通过准确确定从数据库中检索的行数来加快报表和列表视图的性能。一般来说，您制定的筛选器逻辑越具体，数据的基础查询就越有效。优化筛选器的方法包括：
  • 使用“等于”和“不等于”，而不是“包含”和“不包含”
  • 避免按公式字段筛选
• 简化共享模式。过于复杂的共享模型会使各种进程变慢，因为系统必须检查共享和可见性模型，以确定用户是否可以访问要显示或处理的数据。复杂的共享计算会增加在用户上下文中运行的报表、列表视图和自动化的延迟。请参阅共享和可见性。
• 优化自定义 UI 组件。自定义构建的用户界面 (UI) 组件会增加延迟。要优化自定义 UI 组件的性能，请考虑执行以下操作。
  • 使用 Lightning Web 组件 (LWC)。LWC 框架与现代 Web 标准紧密一致。使用 LWC 编写的自定义组件在 Web 浏览器中呈现效率更高，并使开发人员能够使用性能更高的 JavaScript 方法。始终致力于使用 LWC，而不是旧的 UI 技术，例如 Aura 或 Visualforce。
  • 使用 Lightning 数据服务。Lightning 数据服务处理跨组件的安全、高性能和共享缓存的创建和维护。使用它可以避免不必要的数据往返服务器，并提高整体应用程序响应。
  • **对列表数据使用客户端排序和筛选。**对于 LWC（首选）和 Aura 组件（否则），开发人员可以使用标准 JavaScript 数组功能在客户端排序、筛选和选择值，从而减少所需的服务器行程次数。

模式和反模式显示了 Salesforce 组织中正确和较差的延迟。在构建之前，使用它们来验证您的设计，或者确定进一步优化的机会。

要了解有关适用于延迟优化的 Salesforce 工具的更多信息，请参阅适用于可靠性的 Salesforce 工具。

此表显示了要在贵组织中查找或构建的模式选择，以及要避免或针对补救的反模式。

✨ 在模式和反模式探索器中探索更多性能模式。

可扩展性是系统在不断发展壮大时保持一致性能的能力。可扩展的系统可以处理大量增加的事务量或并发访问，而无需进行根本性的更改。Salesforce 的平台服务旨在支持应用程序的可扩展性。请参阅内部平台处理。话虽如此，随着贵组织的增长，对产品和服务的需求增加，您有责任创建一个可以如预期有效执行的系统。从一开始就为可扩展性构建架构可以更快地交付新功能，并随着用户流量的增加减少服务中断。在设计阶段早期,在将新功能部署到生产之前,使用扩展测试来模拟预计的工作量,并验证架构是否可以扩展以支持它们。

并非为可扩展性设计的系统需要不断进行昂贵的故障排除、重新设计和重构。可扩展性问题随着时间的推移而复杂化，降低了整个系统的性能。在某些情况下，企业发现自己将大部分开发和维护资源用于解决可扩展性问题，而不是用于创造价值的新功能。

有时，企业会达到临界临界点。其系统的原始设计无法支持业务的增长，意外事件使系统不稳定。使用规模中心的见解，尽早确定可扩展性临界点。规模中心显示了随着时间的推移而恶化的异常热点、长时间运行的事务和队列瓶颈。

通过关注数据模型优化和数据量管理，您可以更好地构建规模。

注意：虽然此处未讨论，但可扩展性测试是验证应用程序架构的关键部分。有关指导，请查看测试策略。

数据建模涉及构建贵组织中的对象，并将其相互关联，以使您的用户和自动化流程能够尽快检索到他们需要的数据。采取措施提高吞吐量可以解决许多性能问题，但是如果没有优化的数据模型，您的努力就不会那么有效。

设计不当的数据模型的负面影响不会立即明显；随着系统在数据量、流程、用户和集成方面的增长，它的弱点也会暴露出来。随着需求的添加和扩展，设计良好的数据模型可以更容易地持续重构您的应用程序。ApexGuru 显示了直接影响数据模型可扩展性的数据访问反模式，例如非选择性 SOQL、未使用的字段和模式的低效率。

要优化数据模型：

• **使用 Salesforce 中的预构建数据模型。**Salesforce 为销售、服务和各种行业垂直行业提供预构建的数据模型。使用 Salesforce 提供的数据模型可确保系统中的功能仅定义一次，消除冗余和孤岛，并在整个系统中建立单一的真实来源。因为您使用了该单一来源的 Salesforce 预构建数据模型，所以更容易使用 Analytics 理解应用程序数据，也更容易使用 Salesforce 的预构建人工智能服务。此外，减少您必须支持的自定义会降低维护成本并减少技术债务。
• 选择正确的数据类型。了解 Salesforce 支持的不同类型字段及其局限性。请考虑报告和加密要求，这样您就不必将来在类型之间转换数据。
• 选择正确的关系。Salesforce 支持对象之间的两种关系：主-详细信息和查找。主-详细信息关系提供两个主要好处。一个是内置的累计汇总功能，它统计和汇总子记录的详细信息。另一个是内置的级联删除功能，通过该功能，删除父记录也会删除其子记录。但在决定使用前，请确保您了解主-详细信息关系的共享和数据偏差。
• **为了规模而去标准化。**标准化是构建数据模型的过程，以减少数据冗余并提高数据完整性。遗憾的是，标准化有时会导致缩放问题。非标准化表在规模上表现更好，但请谨记考虑数据完整性和冗余性。

模式和反模式显示了 Salesforce 组织中正确和糟糕的数据模型优化。在构建之前，使用它们来验证您的设计，或者确定进一步优化的机会。

要了解有关适用于数据模型优化的 Salesforce 工具的更多信息，请参阅适用于可靠性的 Salesforce 工具。

数据量是根据记录计数和大小衡量存储在系统中的数据量。如果贵组织有数万名用户、数千万条记录或数百 GB 的记录总存储，则数据量很大。数据量和贵组织中的对象之间的关系会影响可扩展性，并且对可扩展性的影响可能大于仅记录数量的影响。

要提高具有大量数据的组织的可扩展性：

• 分发子记录。通过确保没有父级拥有大量子级记录，避免父子级数据偏差。一般建议是，任何父级记录的子记录都不应超过 10,000 个。例如，在具有多个联系人但未使用客户的部署中，请考虑设置多个客户记录并在其中分发相关联系人记录。
• 分配记录的所有权。通过确保没有单个用户或队列拥有，也没有单个角色或公用小组的所有成员拥有来自相同对象的超过 10,000 条记录，避免所有权偏差。使用“虚拟用户”“停放”数据是一种通常导致所有权倾斜的做法。如果您遇到此问题，请谨记其对共享计算的影响。如果您无法重新分配记录来缓解所有权偏差，请避免将数据拥有用户分配到角色。如果贵组织的共享模式需要角色分配，请将数据拥有用户放在共享层次结构顶部的不同角色中。请勿允许频繁或计划外更改该用户的角色。由于共享重新计算，任何更改都会对性能产生重大影响。将该用户排除在任何共享规则中可以引用的公用小组之外。
• 减少 Salesforce 中的记录数据量Salesforce 旨在向企业提供客户的单一视图。在 Salesforce 中限制数据是一种最佳实践，这似乎违反直觉。但是，单一视图的功能在于它使业务用户能够很好地理解客户数据并对其采取行动。随着数据量的增长，与日常流程或分析无关的最新数据会导致一些问题。这些问题包括应用程序性能下降、数据安全风险增加以及对搜索、报告和分析的负面影响。为避免此类问题，请为数据模型中的每个对象定义数据生命周期，并随着数据的老化和丧失即时业务价值，为其提供时间表和分类。根据数据生命周期，实施这些程序，随着时间的推移管理数据。
  • 数据归档和清除 - 要保持尽可能低的数据量，请删除业务不需要的记录，以帮助保持尽可能低的数据量。使用批量 API 2.0 的硬删除功能删除大量数据。
  • 数据聚合 - 创建聚合自定义对象，以兼容报表的格式汇总关键历史趋势或汇总数据。使用批量 Apex 填充自定义对象。然后，用户可以根据聚合的对象记录执行报表。
  • 数据分层。如果 Salesforce 报表或日常工作不需要大型数据集，请在不同的应用程序中维护它们。根据需要，通过混搭、标注或外部对象，使数据在 Salesforce 中可用。

实际上，您可能并不总是能够在出现问题时立即解决可扩展性问题的根本原因。因此，Salesforce 提供了帮助缓解当前痛点的选项。重要的是要知道，在贵组织中启用这些功能对于处理大量数据来说并不是一个可行的长期架构策略。这些短期的权宜之计有助于减少数据架构不佳的系统延迟，但它们也会给贵组织增加技术负担。

规模问题的短期解决方法包括：

• 自定义索引索引存储在平台查询优化器用来加速数据访问操作的特殊内部表中。请参阅多租户索引）。默认情况下，平台会自动索引特定类型的字段。要加速性能不佳的查询，您可以通过联系 Salesforce 客户支持来请求其他自定义索引。使用“查询计划”工具确定自定义索引是否会提高查询的性能。
• 瘦桌子如果您需要进一步优化对具有超过 100 万条记录的对象上的常见字段集的查询，瘦表可以提供帮助。瘦表格消除了在报表或自动化中使用同一对象中的自定义和标准字段时出现的后台连接。要使用瘦表格，Salesforce 客户支持必须为贵组织启用它们。

可扩展性的模式和反模式显示了 Salesforce 组织中正确和糟糕的数据量管理。在构建之前，使用它们来验证您的设计，或者确定进一步优化的机会。

要了解有关管理数据量的 Salesforce 工具的更多信息，请参阅Salesforce 可靠性工具。

这显示了在您的组织中寻找或构建的模式选择，以及避免或针对补救的反模式。

✨ 在模式和反模式探索器中，发现更多可扩展性模式。

帮助我们保持 Salesforce 架构合理与您相关；参加我们的调查，以提供有关此内容的反馈，并告诉我们您接下来想要看到的内容。