---
schema_version: "1"
id: 2324d7b68460ff6e8bd661d31699da182b9b9633b3b23f4e8910a5215e6efc5d
title: 架构基础
collection: architect
version: next
locale: zh-cn
portal_url: https://docs.salesforce.com/architect/next/zh-cn/fundamentals/guides/architecture-basics.md
canonical_url: https://staging.architect.salesforce.com/docs/architect/zh-cn/fundamentals/guide/architecture-basics.html
source_site: staging.architect.salesforce.com
content_type: documentation
content_hash: 68b9005793e01d4912c73f88effa7780acdd5f7dae55645e2cf5920a9c05d79f
products:
  - 基本知识
  - Architect Site Content Repo
updated_at: 2022-08-01T00:00:00Z
---
## 导言

Salesforce Customer 360 平台向每个单独的 Salesforce 租户实例(也称为 " 组织 " )提供了强大的[元数据驱动架构](/docs/architect/zh-cn/fundamentals/guide/platform-multitenant-architecture)。本架构基本文档概述了 Salesforce Platform 的基础架构为构建于该平台的解决方案架构创建重要注意事项的领域。

在 Salesforce 平台上设计架构时，有三个重要方面需要了解：

- [交易](/docs/architect/zh-cn/fundamentals/guide/architecture-basics#交易)
- [元数据与数据](/docs/architect/zh-cn/fundamentals/guide/architecture-basics#元数据与数据)
- [平台 API](/docs/architect/zh-cn/fundamentals/guide/architecture-basics#平台-api)

## 交易

在 Salesforce 平台上，事务可以通过代码执行和/或数据库操作来实例化。在 Salesforce 上构建架构的基本能力是了解平台如何定义和控制租户的交易。为了维护所有租户的资源，Salesforce 对每个租户强加了限制，根据每个事务和组织进行计算。

在事务级别，Salesforce 设置[调控和执行限制](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm)，以确保代码执行的单个实例和数据库事务不会独占共享计算资源。在组织范围内，Salesforce 会根据[版本和功能类型](https://help.salesforce.com/s/articleView?id=sf.overview_limits_general.htm&type=5)设置限制。组织范围的限制还包括对组织中所有事务的 API 使用情况进行滚动计算，这些事务受 [API 限制](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_api.htm)。

让我们更仔细地看看 Salesforce 平台上事务的两个关键部分：执行上下文和数据库操纵。

### 执行上下文

Salesforce 根据[执行上下文](https://trailhead.salesforce.com/content/learn/modules/apex_basics_dotnet/execution_context)的概念计算事务限制。重要的是要了解，对于 Salesforce 应用程序，这不仅限于在单个 Salesforce 组织中执行自定义代码。执行上下文基于平台运行时引擎，以及特定租户的运行时引擎可用的所有代码。这意味着租户组织中定义的自定义代码、与该组织一起安装的软件包中的代码以及 Salesforce Platform 服务中包含的代码都可以实例化事务。该平台确实区分了不同类型的 Apex 代码，并根据这些区分计算调控器限制。

有关[Apex 交易限制](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm)的更多信息，请参阅 Apex 开发人员指南。

### 数据库操作

当事务涉及数据库操纵时，内置[执行顺序](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm)规定了贵组织配置和代码的不同部分的行为方式。了解如何在 Salesforce 应用程序中正确使用执行顺序的关键是了解此行为为您的 Salesforce 应用程序提供的强大的数据完整性。

<a href="/view/MCOOL7W3TDDVFZZGSTXP7SLSI6NI" target="_blank">
    <image style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" src="https://architect.salesforce.com/ns-assets/legacy/salesforce-order-of-execution-diagram.png" alt="Salesforce Order of Execution Diagram">
</a>

该平台以[触发上下文变量](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm)的形式公开数据库操作状态的上下文变量。重要的是要了解，这些触发器上下文变量描述了 Salesforce 组织中所有数据库事务的运行时状态，而不论自定义 Apex 触发器是否已在该组织中定义。它们可用于声明性工具，例如 Salesforce Flow。

在 Salesforce 中，直到成功完成按执行顺序描述的最终触发*后*行为后，数据才会提交(数据事务也不会完成)。这意味着数据事务期间在上下文*之前*或*之后*出现的任何致命错误或不合格行为都将导致平台回滚事务中的所有数据操作。对记录数据的请求更改不会提交到数据库，也不会执行提交后逻辑。(Apex 的确公开了[数据库方法](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_transaction_control.htm),以便对保存点和回滚行为进行更精细的控制。 )

在 Salesforce 架构中要避免的一个关键反模式是尝试快捷方式或取代平台的内置执行行为顺序。

要深入了解这些内置数据完整性行为背后的逻辑，请参见[内部和外部：Salesforce 工程博客中的交易](https://engineering.salesforce.com/inside-and-out-transactions-b9535faa5924)。

## 元数据与数据

在选择如何在 Salesforce 组织中自定义和扩展时，重要的是从 Salesforce 平台的角度了解哪些内容将被视为数据，哪些内容将被视为元数据。有关深入了解此数据/元数据区别背后的基础架构，请参阅[平台多租户架构](/docs/architect/zh-cn/fundamentals/guide/platform-multitenant-architecture#平台数据层)基础文档。

这种区别将影响应用程序的开发生命周期的许多方面，例如：工件是否将被复制到 [Sandbox 开发环境](https://help.salesforce.com/s/articleView?id=sf.create_test_instance.htm&type=5)中，它如何迁移到其他环境，它是否可以是[软件包](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/sharing_apps.htm)的一部分。

下表提供了数据与元数据性能的快速比较，因为它与应用程序生命周期的关键部分相关：

<table>
    <tbody>
        <tr>
            <th scope="colgroup" colspan="1">行为</th>
            <th scope="colgroup" colspan="1">数据</th>
            <th scope="colgroup" colspan="1">元数据</th>
        </tr>
        <tr>
            <td>从生产复制到 Sandbox 环境</td>
            <td>否*</td>
            <td>是</td>
        </tr>
        <tr>
            <td>按元数据 API 迁移</td>
            <td>没有</td>
            <td>是**</td>
        </tr>
        <tr>
            <td>按数据加载迁移</td>
            <td>是</td>
            <td>没有</td>
        </tr>
        <tr>
            <td>可以包含在软件包中</td>
            <td>没有</td>
            <td>是**</td>
        </tr>
        <tr>
            <td>根据数据存储限制计数</td>
            <td>是</td>
            <td>没有</td>
        </tr>
        <tr>
         <td colspan="3">*完全复制和部分复制 Sandbox 允许从生产中复制数据。<br/>**一些元数据类型不适用于元数据 API 和/或软件包。您可以在<a href=https://developer.salesforce.com/docs/metadata-coverage>元数据范围报表</a>中找到异常。</td>
        </tr>
    </tbody>
</table>

有时，这种区别相当明显。例如，Salesforce 组织中的单个记录是数据。组织中的各种 [sObject](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_SObjects.htm) 都是元数据。

在组织配置功能方面，区别可能更加复杂。一个关键的示例是[自定义设置](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_customsettings.htm)与[自定义元数据类型](https://help.salesforce.com/s/articleView?id=sf.custommetadatatypes_about.htm&type=5)。这两个功能都允许您在组织中配置信息，以便在运行时轻松获得，并且能够以类似于数据库记录的方式操作和管理。这两个功能都旨在允许代码和自动化中松散耦合、高度灵活的设计模式。但自定义设置会作为数据存储在组织中，自定义元数据类型会作为元数据存储。

您可以通过查看某个内容是否出现在[元数据范围报表](https://developer.salesforce.com/docs/metadata-coverage)中来确定它是否是元数据。此报表还将告诉您特定元数据类型的关键开发和部署行为。

## 平台 API

有许多 [Salesforce 平台 API](https://help.salesforce.com/s/articleView?id=sf.integrate_what_is_api.htm&type=5)。Salesforce 平台 API 支持不同的数据格式和协议、各种操作类型和时间。一些 API 允许您与 Salesforce 组织中的数据交互，而其他 API 支持与给定组织中元数据的交互。一些 API 专为处理[大量事务](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_intro.htm)而构建，其他 API 则不是。Salesforce 会在每个版本中更新*所有* Salesforce Platform API 的版本号。

正确应用程序架构的关键部分是确保应用程序开发人员为给定的用例[使用正确的 API](https://help.salesforce.com/s/articleView?id=sf.integrate_what_is_api.htm&type=5)（和 API 版本）。您需要考虑 Salesforce 组织的内置 [API 限制](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_api.htm)，其中许多限制由版本和功能激活决定。Salesforce 平台 API 支持向[后兼容](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_support_policy.htm)的使用，这意味着即使发布新的 API 版本，特定版本的实施也应保持稳定和一致性。如果您想从新的 API 版本合并新的或更改的功能，您可能需要在升级对新的 API 版本的引用之前重构您的应用程序。

许多不同的 Salesforce 平台 API，以及 Salesforce API 版本的速度，大大增加了使用 Salesforce API 的任何应用程序的生命周期的复杂性。您需要计划定期评估应用程序中的 Salesforce Platform API 引用，并确定计划的 API 维护周期的优先级，以保持应用程序可预测地正常运行。
