Salesforce Experience Cloud 架构设计：构建可扩展且安全的社区站点

背景与应用场景

在当今的数字化浪ICE中，企业与客户、合作伙伴以及员工的互动方式正在发生根本性的变革。Salesforce Experience Cloud（前身为 Community Cloud）作为 Salesforce 平台的核心组成部分，提供了一个强大的框架，用于快速构建、品牌化和部署安全的在线空间。这些空间，我们通常称之为社区站点 (Community Sites)，不仅仅是简单的门户网站，更是连接企业内外部生态系统、促进协作、提升服务效率和驱动业务增长的关键数字接触点。

作为一名 Salesforce 架构师 (Salesforce Architect)，我关注的不仅仅是功能的实现，更是整个解决方案的健壮性、可扩展性、安全性和长期可维护性。一个成功的 Experience Cloud 站点需要一个深思熟虑的架构设计作为基石。无论应用场景是用于 B2C 客户服务的自助服务门户、用于 B2B 合作伙伴进行交易和协作的渠道站点，还是用于连接特定兴趣群体的品牌社区，其底层的架构决策都将直接影响最终的用户体验和业务价值。

本篇文章将从架构师的视角，深入探讨构建 Experience Cloud 站点时必须考虑的核心架构原则、关键决策点以及最佳实践，旨在帮助您设计出一个既能满足当前需求，又能适应未来发展的卓越数字体验平台。

---

原理说明

从架构层面看，Experience Cloud 并非一个独立的产品，而是深度集成于 Salesforce 核心平台之上的一层应用。它复用了 Salesforce 强大的后端能力，包括数据模型、安全模型、自动化流程以及 Apex/LWC 开发框架。理解其核心架构原理是做出正确设计决策的前提。

1. 身份与许可模型 (Identity and Licensing Model)

这是 Experience Cloud 架构设计的起点和基石。用户的身份决定了他们是谁，而许可证则决定了他们能做什么以及他们能访问哪些数据。不同的许可证类型（如 Customer Community, Customer Community Plus, Partner Community, External Apps 等）提供了截然不同的功能集、对象访问权限和价格模型。作为架构师，必须在项目初期就与业务方明确社区用户的画像和需求，选择最合适的许可证。例如，Customer Community 许可证适用于大量用户需要访问知识库 (Knowledge) 和案例 (Case) 的场景，而 Partner Community 许可证则为合作伙伴提供了更深入的对象访问权限，如销售机会 (Opportunities) 和潜在客户 (Leads)。

2. 外部共享模型 (External Sharing Model)

Salesforce 拥有一个非常成熟和强大的内部数据共享模型。然而，当数据需要暴露给外部用户（社区用户）时，安全和可见性变得尤为复杂和重要。Experience Cloud 引入了一套专门为外部用户设计的共享机制。

• 组织范围默认设置 (Organization-Wide Defaults): 针对外部用户的 OWD 设置是独立于内部用户的，通常需要设置为“私有 (Private)”，遵循最小权限原则 (Principle of Least Privilege)。
• 共享集 (Sharing Sets): 这是针对 Customer Community 和其他大批量门户许可证用户的核心共享工具。它基于用户和记录之间的直接或间接查找关系（如用户的联系人记录关联到某个客户客户，该用户便能看到该客户下的所有案例），来授予记录的访问权限。
• 共享组 (Share Groups): 允许您与大量拥有相同许可证的外部用户共享由 Apex Managed Sharing 创建的共享记录。这为程序化共享提供了更高的性能。
• 角色与超级用户 (Roles and Super User): 对于 Customer Community Plus 和 Partner Community 许可证，可以启用基于角色的共享。合作伙伴社区用户可以被分配到客户客户下的特定角色（最多三个层级），从而实现垂直访问。超级用户访问权限 (Super User Access) 更是允许指定的用户访问其在客户角色层次结构中同级或下级用户所拥有的数据。

3. 认证与授权 (Authentication and Authorization)

如何安全、便捷地让用户登录社区是提升用户体验的关键。架构师需要设计合理的认证方案。

• 标准登录: 用户名密码。
• 单点登录 (Single Sign-On, SSO): 与企业现有的身份提供商 (IdP) 集成，如 Azure AD, Okta 等，使用 SAML 或 OpenID Connect 协议。
• 社交登录 (Social Sign-On): 允许用户使用他们的 Google, Facebook, LinkedIn 等社交账号登录。
• 无密码登录 (Passwordless Login): 通过邮件或短信发送验证码的方式登录。

认证之后是授权，即通过简档 (Profiles) 和权限集 (Permission Sets) 精确控制用户对对象、字段、Apex 类和页面的访问权限。

4. 自定义与扩展性 (Customization and Extensibility)

Experience Cloud 提供了从低代码到专业代码的多种定制方式。架构上需要决定何时使用何种工具。

• Experience Builder: 使用标准或自定义组件，通过拖拽方式构建页面布局和品牌化。
• Salesforce Flows: 用于构建复杂的业务流程和向导，减少对代码的依赖。
• Lightning Web Components (LWC): 现代、高性能、标准化的前端开发框架，是构建自定义用户体验的首选。
• Aura Components: 遗留框架，在新项目中应优先考虑 LWC。
• Apex: 后端逻辑的核心，用于处理复杂的数据操作、集成和业务规则。所有暴露给外部用户的 Apex 控制器都必须经过严格的安全审查。

---

示例代码

在为 Experience Cloud 站点编写后端 Apex 代码时，安全是第一要务，尤其是处理访客用户（未登录用户）的数据请求时。访客用户在后台以一个特殊的 Guest User 身份运行。为了保护数据安全，所有针对访客用户的 Apex 代码都必须以 `with sharing` 方式执行，以强制执行共享规则。下面的代码示例来自 Salesforce 官方文档，展示了一个为访客用户提供服务的安全 Apex 控制器。

// GuestUserController.cls
// This class must be declared as 'with sharing' to enforce sharing rules for guest users.
public with sharing class GuestUserController {

    // The @AuraEnabled annotation makes this method accessible to Lightning components (Aura or LWC).
    // The 'cacheable=true' attribute improves performance by caching the results on the client.
    @AuraEnabled(cacheable=true)
    public static List<Contact> getContacts(Id accountId) {
        // We must validate the input parameter to prevent SOQL injection or unauthorized data access.
        // Here, we ensure the accountId is not null.
        if (accountId == null) {
            // Throwing a specific AuraHandledException provides a clear error message to the front end.
            throw new AuraHandledException('Account ID cannot be null.');
        }

        // The SOQL query is crafted to be secure.
        // 1. It uses 'WITH SECURITY_ENFORCED' to enforce field-level security and object permissions for the running user (the guest user).
        //    If the guest user profile doesn't have access to these fields, the query will fail, preventing data leakage.
        // 2. The 'WHERE' clause filters contacts based on the provided accountId, ensuring only relevant data is returned.
        try {
            return [
                SELECT Id, Name, Title, Phone, Email
                FROM Contact
                WHERE AccountId = :accountId
                WITH SECURITY_ENFORCED
                ORDER BY Name
                LIMIT 10
            ];
        } catch (System.QueryException e) {
            // It's crucial to catch potential exceptions, such as those thrown by WITH SECURITY_ENFORCED,
            // and handle them gracefully. Logging the error is a best practice.
            System.debug(LoggingLevel.ERROR, 'An error occurred while querying contacts for a guest user: ' + e.getMessage());
            // It's better to return an empty list or throw a generic error than to expose system details.
            throw new AuraHandledException('An error occurred while retrieving contact information. Please contact support.');
        }
    }
}

代码注释解析：

• `public with sharing class GuestUserController`: 这是最重要的架构和安全决策。`with sharing` 关键字强制 Apex 代码遵循当前用户的共享规则。对于访客用户，这意味着他们只能看到通过“访客用户共享规则”明确共享给他们的记录。如果使用 `without sharing`，代码将以系统权限运行，可能会绕过共享设置，导致严重的数据泄露。
• `@AuraEnabled(cacheable=true)`: 声明此方法可以被前端 LWC 或 Aura 组件调用。`cacheable=true` 对只读操作至关重要，它可以极大提升站点的性能和可扩展性，减轻服务器负载。
• `WITH SECURITY_ENFORCED`: 这是在 SOQL 查询中强制执行字段级安全 (Field-Level Security) 和对象权限的现代方法。如果访客用户简档没有对 `Contact` 对象的 `Name`, `Title` 等字段的读取权限，查询将抛出异常，而不是静默地返回部分数据。
• `try-catch` 块: 完善的错误处理是健壮架构的一部分。捕获潜在的查询异常，并向前端返回一个用户友好的错误信息，同时在后端记录详细的错误日志，是生产级代码的标准。

---

注意事项

在设计和实施 Experience Cloud 站点时，架构师必须时刻警惕以下几个关键领域：

1. 权限和安全 (Permissions and Security):
   • 访客用户安全：Salesforce 近年来极大加强了对访客用户的安全限制。确保访客用户的简档权限最小化，关闭“查看所有用户”权限，并使用新的“访客用户共享规则”来专门授予记录访问权限。
   • 外部用户 OWD：始终将外部用户的 OWD 设置为私有，然后通过共享规则、共享集等方式逐步开放权限。避免过度共享。
   • Apex 安全：所有暴露给外部用户的 Apex 类都应进行严格的代码审查，检查 SOQL 注入、权限绕过等漏洞，并默认使用 `with sharing`。
2. API 限制和性能 (API Limits and Performance):
   • 用户数量与性能：大量社区用户会消耗 API 调用、存储空间和其他系统资源。设计时需要考虑用户增长，确保 Apex 代码、SOQL 查询和 Flows 的效率。
   • 页面加载时间：优化 LWC 组件，使用客户端缓存 (`cacheable=true`)，压缩图片，并利用 Salesforce CDN 来提升全球用户的访问速度。避免在单个页面上放置过多的组件或进行过多的服务器调用。
3. 数据量 (Data Volume):
   • 如果社区用户需要访问大量数据（例如数百万条案例或自定义对象记录），必须仔细设计数据架构和查询策略。
   • 考虑使用索引来优化查询性能，并避免在查询条件中使用非确定性公式字段。对于大数据量的场景，可能需要考虑使用数据归档策略或外部对象 (External Objects)。
4. 集成 (Integrations):
   • 社区站点经常需要与第三方系统集成。作为架构师，需要选择合适的集成模式（如 REST/SOAP API, Platform Events, MuleSoft）。
   • 确保所有集成调用都经过认证，并考虑到 API 调用限制。使用命名凭据 (Named Credentials) 来安全地管理端点和认证信息。

---

总结与最佳实践

成功构建一个 Salesforce Experience Cloud 站点，是一项融合了业务理解、技术深度和安全意识的系统工程。作为 Salesforce 架构师，我们的职责是超越具体的功能点，从宏观层面规划一个可持续、可扩展且安全的蓝图。

核心最佳实践总结：

• 安全第一 (Security First): 始终以最小权限原则为指导，尤其是在设计外部用户的数据访问模型时。将安全嵌入到设计的每一个环节，而不是事后弥补。
• 许可证规划先行 (License Planning Upfront): 在项目启动阶段就彻底搞清楚用户类型和需求，选择正确的许可证组合。这是一个影响深远的架构决策，后期更改成本极高。
• 拥抱声明式工具 (Embrace Declarative Tools): 优先使用 Experience Builder, Flows 和共享规则等声明式工具。只有在声明式工具无法满足复杂需求时，才诉诸于 LWC 和 Apex 开发。
• 性能设计 (Design for Performance): 从第一天起就考虑性能。优化数据模型，编写高效的查询，并充分利用平台提供的缓存机制。
• 治理与文档 (Governance and Documentation): 建立清晰的开发和部署流程。详细记录架构决策，包括为什么选择某种许可证、为什么设计这样的共享模型等，这将为未来的维护和迭代提供宝贵的依据。

最终，一个卓越的 Experience Cloud 站点架构，不仅能够满足今天的业务需求，更能像一个坚固的平台一样，支撑企业在未来数字化的道路上不断创新和演进。