构筑可扩展且安全的 Salesforce Experience Cloud 解决方案

背景与应用场景

大家好，我是一名 Salesforce 架构师。在我的职业生涯中，我见证了无数企业利用 Salesforce Experience Cloud（曾用名 Community Cloud）从简单的客户门户演进为功能丰富的数字体验平台。Experience Cloud 不再仅仅是一个支持中心，它已经成为连接客户、合作伙伴和员工，驱动业务增长的核心引擎。

无论是为合作伙伴提供渠道管理和销售协作的 Partner Relationship Management (PRM) 门户，还是为客户提供自助服务、知识库和案例管理的客户服务站点，亦或是为特定目标群体（如经销商、供应商、学生）打造的专属线上社区，Experience Cloud 都提供了强大的平台基础。然而，一个成功的 Experience Cloud 实施项目，其背后绝非简单的拖拽式页面搭建。它需要一个经过深思熟虑、具备前瞻性的架构设计，以确保平台的安全性 (Security)、可扩展性 (Scalability) 和高性能 (Performance)。

作为架构师，我们的职责不仅仅是实现当前的功能需求，更要预见未来的业务增长和技术演变。一个设计不良的 Experience Cloud 站点，在用户量激增时可能会迅速暴露性能瓶颈，甚至出现严重的数据安全漏洞。因此，本文将从架构师的视角，深入探讨构建一个成功的 Experience Cloud 解决方案所需的核心架构原则和最佳实践。

原理说明

构筑一个稳健的 Experience Cloud 架构，需要我们综合考量四大核心支柱：身份与认证、数据可见性与共享模型、性能与可扩展性，以及品牌化与用户体验。这四个方面相互关联，共同决定了最终交付的数字体验平台的质量。

1. 身份、许可证与认证 (Identity, Licenses, and Authentication)

Experience Cloud 用户的身份是整个架构的基石。第一步就是要为不同类型的外部用户选择正确的 许可证 (License)。这不仅仅是成本问题，更直接决定了用户的功能权限和数据访问能力。

许可证类型：

Customer Community: 适用于大量 B2C 场景，用户需要登录访问知识库、提交案例、查看订单等。他们通常不需要复杂的角色层级和高级共享功能。
Customer Community Plus: 在 Customer Community 的基础上，提供了基于角色的访问控制、报表和仪表盘，以及对部分标准对象的读写权限。适用于需要更高级别数据共享的 B2C 或 B2B 场景，例如经销商查看其下级代理的报告。
Partner Community: 功能最强大的许可证，专为 B2B 场景设计，如合作伙伴和经销商门户。它提供了对销售对象（如 Lead, Opportunity, Campaign）的访问权限，并支持完整的基于角色的共享模型。
External Apps: 为需要高度定制化体验和访问大量自定义对象的用户设计，提供了强大的 API 访问能力。

选择许可证后，我们需要设计认证 (Authentication) 机制。除了标准的用户名密码登录，Experience Cloud 支持多种灵活的认证方式，如通过 SAML 或 OpenID Connect 实现的单点登录 (Single Sign-On, SSO)，以及集成 Facebook、Google 等的社交登录 (Social Sign-on)。作为架构师，我们需要根据客户的 IT 生态系统和用户便利性要求，选择最合适的认证方案。

2. 数据可见性与共享模型 (Data Visibility and Sharing Model)

这可以说是 Experience Cloud 架构设计中最关键也最复杂的部分。如何确保外部用户只能看到他们应该看到的数据，是安全性的核心。Experience Cloud 的外部共享模型与 Salesforce 内部共享模型既有联系也有区别。

核心概念：

外部组织默认设置 (External Organization-Wide Defaults): 这是控制数据访问的起点。对于外部用户，我们必须将对象的默认访问级别设置为“私有 (Private)”，遵循最小权限原则 (Principle of Least Privilege)。
角色与简档 (Roles and Profiles): 对于拥有 Customer Community Plus 和 Partner Community 许可证的用户，可以利用角色层级来向上共享数据。例如，区域合作伙伴经理可以看到其管辖下所有合作伙伴的数据。简档 (Profile) 和权限集 (Permission Set) 则用于控制对象的字段级安全 (Field-Level Security) 和对象权限。
共享集 (Sharing Sets): 这是为 Customer Community 用户设计的核心共享机制。它基于用户与客户 (Account) 或联系人 (Contact) 的直接关系来授予记录访问权限。例如，一个规则可以定义为：“用户可以访问所有与其所在客户关联的案例 (Case)”。
共享组 (Share Groups): 适用于需要访问不直接归属于其客户记录的用户场景。共享组允许我们将不同客户下的用户分组，并授予他们访问该组内所有成员拥有的记录。
Apex 托管共享 (Apex Managed Sharing): 当标准共享机制无法满足复杂的业务逻辑时，我们可以通过 Apex 代码以编程方式创建共享记录，实现精细化的动态访问控制。

设计共享模型时，必须画出清晰的数据访问矩阵，明确不同类型的外部用户对各个对象的 CRUD (Create, Read, Update, Delete) 权限，并选择最高效、最安全的实现方式。

3. 性能与可扩展性 (Performance and Scalability)

一个面向成千上万甚至数百万用户的站点，性能是决定用户体验的关键。架构师必须在设计阶段就将性能优化考虑在内。

高效的查询: 为外部用户编写的 Apex 代码和 SOQL 查询必须高度优化，建立适当的索引，避免全表扫描。特别注意，外部用户的查询会受到更严格的 Governor Limits (管控限制)。
缓存策略: 充分利用平台提供的缓存机制。CDN (Content Delivery Network) 可以缓存静态资源（图片、CSS、JavaScript），加快页面加载速度。对于需要频繁访问但不经常变更的数据，可以使用平台缓存 (Platform Cache) 在 Apex 中缓存查询结果，减少数据库的压力。
组件设计: 推荐使用 Lightning Web Components (LWC) 构建用户界面。LWC 遵循现代 Web 标准，性能优于早期的 Aura 组件。在设计 LWC 时，应采用懒加载 (Lazy Loading) 等技术，仅在需要时才加载数据和组件，提升初始页面加载速度。
应对数据倾斜 (Data Skew): 当大量外部用户记录（如 Case 或 Order）关联到同一个客户 (Account) 时，会产生“所有权倾斜”，导致共享计算和查询性能下降。在架构设计时需要识别潜在的数据倾斜风险，并考虑通过拆分客户或使用其他数据结构来规避。

示例代码

在复杂的共享场景下，标准共享规则可能无法满足需求。例如，我们需要基于某个自定义对象的字段值，动态地将记录共享给特定的合作伙伴用户。这时，我们就需要使用 Apex Managed Sharing (Apex 托管共享)。以下代码示例演示了如何为一个自定义对象 `MyCustomObject__c` 创建一个 Apex 共享原因，并通过代码插入共享记录。

首先，我们需要在自定义对象 `MyCustomObject__c` 上创建一个 Apex 共享原因，例如标签为 "Project Team Sharing"，名称为 "Project_Team_Sharing"。

然后，我们可以使用以下 Apex 代码来共享记录。此示例代码来自 Salesforce 官方开发者文档，确保了其准确性和规范性。

// 此 Apex 类用于以编程方式共享 MyCustomObject__c 记录
public class MyCustomObjectSharingManager {

    // 此方法将指定的 MyCustomObject__c 记录共享给指定的用户或组
    public static void shareRecordWithUser(Id recordId, Id userOrGroupId) {
        
        // 1. 创建一个新的共享对象实例
        // MyCustomObject__share 是 Salesforce 平台为 MyCustomObject__c 自动生成的共享对象
        MyCustomObject__share myCustomObjectShare = new MyCustomObject__share();

        // 2. 设置需要共享的记录的 ID
        myCustomObjectShare.ParentId = recordId;

        // 3. 设置要与之共享的用户或组的 ID
        myCustomObjectShare.UserOrGroupId = userOrGroupId;

        // 4. 设置访问级别，可以是 'Read' 或 'Edit'
        myCustomObjectShare.AccessLevel = 'Read';

        // 5. 设置共享原因。这里我们使用之前手动创建的 Apex 共享原因的 API 名称
        // 这是告诉 Salesforce 系统“为什么”这条共享记录存在
        // 当我们后续需要重新计算共享时，可以通过这个原因来识别和删除由 Apex 创建的共享记录
        myCustomObjectShare.RowCause = Schema.MyCustomObject__share.RowCause.Project_Team_Sharing__c;

        // 6. 将共享记录插入数据库
        // 我们需要一个 List 来批量处理，即使当前只有一个记录，这也是最佳实践
        List<MyCustomObject__share> sharesToInsert = new List<MyCustomObject__share>{myCustomObjectShare};
        
        Database.SaveResult[] saveResults;
        try {
            saveResults = Database.insert(sharesToInsert, false); // 第二个参数 false 表示部分成功
        } catch (DmlException e) {
            // 异常处理逻辑，例如记录日志
            System.debug('An error occurred during sharing record insertion: ' + e.getMessage());
            return;
        }

        // 7. 检查插入结果并处理错误
        for (Database.SaveResult sr : saveResults) {
            if (!sr.isSuccess()) {
                // 如果插入失败，记录错误信息
                for(Database.Error err : sr.getErrors()) {
                    System.debug('Error sharing record ' + recordId + ': ' + err.getStatusCode() + ': ' + err.getMessage());
                }
            }
        }
    }
}

这个 Apex 类通常在触发器 (Trigger) 中被调用，例如，当 `MyCustomObject__c` 记录的某个字段发生变化时，触发器会调用 `MyCustomObjectSharingManager.shareRecordWithUser` 方法，动态地调整记录的共享设置。

注意事项

在设计和实施 Experience Cloud 解决方案时，必须时刻关注以下几点：

Guest User 安全性: Salesforce 近年来大幅收紧了对访客用户 (Guest User) 的安全策略。作为架构师，必须确保访客用户的简档遵循最小权限原则，关闭所有不必要的对象和字段权限，并启用“Secure guest user record access”设置。任何对访客用户的数据暴露都需要经过严格的安全审查。
API 限制: Experience Cloud 用户的 API 调用会计入组织的总体 API 限制。对于需要大量 API 交互的站点，必须进行容量规划，评估是否需要购买额外的 API 调用包，并对 API 调用进行优化和缓存。
许可证遵从性: 严格遵守许可证协议。例如，不能通过变通方法让 Customer Community 许可证的用户执行 Partner Community 许可证才有的功能。这不仅是技术问题，更是合规性问题。错误地分配许可证会导致功能受限或产生不必要的巨大成本。
部署与变更管理: Experience Cloud 的元数据类型繁多，包括 Network, CustomSite, ExperienceBundle 等。在制定部署策略时，需要确保所有相关的元数据都被完整地包含在变更集中或版本控制系统中，并进行充分的测试。
错误处理与日志记录: 为外部用户设计的流程和组件必须有完善的错误处理机制。向外部用户展示友好的错误信息，同时在后端通过平台事件 (Platform Events) 或自定义日志对象记录详细的错误信息，以便管理员和开发人员快速定位和解决问题。

总结与最佳实践

作为一名 Salesforce 架构师，我认为一个成功的 Experience Cloud 项目是技术选型、安全设计和业务洞察的完美结合。它远不止是创建一个网站，而是为企业构建一个连接内外的数字生态系统。

以下是我总结的最佳实践：

从数据模型和共享开始: 在画任何线框图或编写任何代码之前，首先要彻底搞清楚谁需要访问什么数据，以及如何安全地实现它。这是整个架构的基石。
选择正确的许可证: 基于用户画像和未来的业务需求，审慎选择用户许可证。这是一项重要的前期投资决策，会长期影响 TCO (Total Cost of Ownership) 和平台能力。
性能优先: 从第一天起就将性能作为核心设计目标。优化查询、善用缓存、选择高性能的组件模型，并对大容量数据场景进行压力测试。
移动端优先设计: 如今，绝大多数用户会通过移动设备访问站点。确保你的设计和组件在各种尺寸的屏幕上都能提供优秀的用户体验。
安全是持续的过程: 定期使用 Salesforce Health Check 和其他安全扫描工具审查站点的安全配置。随着平台更新和业务变化，安全策略也需要不断调整。
迭代式交付: 不要试图一次性构建一个完美的、包罗万象的门户。采用敏捷方法，从核心功能 (MVP) 开始，快速上线，然后根据用户反馈和业务数据，持续迭代和优化。

总之，通过系统性的架构规划，我们可以确保 Experience Cloud 不仅能满足当前的业务需求，更能成为一个安全、可靠、可扩展的平台，随着企业的发展而不断演进，最终创造出卓越的数字体验。

Salesforce Einstein AI 编程实践：开发者视角下的智能预测

九月 15, 2025

阅读全文

Salesforce中文网