在 Force.com 平台上构建可扩展应用：多租户架构与执行限制深度解析

十一月 04, 2025

背景与应用场景

我是一名 Salesforce 架构师。在我的职业生涯中，我见证了无数企业利用 Force.com 平台（现在通常称为 Lightning Platform）以前所未有的速度构建和部署关键业务应用。Force.com 本质上是一个 PaaS (Platform as a Service/平台即服务)，它抽象了底层的硬件、操作系统和数据库，让开发者和管理员能够专注于业务逻辑的实现，而非基础设施的管理。

想象一个典型的场景：一家中型制造企业希望开发一个定制的供应商管理门户。传统方式下，他们需要采购服务器、安装数据库、搭建开发环境、编写大量后端代码来处理数据存储和安全。这个过程可能需要数月甚至更长时间。而借助 Force.com，他们可以直接利用平台提供的标准对象（如 Account、Contact）进行扩展，通过点击式配置创建数据模型、用户界面和业务流程，仅在必要时编写少量 Apex 代码。整个应用的开发周期可以缩短到几周。这正是 Force.com 的核心价值所在：速度、信任和规模。

作为架构师，我的职责不仅是设计解决方案，更是确保这些方案在平台上是健壮、可扩展且高效的。要做到这一点，就必须深刻理解 Force.com 的核心架构原理，其中最重要的两个概念便是：Multi-Tenancy (多租户) 和 Governor Limits (执行限制)。

原理说明

要构建一个摩天大楼，你必须了解它的地基和承重结构。同样，要在 Force.com 上构建企业级应用，我们必须深入理解其架构基石。

Multi-Tenancy (多租户) 架构

Force.com 的所有服务都运行在一个共享的、统一的基础设施上。这个模型被称为 Multi-Tenancy (多租户)。我们可以将其比作一栋公寓楼：

共享资源：整栋大楼共享地基、管道、电力系统和外部结构。这对应于 Salesforce 的单一应用程序服务器、数据库实例和底层硬件资源。所有客户（租户）共享这些资源。
独立单元：每个住户（租户）拥有自己独立、安全的公寓。他们无法访问邻居的房间，也无法看到邻居的物品。这对应于每个 Salesforce Org (组织)。平台通过在数据层面为每条记录附加一个唯一的 Organization ID 来确保严格的数据隔离。你查询的数据永远不会串到其他租户那里去。

这种架构带来了巨大的规模经济效应。Salesforce 只需维护一套核心代码库和基础设施，就可以服务于成千上万的客户。这也意味着平台升级可以无缝地推送给所有客户。但同时，为了保证“大楼”的稳定运行，防止某个“住户”过度用水用电而影响到其他人，平台必须建立一套严格的资源使用规则，这就是 Governor Limits。

Metadata-Driven Architecture (元数据驱动架构)

Force.com 的另一个核心是其元数据驱动架构。在平台上，你创建的几乎所有东西——对象、字段、页面布局、自动化规则，甚至 Apex 代码和 Visualforce 页面——都以元数据 (Metadata) 的形式存储在数据库中。元数据可以理解为“描述数据的数据”。

当用户访问一个 Salesforce 页面时，平台的应用服务器并不执行传统的编译后代码。相反，它会读取相关的元数据，然后动态地“渲染”出用户界面和应用程序逻辑。这种架构的优势是：

灵活性与敏捷性：修改应用通常只是修改元数据，这个过程非常快，使得 declarative (声明式，即点击式配置) 开发成为可能。
无缝升级：Salesforce 每年进行三次平台升级。因为你的定制化内容是元数据，所以平台可以升级底层的应用引擎，而不会破坏你的应用。你的定制元数据会被新版本的引擎正确解析和执行。

Governor Limits (执行限制)

Governor Limits 是多租户架构的直接产物。它们是一系列严格的运行时限制，用于确保任何一个租户的低效代码或进程不会垄断共享资源，从而影响其他租户的性能。作为架构师，设计解决方案时必须将这些限制刻在脑海里。常见的限制包括：

SOQL 查询限制：在单次交易 (Transaction) 中，SOQL 查询返回的总记录数不能超过 50,000 条。
DML 操作限制：在单次交易中，DML (Data Manipulation Language/数据操作语言) 语句（如 insert, update, delete）的执行次数不能超过 150 次。
CPU 时间限制：在单次交易中，所有 Apex 代码的累计执行时间不能超过 10,000 毫秒（同步）或 60,000 毫秒（异步）。
堆大小限制：在单次交易中，Apex 代码使用的内存不能超过 6MB（同步）或 12MB（异步）。

这些限制强制开发者和架构师编写高效、可扩展的代码，尤其是要遵循“Bulkification (批量化)”原则。

示例代码

为了说明 Governor Limits，特别是 DML 限制的重要性，让我们看一个典型的反模式（错误示例）及其正确的、批量化的实现方式。场景是：更新一组客户（Account）的描述字段。

错误示例：在循环中执行 DML

以下代码在 `for` 循环中执行 `update` 操作。如果 `accountsToUpdate` 列表包含超过 150 个客户，这段代码将立即触发 `System.LimitException` 错误，因为 DML 语句的执行次数超过了 150 次的限制。

// WARNING: This is an anti-pattern and should not be used.
// 警告：这是一个反模式，不应在实际项目中使用。
List<Account> accountsToUpdate = [SELECT Id FROM Account WHERE Name LIKE 'Test%'];

// This loop executes one DML statement (update) for each Account.
// If there are 200 accounts, this will make 200 DML calls, exceeding the limit of 150.
// 这个循环为每个客户执行一次 DML 语句。
// 如果有 200 个客户，将会执行 200 次 DML 调用，超出 150 次的限制。
for (Account acc : accountsToUpdate) {
    acc.Description = 'Updated via individual DML.';
    update acc; // DML statement inside a loop is a critical violation.
}

正确示例：批量化 (Bulkified) DML

正确的做法是创建一个记录列表，在循环中对列表中的元素进行修改，最后在循环外对整个列表执行一次 DML 操作。这样无论列表有多大（在其他限制范围内），DML 操作都只执行一次。

// BEST PRACTICE: Perform DML on a list of records.
// 最佳实践：对记录列表执行 DML 操作。
List<Account> accountsToUpdate = [SELECT Id FROM Account WHERE Name LIKE 'Test%'];
List<Account> updatedAccounts = new List<Account>();

// Iterate through the records and modify them in memory.
// Add the modified records to a new list.
// 遍历记录并在内存中修改它们。
// 将修改后的记录添加到一个新的列表中。
for (Account acc : accountsToUpdate) {
    acc.Description = 'Updated via bulk DML.';
    updatedAccounts.add(acc);
}

// Perform a single DML operation on the entire list of records.
// This consumes only 1 DML statement, regardless of the number of records.
// 对整个记录列表执行单次 DML 操作。
// 无论列表包含多少记录，这仅消耗 1 次 DML 语句。
if (!updatedAccounts.isEmpty()) {
    update updatedAccounts;
}

以上代码示例改编自 Salesforce Apex Developer Guide 中的最佳实践。这清晰地展示了架构设计时遵循 Governor Limits 的重要性。不遵循此原则的系统在数据量较小时可能正常工作，但随着业务增长，很快就会遇到性能瓶颈和致命的运行时错误。

注意事项

作为架构师，在 Force.com 上设计解决方案时，需要全面考虑以下几点：

权限与安全：Force.com 拥有一个非常成熟和强大的安全模型。所有 Apex 代码默认在系统模式 (System Mode) 下运行，通常会绕过用户的字段级安全和对象权限。但在设计时，必须考虑何时使用 `with sharing` 或 `without sharing` 关键字来强制执行或忽略用户的共享规则 (Sharing Rules)，以确保数据访问的合规性。永远不要在代码中硬编码敏感信息。
API 限制：与外部系统集成是常见需求。Salesforce 对 API 调用有严格的限制，通常是基于用户许可证类型和组织版本的滚动 24 小时限制。在设计集成架构时，必须评估 API 调用频率和数据量，选择合适的集成模式（如使用 Bulk API 处理大量数据），并设计缓存和重试机制。
错误处理：健壮的系统必须有完善的错误处理。特别是要预见到可能发生的 `LimitException`。使用 `try-catch` 块来捕获这些异常，并提供优雅的降级逻辑或向用户显示友好的错误信息。同时，利用平台日志和 Apex 异常邮件来监控和诊断问题。
大规模数据量 (Large Data Volumes - LDV)：当组织中的某个对象记录数超过数百万时，就进入了 LDV 的范畴。此时，糟糕的 SOQL 查询（非选择性查询）、数据倾斜 (Data Skew) 等问题都会被放大，导致性能急剧下降。架构师必须提前规划，设计合理的数据模型，为查询字段创建自定义索引 (Custom Indexes)，并优先使用异步处理（如 Batch Apex）来处理大规模数据。

总结与最佳实践

Force.com 是一个功能强大且高效的 PaaS 平台，但它的力量源于其独特的架构。作为 Salesforce 架构师，我们的成功取决于我们对这个架构的理解和尊重程度。以下是我在设计解决方案时始终遵循的最佳实践：

声明式优先，编码其次：在编写一行 Apex 代码之前，总是先考虑是否能通过 Flow、Validation Rule、Process Builder (已逐步被 Flow 取代) 等声明式工具实现。声明式工具由平台优化，更易于维护和升级。
时刻铭记批量化：所有代码，尤其是 Trigger (触发器)、Controller (控制器) 和批处理作业，都必须从第一天起就按照批量化原则进行设计。永远不要假设一次只会处理一条记录。
善用异步处理：对于耗时或资源密集型的操作，后果断地选择异步模式。理解 Future Methods、Queueable Apex、Batch Apex 和 Scheduled Apex 的适用场景和差异，并根据业务需求做出正确的技术选型。
数据模型是基石：一个设计良好、规范化的数据模型是高性能应用的基石。避免过度复杂的查找关系，合理使用主从关系 (Master-Detail) 和查找关系 (Lookup)，并提前规划数据归档策略。
持续学习与测试：Salesforce 平台在不断进化。架构师需要保持对平台新功能和限制变化的关注。同时，必须建立严格的测试文化，利用 Apex Test Classes 确保代码覆盖率，并模拟真实数据量进行性能和压力测试。

总之，在 Force.com 上进行架构设计，不仅仅是技术选型，更是一种在共享资源模型下，与平台规则共舞的艺术。只有深刻理解并遵循其核心原则，我们才能构建出真正能够随企业发展而扩展的、可靠且高效的应用程序。

Salesforce中文网