--- schema_version: "1" id: dc1fae782fa0d704d0a625e08153d10454a92736f65e1f169d2c71c3b9723e03 title: 架构良好的框架 collection: architect version: current locale: zh-cn portal_url: https://docs.salesforce.com/architect/current/zh-cn/well-architected/guides/framework.md canonical_url: https://architect.salesforce.com/docs/architect/zh-cn/well-architected/guide/framework.html source_site: architect.salesforce.com content_type: documentation content_hash: 0c8d668d491f511cf1a1540d72d07518f79a935eb6b9afd0810d120800d4698c products: - 架构良好的框架 - Architect Site Content Repo --- # 架构良好的框架 Salesforce 良好架构框架为架构师提供了共同的原则性基础，以做出有助于解决方案随着时间的推移取得成功的决策。它围绕五个支柱进行组织 — Trust、可靠性、卓越运营、资源和成本优化以及公平性 — 每个支柱都涵盖了从初始设计到长期运营和发展的解决方案生命周期的每个阶段中都很重要的质量维度。 该框架解决了架构师今天面临的现实问题：在受管业务系统中一起工作的人员、客服人员和平台。一个安全但在负载下易碎的解决方案，或者一个高效但在决策上不透明的解决方案，其架构并不好。这五个支柱相互协作,确保将质量作为一个整体对待,而不是作为一份独立关切的核对清单。 在设计审查、权衡对话和持续治理期间，架构师将框架用作一致的镜头。它没有规定一个正确答案。它为您提供了正确的问题、正确的模式和跨团队使用的常用词汇。 | [查看变更日志](/docs/architect/zh-cn/well-architected/guide/change-log.html)，以查看架构中心文档的最近更新。 | | :---- | ## 什么是架构良好的框架 Salesforce 良好架构框架是构建于 Salesforce 平台的解决方案的架构质量的意见指南。它编纂了原则、模式和权衡，将按比例调整的解决方案与累积技术债务或迫于压力而失败的解决方案区分开来。 该框架围绕五个支柱组织。每个支柱都定义了质量维度，阐明了核心设计原则，确定了共同的模式，并为传统平台功能和客服人员 AI 工作负载提供了明确的指导。这些支柱共同全面地涵盖了在 Salesforce 上构建良好内容的含义。 此框架不是产品手册或实施指南。它是一个架构决策框架 - 一种考虑质量的方式，无论解决方案使用哪些云、功能或工具，它都适用。 ## Salesforce 为何需要自己的框架 来自超大规模云提供商的行业框架提供了有价值的一般指导，但它们主要是针对云基础设施和运营问题构建的，例如虚拟机、网络、存储和计算。Salesforce 架构师面临不同的限制和功能：具有调控器限制的多租户平台、Customer 360 中数十年的业务逻辑、复杂的集成解决方案、声明自动化、元数据驱动的配置和受管共享模型。这些以通用云指导无法解决的方式塑造了每个架构决策。 转向自主客服人员会引入更多注意事项。推理和行动的客服人员引入了非确定性、概率推理和人类在环监督模式，而早期框架最初没有涉及这些模式，尽管通用框架已经开始通过专用的 AI 镜头扩展到这一领域。Salesforce 架构良好的框架通过统一的镜头解决了传统平台架构和客服人员系统的问题。 ## 谁应该使用此框架 此框架为 Salesforce 平台上负责架构质量的任何人提供服务： - 设计新解决方案或扩展现有解决方案的 **Salesforce Architects** - **Salesforce 管理员**配置和保护运行这些解决方案的组织 - **开发主管**为其团队建立标准和模式 - **顾问和合作伙伴**就平台最佳实践向客户提供建议 - **AI 和客服人员**专家构建和管理自主客服人员系统 无需此前在客服人员 AI 方面的专业知识。所有架构师都可以访问该框架，同时为从事自治系统前沿工作的人员提供了深度。 ## 如何使用此框架 ### 读取顺序 没有单一的正确读取顺序。根据您的角色和即时需求选择： - **如果您是该框架的新用户：**请仔细阅读此概览文档，然后探索与当前项目最相关的支柱。 - **如果您正在设计新解决方案：**从 Trust 和可靠性开始(不容商榷的基础 ) , 然后解决卓越运营(您将如何操作它 ) 、 资源和成本优化(您将如何维护它)以及公平性(您将如何确保它公平地为所有用户服务 ) 。 - **如果您正在构建代理解决方案：**请先阅读[客服人员企业概览](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise.html)，了解全面的客服人员架构指导。然后，阅读基础模式的核心支柱文档（上文链接），这些基础模式是客服人员解决方案所基于的分担责任模型、调控器限制、监控工具、TCO 建模、可访问性标准。最后，参考客服人员企业支柱变体（从每个支柱链接），了解每个质量维度上特定于客服人员的叠加。 - **如果您正在进行设计审查：**将支柱文档用作结构化审查核对清单。架构良好的解决方案对每个相关支柱中的关键问题都有明确的答案。 ### 将框架应用于权衡决策 最重要的架构决策涉及支柱之间的权衡。该框架帮助您明确这些： - **Trust与资源和成本优化:**加密和审计日志记录会消耗资源。该框架帮助您确定 Trust 要求在哪里是不容置疑的，哪里是您有灵活性的。 - **可靠性与资源和成本优化：**可用性越高，成本越高。SLO 定义帮助您将投资与实际业务需求相匹配，而不是默认设置为最大冗余。 - **卓越运营与速度：**全面的可观察性和测试需要时间来实施。该框架帮助您确定风险简档的最低可行可观察性。 - **公平与自主：**更大的客服人员自主权提高了效率，但产生了公平风险。以人为本的模式有助于您找到每种决策类型的正确平衡。 这些权衡没有普遍的答案。该框架帮助您提出正确的问题，并有意识地做出权衡，而不是在生产中发现它们。 ## 框架原则 架构良好的框架本身在设计时考虑了这些原则： - **特定于平台但与技术无关：**指导解决了特定于 Salesforce 的约束（管理者限制、多租户架构、元数据驱动的配置），而没有规定特定的产品或功能。架构师为其上下文选择正确的功能。 - **不带规范性的意见：**该框架对什么是质量采取了明确的立场,但没有规定单一的实施路径。它提供原则、模式和问题，而不是要求。 - **尊重现在的同时向前看：**该框架解决了新出现的模式（智能 AI、自主系统），同时与传统的平台解决方案仍然相关。这两个用例都受益于相同的基本原则。 - **生活，不是静态的：**该框架会随着平台、行业实践和客户需求的变化而变化。变更日志会跟踪更新，以便架构师了解最新指导。 - **在每个阶段均可操作：**无论您是设计新解决方案、进行审查还是改进现有实施，该框架都会提供相关指导。它不仅仅是一个认证核对清单，它还是一个有效工具。 这些原则确保框架在各种架构上下文中仍然有用，同时对架构质量对 Salesforce 解决方案的意义保持清晰一致的指导。 ## 五大支柱 每个支柱都涉及建筑质量的基本层面。这些支柱共同提供了全面的覆盖范围 - 没有任何一个支柱本身是足够的，而支柱之间的权衡是最重要的架构决策所在。 ### 框架支柱和客服人员企业：协同工作 以下 5 个支柱为**所有** Salesforce 解决方案提供了基本的架构指导 — 传统平台应用程序、集成和客服人员系统。[客服人员企业概览](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise.html)及其伴随的支柱变体提供了特定于客服人员的叠加：客服人员如何构建这些功能，系统自主运行时会发生什么变化，以及受管 AI 所需的架构模式。 **一起使用：** - 从核心架构模式的支柱指导开始（例如，分担责任模型、调控器限制、监控工具、TCO 建模、可访问性标准）。 - 然后，参考相应的客服人员企业支柱，了解客服人员特定的注意事项（例如，客服人员权限和审计链、编排失败处理、客服人员开发生命周期、令牌优化、客服人员工作单位、可解释性和可竞争性）。 支柱不是“传统”与“代理”，而是代理解决方案所基于的基础架构。代理系统必须满足与任何其他企业解决方案相同的 Trust、可靠性、卓越运营、资源和成本优化以及公平性要求，并包含自主操作的其他注意事项。 此表提供了快速参考。以下是每个支柱的详细指导。 | 支柱 | 它解决了什么问题 | 客服人员角度 | | :---- | :---- | :---- | | [信任](/docs/architect/zh-cn/well-architected/guide/trust.html) | 安全、访问、隐私、治理 | 管理客服人员可以执行的操作并审核他们执行的操作 | | [可靠性](/docs/architect/zh-cn/well-architected/guide/reliability.html) | 可用性、恢复、可扩展性 | 处理非确定性、编排失败和客服人员可中断性 | | [卓越运营](/docs/architect/zh-cn/well-architected/guide/operational-excellence.html) | 可观察性、DevOps、自动化 | 观察概率系统和管理客服人员开发生命周期 | | [资源和成本优化](/docs/architect/zh-cn/well-architected/guide/resource-and-cost-optimization.html) | 效率、性能、成本、价值 | 令牌经济性、内存检索和基于消耗的客服人员工作成本 | | [公平](/docs/architect/zh-cn/well-architected/guide/fairness.html) | 可访问性、透明度、监督 | 可解释性、可竞争性和公平的客服人员驱动体验、偏见 | ### Trust 通过现代安全性、最低权限访问、隐私控制和明确治理，保护您的解决方案、数据和用户。Salesforce 上的 Trust 通过**分担责任模型**:运作Salesforce 保护基础设施和平台，然后在此基础上构建安全的解决方案。您的职责范围： - 身份和访问权限管理（角色、简档、权限集、MFA、SSO、OAuth） - 数据治理（Shield Platform Encryption、对象/字段/记录级安全性） - 集成安全性（API 身份验证、命名凭据） - 安全开发实践（适用于 Salesforce、静态分析、CI/CD 安全门的 [OWASP 十大](https://owasp.org/www-project-top-ten/)标准） **对于客服人员解决方案：**在客服人员自主操作时，Trust 要求会扩展到管理允许客服人员执行的操作、审核他们执行的操作以及保护客服人员到平台的边界（客服人员结构、Einstein Trust 层）。见[Agentic Enterprise Trust](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-trust.html)。 要了解更多信息,请参阅[Trust](/docs/architect/zh-cn/well-architected/guide/trust.html)支柱和[Agentic Enterprise Trust](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-trust.html)。 ### 可靠性 设计用于持续可用性、从中断中快速恢复以及根据意外需求进行扩展的能力。可靠性要求了解平台保证（多区域基础设施、平台 SLA），同时设计在这些约束下保持可靠的解决方案。支柱涵盖： - 具有 70% 操作上限指导的调控器限制 - 异步处理模式（批处理 Apex、可排队 Apex、平台事件） - 用于外部集成的断路器 - 容量规划 - 负载测试 - 多组织模式 - 灾难恢复 - 健康建模 **对于客服人员解决方案：**客服人员驱动的系统引入了概率行为，需要新模式来处理编排故障，需要断路器来处理级联客服人员错误，还需要确定性客服人员图来处理业务结果需要可预测性的问题。请参阅[代理企业可靠性](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-reliability.html)。 要了解更多信息，请查看[可靠性](/docs/architect/zh-cn/well-architected/guide/reliability.html)支柱和[代理企业可靠性](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-reliability.html) ### 卓越运营 将全面的可观察性构建到您的解决方案中，并通过定义明确的程序和自动化来管理它。卓越运营跨越： - 可观察性（事件监控、Proactive Monitoring、比例中心） - DevOps 实践（源驱动的开发、CI/CD 漏斗、测试策略） - 自动化（使用 Flow Builder 声明优先，使用 Apex 编程模式） - 事件管理（严重级别、随叫随到的轮换、无可指责的事后分析） - 持续改进（DORA 度量、运营审查） **对于客服人员解决方案：**当系统行为是概率性的时，可观察性变得更加困难。客服人员开发生命周期 (ADLC) 通过五个阶段提供结构：意见和设计、开发、测试和验证（包括客服人员测试中心对准确性、一致性和指令遵守情况的评估）、部署和发布，以及监控和调整（包括 Agentforce 会话跟踪，以实现端到端的交互可见性）。请参阅[代理企业运营卓越](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-operational-excellence.html)性。 要了解更多信息，请查看[卓越运营](/docs/architect/zh-cn/well-architected/guide/operational-excellence.html)支柱和[卓越代理企业](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-operational-excellence.html)。 ### 资源和成本优化 通过有效利用您拥有的资源，并有意投资于您购买的资源，为每一美元和每一单位平台资源带来最大的业务价值。在资源方面，这意味着要了解调控器限制（SOQL 查询、DML 语句、堆大小、CPU 时间），并通过 SOQL 优化、异步处理和防止数据偏差在它们中进行设计。在成本方面，这意味着对直接成本（实施、运营、维护）和间接成本（技术债务、治理开销）进行全面的 TCO 建模，这些成本通常超过直接许可证成本。支柱涵盖： - 代码组织模式（触发器处理程序、服务层、选择器） - 封装和模块化（受管 2GP 与解锁软件包，两者都是第二代封装类型，LWC 组成） - 数据生命周期管理（归档策略、流优化） - 性能监控工具（规模中心、查询计划工具、ApexGuru、Salesforce 代码分析器） - 构建与购买分析（AgentExchange 评估） - 许可证和 Sandbox 优化 - 成本监控和治理（仪表板、预算控制、显示与按存储容量使用计费模型） **对于客服人员解决方案：**客服人员工作流增加了推理步骤、工具调用和数据检索的资源消耗，因此需要优化令牌使用、推理延迟和内存模式。代理系统还引入了基于消耗的成本（灵活信用、推理令牌），这比每个用户许可更难预测。客服人员工作单位 (AWU) 衡量客服人员实际完成的工作（完成的离散任务），而不是原始令牌消耗。请参阅[代理企业资源和成本优化](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-resource-and-cost-optimization.html)。 要了解更多信息，请参阅[资源和成本优化](/docs/architect/zh-cn/well-architected/guide/resource-and-cost-optimization.html)支柱和[代理企业资源和成本](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-resource-and-cost-optimization.html)优化。 ### 公平性 确保您的解决方案是可访问的、非歧视性的、包容性的和透明的，并对自动化决策进行适当的人为监督。公平建立在平台基础上。Salesforce Lightning 设计系统(SLDS)为标准组件提供内置的可访问性,而自定义组件需要明确的WCAG 2.1 AA实施(对于[WCAG 2.2 AA](https://www.w3.org/TR/WCAG22/),即截至2024年12月的当前W3C建议,建议进行新的工作)。支柱涵盖： - 可访问性测试（轴心、sfdx 扫描仪） - 不歧视模式（OWD、共享规则、带有 Shield Event Monitoring 的 FLS） - 隐私架构（Data 360 同意管理、字段审计跟踪） - AI 道德治理（审查委员会、公平大门、监管合规）。 **对于客服人员解决方案：**当客服人员做出影响人员的自主决策时，公平性风险会增加。可解释性（了解客服人员的行为原因）、可争议性（具有挑战性的决策）和人与人（按比例监督）变得至关重要。请参阅[代理企业公平](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-fairness.html)性。 要了解更多信息，请查看[公平](/docs/architect/zh-cn/well-architected/guide/fairness.html)支柱和[代理企业公平](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-fairness.html)。 ## 支柱如何相互作用 没有孤立的支柱。一个支柱中的架构决策不可避免地会影响其他支柱： - 更强的 Trust 控制(加密、审计日志记录)会消耗更多资源，增加成本(资源和成本优化),并增加影响可靠性的延迟 - 更高的可靠性（冗余、多区域）增加了成本（资源和成本优化）和运营复杂性（卓越运营） - 更全面的公平性执行（人工监督、偏见监控）会降低客服人员的吞吐量（资源和成本优化） - 更高的运营卓越性成熟度(全面的仪器)可以更好地执行 Trust 和更早地检测公平性问题 这些交互意味着建筑质量始终是一种平衡。该框架帮助架构师了解他们正在交易的内容，并有意进行这些交易。目标不是同时最大化每个支柱，而是为给定解决方案的要求、风险容忍和业务上下文实现正确的质量简档。

分享您对良好架构框架的反馈。