Salesforce平台多租户架构

　　原文英文链接：
　　https://architect.salesforce.com/fundamentals/platform-multitenant-architecture
　　每天，成千上万的企业和数百万用户使用由 Salesforce 平台支持的应用程序在云中运营他们的业务。平台为何如此成功？为什么您可以信任它来支持您的业务？该平台为像您这样的企业提供了哪些独特的好处？
　　本技术简介解释了 Salesforce 平台如何使用其独特的云计算软件架构来提供可靠、可扩展且易于定制的最终用户体验。阅读本简报后，您将更好地了解使 Salesforce 平台成为您的业务应用程序引人注目的选择的底层技术。平台概述
　　Salesforce 平台是成功的云计算平台和相关应用生态系统的杰出范例。自千年之交以来，该平台一直是以下方面的支持基础：许多流行 的商业用途应用程序，用于常见用例，例如销售和客户服务 针对金融和医疗保健等更专业用例的 行业特定应用程序针对独特用例的数百万个 自定义应用程序和应用程序扩展
　　在很大程度上，Salesforce 平台之所以如此成功和受欢迎，是因为其独特的软件架构支持易于构建、使用、定制和扩展的应用程序，具有卓越的性能和可靠性。该平台软件架构的核心是其多租户、元数据驱动的设计。
　　Salesforce 平台的软件架构是：多租户 ——它隔离并同时支持许多 租户 （组织、业务单位等）的不同需求。 元数据驱动——它允许每个租户使用元 数据、描述用户界面 (UI) 和业务逻辑等元素的数据轻松快速地自定义他们的应用程序和用户体验。
　　当您使用 Salesforce 平台创建新应用程序对象或编写一些代码时，平台不会在数据库中创建实际表或编译任何代码。相反，平台只是存储一些元数据，然后它可以在运行时使用这些元数据来动态实现虚拟应用程序组件。该平台确保每个租户的元数据都是私有的并且易于更新，无需任何锁定或停机时间，因此每个租户都可以单独构建和自定义应用程序。Salesforce 平台使用相同的元数据来提供自定义 API、RESTful 和 Web 服务（基于 SOAP）接口，您可以使用这些接口将您的应用程序与其他应用程序和自动化流程集成。
　　AppExchange中也提供现成的解决方案，该平台的广阔应用市场。AppExchange 包由受信任的合作伙伴和独立软件供应商 (ISV) 组成的庞大生态系统构建，是来自第三方的元数据，它描述了免费或付费的应用程序扩展和整个应用程序，您可以使用它们来满足特定的业务需求。
　　为了支持这种高度可定制和可扩展的架构，Salesforce 平台的单个实例使用：具有存储租户特定元数据和数据的单个架构的单个共享 多租户数据库。 一个 多租户内核 （应用程序运行时），它读取元数据和数据，以便在运行时为每个租户的用户动态提供特定于租户的应用程序、业务逻辑和 API。
　　Salesforce 管理的内核与租户管理的元数据的这种明确分离使得 Salesforce、租户和 ISV 可以独立地发展他们的系统部分而不受干扰。
　　在此概述的基础上，本文的后续部分提供了有关平台独特功能的更多详细信息，这些功能源于其设计的关键方面，包括：平台数据层 平台应用开发 内部平台处理 平台基础设施 平台数据层
　　Salesforce 平台的应用程序运行时和创新的数据层一起安全地隔离了特定于租户的数据、模式自定义和业务逻辑。在较高级别上，模式支持各种用例：当您创建或自定义应用程序时，平台会将相关元数据存储在共享数据库表中，这些表维护所有租户的元数据。 当您使用应用程序读取或写入数据时，平台会将您的数据存储在共享数据库表中，这些表维护所有租户的数据。 在幕后，该平台还在许多表中维护内部元数据，内核使用这些表来优化运行时的请求延迟。
　　但是单个共享数据库和模式如何使每个租户的数据保持私密呢？平台上的每个租户都称为一个组织，或简称为org。共享数据库表中的每个组织特定记录都有一个OrgID。当内核访问数据库时，它使用这个唯一标识符来确保每个组织的活动都是私有的。
　　元数据
　　特定于组织的对象（想想传统关系数据库用语中的表）、字段、存储过程、数据库触发器等都是由平台存储在称为通用数据字典 (UDD)的几个数据库表中的元数据描述的虚拟构造。MT_Objects 是一个数据库表，用于存储有关您为应用程序定义的对象的元数据，包括对象的唯一标识符 (ObjID)、您的组织 (OrgID) 以及您为对象指定的名称 (ObjName)。 MT_Fields 系统表存储有关您为每个对象声明的字段（列）的元数据，包括字段的唯一标识符 (FieldID)、您的组织 (OrgID)、包含该字段的对象 (ObjID)、名称字段 (FieldName)、字段的数据类型、指示字段是否需要索引的布尔值 (IsIndexed)，以及字段在对象中相对于其他字段的位置 (FieldNum)。
　　由于元数据是关键要素，平台必须优化对元数据的访问；否则，频繁的元数据访问会阻止服务扩展。考虑到这个潜在的瓶颈，该平台使用大量复杂的元数据缓存来维护内存中最近使用的元数据，避免降低性能的磁盘 I/O 和代码重新编译，并提高应用程序响应时间。数据
　　MT_Data系统表存储映射到所有组织特定表及其字段的应用程序可访问数据，由 MT_Objects 和 MT_Fields 中的元数据定义。每行包括标识字段，例如全局唯一标识符 (GUID)、拥有该行的组织 (OrgID) 和包含对象标识符 (ObjID)。MT_Data 表中的每一行还有一个 Name 字段，用于存储相应记录的＂自然名称＂；例如，客户记录可能使用＂客户名称＂，案例记录可能使用＂案例编号＂，等等。
　　Value0 ... ValueN弹性列，也称为槽，存储应用程序数据，这些数据分别映射到 MT_Objects 和 MT_Fields 中声明的表和字段。所有 flex 列都使用可变长度的字符串数据类型，以便它们可以存储任何结构化类型的应用程序数据（字符串、数字、日期等）。如下图所示，同一个对象的两个字段不能映射到MT_Data中的同一个slot进行存储；但是，一个槽可以管理多个字段的信息，只要每个字段来自不同的对象。
　　MT_Fields 可以使用多种标准结构化数据类型中的任何一种，例如文本、数字、日期和日期/时间，以及特殊用途、结构丰富的数据类型，例如选择列表（枚举字段）、自动编号（自动递增、系统生成的序列号）、公式（只读派生值）、主从关系（外键）、复选框（布尔值）、电子邮件、URL 等。MT_Fields 也可以是必需的（不为空）并具有自定义验证规则（例如，一个字段必须大于另一个字段），这两者都是平台强制执行的。
　　当您声明或修改对象时，平台会管理定义该对象的 MT_Objects 中的一行元数据。同样，对于每个字段，平台管理 MT_Fields 中的一行，包括将字段映射到 MT_Data 中特定弹性列的元数据，以存储相应的字段数据。由于平台将对象和字段定义作为元数据而不是实际的数据库结构进行管理，因此系统可以容忍在线多租户应用程序模式维护活动，而不会阻塞其他组织和用户的并发活动。相比之下，传统关系数据库系统的在线表重定义通常需要临时锁，而且通常需要费力、复杂的流程和计划的应用程序停机时间。
　　如上图中 MT_Data 的简化表示所示，弹性列是一种通用数据类型（可变长度字符串），这使得平台可以在使用各种结构化数据类型（字符串、数字）的多个字段之间共享一个弹性列、日期等）。
　　该平台使用规范格式存储所有弹性列数据，并在应用程序从弹性列读取数据和向弹性列写入数据时根据需要使用底层数据库系统数据类型转换函数（例如，TO_NUMBER、TO_DATE、TO_CHAR）。
　　MT_Data 还包含上图中未显示的列。例如，有四列用于管理审计数据，包括哪个用户创建了一行以及创建该行的时间，以及哪个用户上次修改了一行以及上次修改该行的时间。MT_Data 还包含一个IsDeleted列，平台使用该列来指示何时删除了行。
　　该平台还支持将字段声明为字符大对象 (CLOB)，以允许存储最多 32,000 个字符的长文本字段。对于 MT_Data 中具有 CLOB 的每一行，平台将 CLOB 存储在名为MT_Clob的表中，系统可以根据需要将其与 MT_Data 中的相应行连接。
　　注意：该平台还在数据库外部以索引形式存储 CLOB，以便进行快速文本搜索。 有关平台的文本搜索引擎的更多信息，请参阅搜索。索引
　　该平台自动索引各种类型的字段以提供可扩展的性能。
　　传统数据库系统依靠原生数据库索引来快速定位数据库表中具有匹配特定条件的字段的特定行。但是，为 MT_Data 的 flex 列创建本地数据库索引是不切实际的，因为该平台使用单个 flex 列来存储具有不同结构化数据类型的许多字段的数据。相反，平台通过将标记为索引的字段数据同步复制到MT_Indexes数据透视表中的适当列来管理 MT_Data 的索引。
　　MT_Indexes 包含强类型索引列，例如 StringValue、NumValue 和 DateValue，平台使用这些列来定位相应数据类型的字段数据。例如，平台会将 MT_Data flex 列中的字符串值复制到 MT_Indexes 中的 StringValue 字段，将日期值复制到 DateValue 字段等等。MT_Indexes 的基础索引是标准的、非唯一的数据库索引。当内部系统查询包含引用对象中结构化字段的搜索参数时，平台的自定义查询优化器使用 MT_Indexes 帮助优化关联的数据访问操作。
　　注意：该平台可以处理跨多种语言的搜索，因为系统使用大小写折叠算法将字符串值转换为通用的、不区分大小写的格式。MT_Indexes 表的 StringValue 列以这种格式存储字符串值。在运行时，查询优化器会自动构建数据访问操作，以便优化的 SQL 语句过滤相应的大小写折叠的 StringValue，这反过来又对应于搜索请求中提供的文字。
　　该平台允许您指示对象中的字段何时必须包含唯一值（区分大小写或不区分大小写）。考虑到 MT_Data 的排列和字段数据的 Value 列的共享使用，为对象创建唯一的数据库索引是不切实际的。（这种情况类似于上一节中讨论的非唯一索引。）
　　为了支持自定义字段的唯一性，平台使用 MT_Unique_Indexes 数据透视表；此表与 MT_Indexes 表非常相似，不同之处在于 MT_Unique_Indexes 的底层本机数据库索引强制唯一性。当应用程序尝试将重复值插入需要唯一性的字段中，或者管理员尝试对包含重复值的现有字段强制执行唯一性时，平台会向应用程序返回适当的错误消息。
　　在极少数情况下，平台的外部搜索引擎（在搜索中解释）可能会变得超载或不可用，并且可能无法及时响应搜索请求。该平台没有向最终用户返回令人失望的错误，而是退回到辅助搜索机制以提供合理的搜索结果。
　　后备搜索被实现为具有引用目标记录的名称字段的搜索条件的直接数据库查询。为了优化全局对象搜索（跨表的搜索）而不必执行可能代价高昂的联合查询，平台维护了一个MT_Fallback_Indexes数据透视表，该表记录了所有记录的名称。MT_Fallback_Indexes 的更新在事务修改记录时同步发生，因此后备搜索始终可以访问最新的数据库信息。
　　MT_Name_Denorm表是一个精益数据表，它存储了MT_Data中每条记录的 ObjID 和 Name。当应用程序需要提供涉及父/子关系的记录列表时，平台使用 MT_Name_Denorm 表执行一个相对简单的查询，该查询检索每个引用记录的名称以显示在应用程序中，例如作为超链接。关系
　　该平台提供了关系数据类型，组织可以使用这些数据类型来声明表之间的关系（参照完整性）。当你用关系类型声明一个对象的字段时，平台将该字段映射到MT_Data中的一个Value字段，然后使用该字段来存储相关对象的ObjID。
　　为了优化连接操作，平台维护了一个MT_Relationships数据透视表。此系统表有两个底层数据库唯一复合索引，允许在必要时在任一方向上进行有效的对象遍历。领域历史
　　只需点击几下鼠标，该平台就可以为任何领域提供历史跟踪。当组织启用对特定字段的审计时，系统使用内部数据透视表作为审计跟踪异步记录有关对该字段所做更改的信息（旧值和新值、更改日期等）。数据分区
　　所有平台数据、元数据和数据透视表结构，包括底层数据库索引，都由 OrgID 使用本地数据库分区机制进行物理分区。数据分区是数据库系统提供的一种经过验证的技术，用于将大型逻辑数据结构物理划分为更小、更易于管理的部分。分区还有助于提高大型数据库系统（例如多租户环境）的性能、可伸缩性和可用性。根据定义，每个平台查询都针对特定组织的信息，因此查询优化器只需要考虑访问包含组织数据的数据分区，而不是整个表或索引。这种常见的优化有时被称为＂分区修剪＂。平台应用开发
　　本节介绍应用程序开发人员如何创建架构的底层元数据，然后构建管理数据的应用程序。该元数据和数据存储在上一节中描述的平台数据层中。基于浏览器、无代码和低代码的应用程序开发
　　开发者可以使用平台的基于浏览器的开发环境以声明方式构建服务器端应用组件，通常称为平台Setup屏幕。安装程序的点击式 UI 支持应用程序架构构建过程的所有方面，例如创建应用程序的数据模型（包括对象及其字段以及关系）、安全和共享模型（包括用户、配置文件和角色层次结构）、用户界面（包括屏幕布局、数据输入表单和报告）、声明性逻辑（工作流）和编程逻辑（存储过程和触发器）。例如，Salesforce Flow 可以轻松实现各种用例的自动化。Setup 的 Flow Builder UI（如下所示）允许您以图形方式设计和实施与用户交互的工作流，或根据计划自动启动或在由事件触发时启动。
　　设置屏幕使任何人都可以轻松地开发和自定义应用程序，而无需（或很少）代码。例如：平台原生 UI 无需任何代码即可轻松构建。在幕后，原生应用程序 UI 支持所有常见的数据访问操作，包括查询、插入、更新和删除。本机平台应用程序执行的每个数据操作操作一次可以修改一个对象，并在单独的事务中自动提交每个更改。 在为包含敏感数据的对象定义文本字段时，您可以轻松配置该字段，以便平台加密相应的数据，并且可以选择使用输入掩码来隐藏屏幕信息以防窥探。 声明性 验证规则 是组织无需任何编程即可强制执行域完整性规则的一种简单方法。例如，您可以声明一个验证规则，以确保 LineItem 对象的 Quantity 字段始终大于零。 公式字段 是平台的一项声明性功能，可以轻松地将计算字段添加到对象。例如，您可以向 LineItem 对象添加一个字段来计算 LineTotal 值。 汇总汇总字段 是一个跨对象字段，可以轻松聚合父对象中的子字段信息。例如，您可以基于 LineItem 对象的 LineTotal 字段在 SalesOrder 对象中创建 OrderTotal 汇总字段。
　　注意：在内部，平台使用本地数据库功能实现公式和汇总汇总字段，并作为正在进行的事务的一部分同步有效地重新计算值。APIs
　　该平台提供了几个开放的、基于标准的 API，开发人员可以使用这些 API 来构建应用程序。RESTful 和 Web 服务（基于 SOAP）API都提供对平台许多功能的访问。使用这些不同的 API，应用程序可以：操作描述应用程序模式的元数据 创建、读取、更新和删除 (CRUD) 业务数据 异步批量加载或查询大量记录 以安全且可扩展的方式公开近乎实时的数据流 查询语言
　　应用程序可以使用Salesforce 对象查询语言 (SOQL)来构建简单但功能强大的数据库查询。与结构化查询语言 (SQL) 中的 SELECT 命令类似，SOQL 使您能够指定源对象、要检索的字段列表以及在源对象中选择行的条件。例如，以下 SOQL 查询返回名称等于字符串＂Acme＂的所有客户记录的 Id 和 Name 字段的值。
　　SELECT Id, Name FROM Account WHERE Name = ＂Acme＂
　　该平台还包括一个全文、多语言搜索引擎，可自动索引所有与文本相关的字段。应用程序可以通过使用Salesforce 对象搜索语言 (SOSL)来执行文本搜索，从而利用这个预集成的搜索引擎。与一次只能查询一个对象的 SOQL 不同，SOSL 使您能够同时搜索多个对象的文本、电子邮件和电话字段。例如，以下 SOSL 语句在 Lead 和 Contact 对象中搜索名称字段中包含字符串＂Joe Smith＂的记录，并从找到的每条记录中返回姓名和电话号码字段。
　　FIND {＂Joe Smith＂} IN Name Fields RETURNING lead(name, phone), contact(name, phone)  Apex 和 Pro-Code 应用程序开发
　　Apex在许多方面与 Java 相似，是一种功能强大的开发语言，开发人员可以使用它在其应用程序模式中集中过程逻辑。Apex 代码可以声明程序变量和常量，执行传统的流控制语句（if-else、循环等），执行数据操作操作（插入、更新、更新插入、删除），以及执行事务控制操作（setSavepoint、回滚） .
　　您可以使用两种不同的形式将 Apex 程序存储在平台中：作为具有方法的命名 Apex 类（类似于传统数据库用语中的存储过程），应用程序在必要时执行，或者作为在特定数据库之前或之后自动执行的数据库触发器操作事件发生。无论采用哪种形式，平台都会编译 Apex 代码并将其作为元数据存储在 UDD 中。组织第一次执行 Apex 程序时，平台的运行时解释器将程序的编译版本加载到该组织的 MRU（最近使用的）缓存中。此后，当来自同一组织的任何用户需要使用相同的例程时，平台可以通过共享已经在内存中的准备运行的程序来节省内存并避免再次重新编译程序的开销。
　　通过在这里和那里添加一个简单的关键字，开发人员可以使用 Apex 来支持许多独特的应用程序需求。例如，开发人员可以将方法公开为自定义 RESTful 或基于 SOAP 的 API 调用，使其可异步调度，或将其配置为批量处理大型操作。
　　Apex 不仅仅是＂另一种程序语言＂。它是一个集成的平台组件，可帮助系统提供可靠的多租户。例如，平台会自动验证类中所有嵌入的 SOQL 和 SOSL 语句，以防止代码在运行时失败。然后，平台维护有效类的相应对象依赖关系信息，并使用它来防止更改元数据，否则会破坏依赖代码。
　　许多标准 Apex 类和系统静态方法为底层系统功能提供了简单的接口。例如，插入、更新和删除等系统静态 DML 方法具有一个简单的布尔参数，开发人员可以使用该参数来指示所需的批量处理选项（全部或全部，或部分保存）；这些方法还返回一个结果对象，调用例程可以读取该结果对象以确定哪些记录未成功处理以及原因。Apex 和平台功能之间直接联系的其他示例包括内置电子邮件类和 XmlStream 类。内部平台处理
　　在很大程度上，该平台的性能和扩展性都很好，因为 Salesforce 在构建它时考虑了两个重要原则：提供高效、大规模的基础平台能力。 帮助开发人员尽可能高效地完成所有工作。
　　该平台将这些原则融入平台的独特处理架构中，包括：查询 搜索 批量操作 架构修改 多租户隔离 回收站 查询
　　大多数现代数据库系统通过采用基于成本的查询优化器来确定最佳查询执行计划，该优化器考虑有关目标表和索引数据的相关统计信息。然而，传统的、基于成本的优化器统计是为单租户应用程序设计的，无法考虑在多租户环境中执行查询的任何给定用户的数据访问特征。例如，针对具有大量数据的对象的给定查询很可能使用不同的执行计划更有效地执行具有高可见性的用户（可以查看所有行的经理）与低可见性的用户（可以查看所有行的销售人员）。只看到与自己相关的行）。
　　为了提供足够的统计信息来确定多租户系统中的最佳查询执行计划，平台为每个组织的对象维护一套完整的优化器统计信息（租户、组和用户级别）。统计信息反映特定查询可能访问的行数，仔细考虑整体组织特定对象统计信息（例如，组织作为一个整体拥有的总行数），以及更精细的统计信息（例如，特定权限组或最终用户可能访问的行数）。
　　该平台还维护其他类型的统计信息，这些统计信息对特定查询很有帮助。例如，平台维护所有自定义索引的统计信息，以显示相应字段中非空值和唯一值的总数，以及显示每个列表值基数的选项列表字段的直方图。
　　当现有统计信息不存在或被认为无用时，平台的优化器会使用一些不同的策略来帮助构建合理的优化查询。例如，当查询过滤对象的 Name 字段时，优化器可以使用 MT_Fallback_Indexes 表来有效地查找请求的行。在其他情况下，优化器会在运行时动态生成缺失的统计信息。
　　该平台的优化器与优化器统计信息一起使用，还依赖于内部安全相关表（Groups、Members、GroupBlowout 和 CustomShare），这些表维护有关组织用户安全域的信息，包括给定用户的组成员资格和自定义访问权限对于对象和行。此类信息对于确定基于每个用户的查询过滤器的选择性非常宝贵。有关该平台的嵌入式安全模型的更多信息，请参阅平台开发者基础教程。
　　下图中的流程图说明了当平台处理对某个大型堆表（例如 MT_Data）中的数据的请求时会发生什么。请求可能来自任意数量的来源，例如 API 调用或存储过程。首先，平台执行考虑多租户感知统计信息的＂预查询＂。然后，根据预查询返回的结果，该服务构建一个最优的底层数据库查询，以便在特定设置中执行。
　　如下表所示，平台可以通过四种不同的方式执行相同的查询，具体取决于提交查询的用户和查询过滤条件的选择性。
　　查询前选择性测量
　　编写最终的数据库访问查询，强制...
　　用户
　　筛选
　　低的
　　低的
　　...嵌套循环连接，使用用户可以看到的行视图驱动
　　低的
　　高的
　　... 使用与过滤器相关的索引
　　高的
　　低的
　　... 有序散列连接，使用 MT_DATA 驱动
　　高的
　　高的
　　...使用索引相关过滤器 搜索
　　用户期望交互式搜索功能能够扫描应用程序数据库的全部或选定范围，并以亚秒级响应时间返回排名结果。为了向平台应用程序提供这种能力，平台使用了一个独立于其事务引擎的搜索引擎。当您更新记录时，事务引擎会更新核心数据库并将相关数据转发给搜索引擎进行索引。当您搜索记录时，搜索引擎会使用其索引来快速处理查询并返回排名结果以及相关数据库记录的链接。
　　当应用程序更新文本字段（CLOB、名称等）中的数据时，称为索引服务器的后台进程池负责异步更新相应的索引，搜索引擎在核心事务引擎之外维护这些索引。为了优化索引过程，平台在事务提交时将修改后的文本数据块同步复制到内部＂待索引＂表，从而提供相对较小的数据源，最大限度地减少索引服务器必须从磁盘读取的数据量. 搜索引擎自动为每个组织维护单独的索引。
　　根据索引服务器的当前负载和利用率，文本索引更新可能滞后于实际事务。为了避免源自陈旧索引的意外搜索结果，该平台还维护一个最近更新的行的 MRU 缓存，系统在具体化全文搜索结果时会考虑这些行。该平台在每个用户和每个组织的基础上维护 MRU 缓存，以有效地支持可能的搜索范围。
　　该平台的搜索引擎使用多种方法优化搜索结果中记录的排名。例如，系统会考虑执行搜索的用户的安全域，并在当前用户可以访问的行中赋予更多权重。系统还可以考虑特定行的修改历史，并将更积极更新的行排在相对静态的行之前。用户可以根据需要选择对搜索结果进行加权，例如，更加强调最近修改的行。批量操作
　　事务密集型应用程序在批量组合和执行重复操作时产生的开销更少，性能更好。例如，对比应用程序可能加载许多新行的两种方式。一种低效的方法是使用带有插入单个行的循环的例程，为每个插入行进行一个又一个 API 调用。一种更有效的方法是创建一个行数组，并让例程通过一个 API 调用将它们全部插入。
　　该平台的高效批量处理对开发人员来说很简单，因为它已融入 API 调用。在内部，平台还批量处理与显式批量操作相关的所有内部步骤。
　　该平台的批量处理引擎会自动考虑在此过程中的任何步骤中遇到的孤立故障。当批量操作以部分保存模式启动时，引擎会识别一个已知的启动状态，然后尝试执行流程中的每个步骤（批量验证字段数据、批量触发预触发器、批量保存记录等）。如果引擎在任何步骤中检测到错误，引擎会回滚违规操作和所有副作用，删除导致错误的行，然后继续尝试批量处理剩余的行子集。这个过程迭代每个连续的阶段，直到引擎可以提交行的子集而没有任何错误。应用程序可以检查返回对象以确定哪些行失败以及它们引发了哪些异常。
　　注意：根据您的判断，批量操作可以使用全有或全无模式。此外，在批量操作期间触发器的执行受内部调控器的限制，这些调控器限制了工作量。架构修改
　　对对象定义的某些类型的修改需要的不仅仅是简单的 UDD 元数据更新。在这种情况下，该平台使用有效的机制来帮助减少对整个云数据库服务的整体性能影响。
　　例如，考虑将列的数据类型从选择列表修改为文本时在幕后发生的情况。平台首先为列的数据分配一个新槽，批量复制与当前值关联的选项列表标签，然后更新列的元数据以使其指向新槽。虽然所有这些都发生了，但对数据的访问是正常的，应用程序继续运行而没有任何明显的影响。
　　作为另一个示例，请考虑将汇总汇总字段添加到对象时发生的情况。在这种情况下，平台使用高效的批量操作在后台异步计算初始摘要。在进行后台计算时，查看新字段的用户会收到平台当前正在计算该字段值的指示。多租户隔离和保护
　　为了防止恶意或无意垄断共享的多租户系统资源，该平台具有大量与平台代码执行相关的调控器和资源限制。例如，平台密切监视代码脚本的执行，并限制它可以使用多少 CPU 时间、它可以消耗多少内存、它可以执行多少查询和 DML 语句、它可以执行多少数学计算、多少它可以进行的出站 Web 服务调用等等。平台优化器认为执行成本太高的单个查询会向调用者抛出运行时异常。尽管这些限制听起来有些限制，但它们对于保护所有相关应用程序的共享数据库系统的整体可伸缩性和性能是必要的。在长期，这些措施有助于在开发人员中推广更好的编码技术，并为使用该平台的每个人创造更好的体验。例如，如果开发人员最初尝试编写一个循环一次低效地更新一千行一行的代码，则会由于资源限制而收到运行时异常，然后开始使用平台的高效批量处理 API 调用。
　　为了进一步避免因编写不佳的应用程序而引入的潜在系统问题，新生产应用程序的部署是一个严格管理的过程。在组织可以将新应用程序从开发状态转换到生产状态之前，Salesforce 需要单元测试来验证应用程序平台代码例程的功能。提交的单元测试必须覆盖不少于 75% 的应用程序源代码。
　　Salesforce 在平台的沙盒开发环境中执行提交的单元测试，以确定应用程序代码是否会对整个多租户群体的性能和可扩展性产生不利影响。单个单元测试的结果指示基本信息，例如执行的总行数，以及有关未由测试执行的代码的特定信息。
　　一旦应用程序的代码通过 Salesforce 的生产认证，应用程序的部署过程将由一个事务组成，该事务将所有应用程序的元数据复制到生产平台实例并重新运行相应的单元测试。如果过程的任何部分失败，平台只需回滚事务并返回异常以帮助解决问题。
　　注意： Salesforce 会在平台的每个开发版本中重新运行每个应用程序的单元测试，以主动了解新的系统功能和增强功能是否会破坏任何现有应用程序。
　　生产应用程序上线后，平台的内置性能分析器会自动对其进行分析并向管理员提供相关反馈。性能分析报告包括有关慢速查询、数据操作和子例程的信息，您可以查看这些信息并使用它们来调整应用程序功能。该系统还记录并返回有关运行时异常的信息给管理员，以帮助他们调试他们的应用程序。删除、取消删除和回收站
　　当应用程序从对象中删除记录时，平台只需通过修改 MT_Data 中行的 IsDeleted 字段来标记要删除的行。此操作有效地将行放置在所谓的回收站中。该平台允许您从回收站中恢复选定的行长达 15 天，然后再将它们从 MT_Data 中永久删除。该平台会根据该组织的存储限制来限制它为该组织维护的记录总数。
　　当操作删除涉及主从关系的父记录时，平台会自动删除所有相关的子记录，前提是这样做不会破坏任何现有的参照完整性规则。例如，当您删除 SalesOrder 时，平台会自动将删除级联到依赖的 LineItems。如果您随后从回收站恢复父记录，系统也会自动恢复所有子记录。
　　相反，当您删除涉及查找关系的引用父记录时，平台会自动将所有依赖键设置为空。如果您随后恢复父记录，平台会自动恢复先前为空的查找关系，但在删除和恢复操作之间重新分配的关系除外。
　　回收站还存储删除的字段及其数据，直到组织永久删除它们或经过设定的天数，以先发生者为准。在此之前，整个字段及其所有数据都可用于恢复。平台基础设施
　　敏捷性是企业在现代世界取得成功的关键。Salesforce 平台的底层可帮助您的业务应用程序快速适应新的挑战，因此您可以继续专注于您的业务而不是基础设施。超力
　　基础设施（例如，基础服务和计算资源）是隐藏的底层技术，支持 Salesforce 平台中的上层。Hyperforce是 Salesforce 平台基础架构，建立在 100% 可再生能源和净零基础之上，可解决关键的客户挑战，包括合规性、信任和可扩展性规约
　　在多个地理位置运营的企业需要遵守新的、不断发展的和不断变化的数据管理法规。由于 Salesforce 正在越来越多的国家/地区部署 Hyperforce，目前基于 AWS 区域的可用性，平台应用程序和用户可以以符合严格的数据存储或数据保护标准的方式运行其敏感的工作负载。例如，借助由 Hyperforce 提供支持的Salesforce 的欧盟 (EU) 运营区，欧盟企业可以轻松地将其数据保存在欧盟。信任
　　安全性、可靠性和可用性是每个业务应用程序必须考虑的非功能性要求，以兑现对其最终用户的信任承诺。借助 Hyperforce，Salesforce 平台可让企业轻松交付受信任的业务应用程序。安全 性——Hyperforce 对静态和传输中的客户数据进行本地端到端加密。Hyperforce 的零信任架构强制执行严格的身份验证流程，以确保不会对资源进行隐式访问。Hyperforce 使用 最小权限原则 ，确保操作在适当的时间内以适当的访问权限获得批准。 可靠性 — Hyperforce 的每个实例都使用多个云可用区和现代化的方法来加快事件响应速度，以提供高度可用和弹性的平台。 可用性 — Hyperforce 的现代 CI/CD 管道和蓝/绿应用程序版本将应用程序维护时间缩短到每年仅一分钟。 概括
　　作为 Sales Cloud 和 Service Cloud 等应用程序的基础，Salesforce 是一个经过验证的应用程序开发平台，各个企业和服务提供商在此平台上构建了数百万个用于不同用例的业务应用程序，包括供应链管理、计费、会计、商务、合规跟踪、人力资源管理和索赔处理。该平台独特的、多租户、元数据驱动的架构专为云而设计，可靠且安全地支持关键任务、互联网规模的应用程序。使用基于标准的 API 和原生开发工具，平台开发人员可以轻松构建现代 Web 或移动应用程序的所有组件，包括应用程序的数据模型（包括对象和关系）、业务逻辑（包括工作流和验证）。
　　自成立以来，该平台已由 Salesforce 的工程师针对多租户进行了优化，其功能可让平台应用程序扩展以满足不断变化的业务需求。集成的系统功能——例如批量数据处理 API、Apex、全文搜索引擎和独特的查询优化器——有助于使相关应用程序变得高效和可扩展，而开发人员只需很少或无需付出任何努力。
　　Salesforce 用于部署生产应用程序的托管方法可确保依赖该平台的所有应用程序具有出色的性能、可扩展性和可靠性。Salesforce 持续监控和收集来自平台应用程序的操作信息，以帮助推动增量改进和新的系统功能，从而立即使现有和新的应用程序受益。关于作者
　　Steve Bobrowski 是一位成功的企业和技术领导者，他曾在多家领先的企业软件公司工作，包括自 2008 年以来在 Salesforce 担任各种职务。如今，Steve 在 Salesforce 的 CTO 办公室工作，帮助公司制定技术架构战略。
　　Tom Leddy 是 Salesforce 的架构师宣传员。他通过帮助创建资源、工具和指南来支持 Salesforce 架构师最佳社区，以帮助架构师完成工作。在 LinkedIn和Twitter 上与 Tom 联系。