共计 10875 个字符，预计需要花费 28 分钟才能阅读完成。
架构模式
底层机制的要害架构组件
在 Force.com 中，裸露给开发和应用程序用户的所有货色都外在地出现为元数据。表格、报告、工作流、用户拜访权限、租户特定的自定义和业务逻辑，甚至是根底数据表和索引的定义，所有这些都只是作为元数据在 Force.com 的通用数据字典（UDD-The Universal Data Dictionary）中被形象和构建。例如，当一个开发人员建设一个新的自定义利用时，定义客户表，搁置一个表单，或写一些程序代码，Force.com 并不会在数据库中创立一个“理论”的表或编译任何代码。相同，Force.com 只是简略地存储元数据，该平台的引擎可应用这些元数据在运行时生成“虚构”的应用程序组件。当有人想批改或定制一些无关应用程序，所须要做的只是对相应元数据简略的无阻塞更新。
因为元数据是影响 Force.com 利用的要害成分，该平台的运行时引擎必须优化元数据的拜访，否则，频繁拜访元数据将会妨碍平台的可扩展性。思考到这个潜在的瓶颈，Force.com 应用元数据缓存，以将最近最多应用的元数据放弃在内存中，从而防止性能受到磁盘 I / O 和代码从新编译的影响，并进步应用程序的响应工夫。
Force.com 将多数大型数据库虚表中的所有利用数据作为堆存储。而后思考相应的元数据，该平台的引擎在运行时物化虚构表中的数据。为了优化零碎大表的数据存取，Force.com 的引擎上依赖一组专门的数据透视表，来保护各种用处的非规范化的数据，如索引，唯一性，关系，等等。
Force.com 的数据处理引擎通过通明地进行批量数据批改操作，精简了大型数据的加载开销和在线事务处理利用。该引擎内置故障复原机制，主动在剖析出导致谬误的因素后重试批量保留操作。
为了进一步晋升应用程序的响应工夫，该平台采纳内部搜寻服务优化全文索引和搜寻。应用程序更新数据时，搜寻服务的后盾过程近实时地异步更新租户和用户的索引。应用程序引擎和搜寻服务之间的职责拆散使平台利用能够无效地处理事务，而没有文本索引的更新开销，同时也为用户迅速提供精确的搜寻后果。
因为 Force.com 的运行时应用程序生成器，针对特定的用户申请动静地建设应用程序，所以引擎在很大水平上依赖其“多租户感知”的查问优化器尽可能无效地执行外部操作。查问优化器首先思考哪些用户正在执行给定的利用性能，而后利用保护在 UDD 中的相干租户的特定元数据以及外部的零碎透视表，建设并执行数据拜访操作，以优化数据库查问。
数据模型
1 对象元数据表（The Objects Metadata Table）
Metadata 表的作用是存储用户定制的对象和对象所蕴含的字段的构造信息，不保留具体的数据，次要有两大类：
- Object Metadata 表：这个表次要存储对象的信息，其中次要字段包含对象的 ID（ObjID），领有这个对象的租户的 ID（OrgID）和这个对象的名字（ObjName）。
- Field Metadata 表：这个表次要存储对象附带字段的信息，其中次要字段包含字段的 ID（FieldID），领有这个字段的租户的 ID（OrgID），这个字段的名字（FieldName），这个字段的数据类型（datatype）和一个布尔字段（IsIndexed）来定义这个字段是否须要被检索。
2 字段元数据表（The Fields Metadata Table）
字段元数据表存储组织自定义对象的自定义字段（又名列或属性），包含一个字段的惟一标识符（FieldID），领有该对象的组织（OrgID），蕴含该字段的对象（ObjID），字段名称（FieldName），该字段的数据类型，示意如果该字段是否须要索引的 Boolean 值（IsIndexed）和在对象中绝对于其余字段的地位（FieldNum）。
3 数据表（The Data Table）
数据表存储可供拜访的应用程序数据，并通过对象和字段的元数据定义映射到自定义对象和字段。每一行包含一个标识字段如全局惟一标识符（GUID）、领有该行的组织（OrgID）以及对象标识符（ObjID）。数据表中的每一行也有一个名称字段存储相应对象实例的“天然名”。例如，一个 Account 对象能够应用“Account Name”，一个 Case 对象可能会应用“Case Number”等等。这 Value0 …Value500 列存储利用数据，这些列将对象和字段别离映射到在对象和字段表中申明过的对象和字段；所有“flex”列应用可变长度字符串数据类型，从而可能存储任何类型的应用程序数据（strings，numbers，dates 等）。
自定义字段能够应用任何一种规范结构化数据类型，如 text，number，date，和 date/time 以及非凡用处的结构化数据类型，如抉择列表（枚举字段），主动编号（主动递增，系统生成的序列数），公式（只读的派生值），主从关系（外键），复选框（布尔），电子邮件，网址等。自定义字段也可能是必须的（不为空），或者蕴含自定义的验证规定（例如，一个字段的值必须比其余字段更大），两者都是通过该平台的应用服务器来实现的。
当一个组织申明或批改自定义应用程序的对象，Force.com 治理对象元数据表中定义对象的一行。同样，对于每个自定义字段，Force.com 治理字段表中的一行，包含将这个字段映射到数据表中的一个存储相应字段数据的 flex 列的元数据。因为 Force.com 将对象和字段定义作为元数据而不是理论的数据库构造来治理，所以平台能够容忍多租户利用模式的保护流动，而不妨碍其余租户和用户的并发流动。
同一个对象不会有两个字段映射到数据表中同一个的 flex 列（槽）存储；然而，一个 flex 列能够治理多个字段的信息，但每个字段来自于不同的对象。
(一个 flex 列能够存储来自不同对象的属性的数据，它们领有不同的数据类型)
如图所示的数据表的简化示意，flex 列领有一种通用数据类型（变长字符串类型），容许 Force.com 在多个字段间共享一个 flex 列，应用各种结构化的数据类型（strings，numbers，dates 等）。
Force.com 应用对立的格局存储所有 flex 列数据，而且当应用程序从 flex 列读取和写入数据时，必要时候应用底层数据库系统的数据类型转换函数（例如，TO_NUMBER，TO_DATE，TO_CHAR）。
4 Clobs 表（The Clobs Table）
Force.com 反对将字段作为字符大对象（CLOBs）申明，以容许存储多达 32,000 个字符的长文本字段。对于每一个在数据表含有 CLOB 字段的行，Force.com 会在一个称为 Clobs 的透视表中存储 CLOB 超行，零碎能够必要时通过它与数据表中相应的行进行连贯运算。
注：Force.com 还将 CLOBs 以索引模式存储在数据库内部，以不便疾速的文本搜寻。
5 索引透视表（The Indexes Pivot Table）
传统的数据库系统依赖索引迅速定位数据库表中的字段满足特定匹配条件的行。然而，为数据表的 flex 列创立本地索引是不切合实际的，因为 Force.com 可能用一个 flex 列来存储很多字段的数据，且它们的数据结构类型各不相同。所以，Force.com 通过同步复制有标记的字段来治理数据表的索引，这些标记字段数据被索引到一个称为 Indexes 的数据透视表中相应的列，如图 7 简化 ER 图的形容。
该 Indexes 表蕴含强类型的索引列，如 StringValue，NumValue 和 DateValue，Force.com 借此查找相应数据类型的字段数据。例如，Force.com 将复制一个数据表中 flex 列的字符串值到 Indexes 表的 stringValue 的字段，将日期值复制到 DateValue 字段，等等。Indexes 表的底层索引是规范的非惟一数据库索引。当蕴含一个查问参数外部零碎查问援用了自定义对象中的一个结构化字段，该平台的查问优化器就应用索引表，以帮忙优化相干的数据拜访操作。
(Force.com 应用数据透视表来索引存储在 flex 列的数据)
注：Force.com 能够解决多语言搜寻，因为该平台的应用服务器应用大小写折叠算法将字符串值转换成一个广泛的、大小写不敏感的格局。Indexes 表的 StringValue 列以这种格局存储字符串。在运行时，查问优化器主动生成数据拜访操作，从而使得对于字面上给定的搜寻申请，优化后的 SQL 语句能够做些相应大小写折叠后的 StringValue 的过滤。
6 数据和元数据的分区（Partitioning of Metadata, Data, and Index Data）
所有 Force.com 数据，元数据和数据透视表构造（包含根底数据库索引）均由 OrgID（租户）应用本机数据库分区机制进行物理分区。数据分区是数据库系统提供的一种成熟技术，可将大型逻辑数据结构物理划分为更小，更易治理的局部。分区还能够帮忙进步大型数据库系统（如多租户环境）的性能，可伸缩性和可用性。依据定义，每个 Force.com 查问都会针对特定租户的信息，因而查问优化器只需思考拜访蕴含租户数据的数据分区，而不是整个表或索引。这种常见的优化有时被称为““partition pruning”。
7 惟一域的数据透视表（The UniqueFields Pivot Table）
Force.com 容许组织指出何时一个对象中的字段必须蕴含惟一值（辨别大小写或不辨别大小写）。思考到数据表值列上共享应用自定义的字段数据，为表创立惟一的数据库索引是不切实际的，这与后面局部探讨过的非惟一索引问题相似。
为了反对自定义字段的唯一性，Force.com 应用称为 UniqueFields 的数据透视表来实现，这表与 Indexes 数据透视表十分类似，只不过 UniqueFields 数据透视表的底层数据库索引强制唯一性。当一个应用程序试图在须要唯一性的字段上插入反复值，或者管理员试图在蕴含反复值的已有字段上强制唯一性时，Force.com 直达一个适当的谬误音讯给应用程序。
8 关系数据透视表（The Relationships Pivot Table）
Force.com 提供了组织申明其利用对象间关系的“关系”数据类型（参照完整性）。当一个组织将对象的字段申明为关系类型时，平台将该字段映射到数据表中的一个值字段，而后应用该字段来存储相干对象 ObjID。
为了优化连贯操作，Force.com 保护一个称为关系（Relationships）的数据透视表，如图 8 所示。
图 8：关系表可帮忙优化对象连接。
关系索引表（The Relationships Index table）有两个底层数据库的惟一联结索引，即 OrgID +GUID，和 OrgID + ObjID + RelationID + TargetObjID，从而保障必要时对象双向遍历的高效性。
9 FallbackIndex 表（The FallbackIndex Table）
在极少数状况下，平台的内部搜索引擎可能超载或不可用，或可能无奈及时响应搜寻申请。用户提交一个查问申请后，该平台的用户服务器进入后备的二级搜寻机制，返回正当的搜寻后果，而不是返回一个令人悲观的谬误。
后备搜寻是数据库查问的间接实现，它参照指标利用对象的名称字段进行搜寻。为了不用执行潜在的低廉的 Union 查问，实现优化搜寻全局对象（跨对象搜寻），Force.com 保护一个称为 FallbackIndex 的数据透视表来记录所有对象的名称。当事务批改对象时，FallbackIndex 同步更新，后备搜寻总能够拜访到最新的数据库信息。
10 NameDenorm 表（The NameDenorm Table）
该表是一个精简的数据表，存储 ObjID 和数据表中每个对象实例的名称。当利用须要给出一个父子关系的对象实例的超链接列表时，Force.com 应用 NameDenorm 表来执行一个绝对简略的查问，检索每个援用对象的名称以失去超链接的列表。
11 历史跟踪表（History Tracking Table）
Force.com 容易实现对任何字段的历史跟踪。当组织审计特定的字段，零碎将应用一个用于审计跟踪的外部透视表异步记录该字段的变动信息（旧值，新值，扭转的日期等）。
好了，明天这篇是前面章节所有内容的铺垫，理解了这个数据模型，会不便大家了解 Salesforce 的“令人发指”的灵活性。
UDD 模型
SF 的每一条记录都有本人的编号，一个 Account，一个业务机会等等都会有本人的 UniqueID。怎么查看呢？
当你关上一条记录，在浏览器的地址栏都能够看到这条记录的 ID，这个 ID 在开发人员后盾是能够间接用来检索数据的。
这个 18 位的编号就是这个名叫“Canson”的客户的 ID，它是怎么形成的呢？
1）前三位是 key prefix（要害前缀），对应代表不同的对象；
2）前面二位是 Instance 的编号，代表着所属的 Instance，当初一共有 75+ 个 Instance，所以占两位，将来有可能会场超过 2 位，所以紧跟着的第 6 和 7 位是 reserved，预留 Instance 当前数量减少用的；
3）两头那串才是正经的这个记录的 Unique ID；
4）最初三位，Case Checksum，用来标记 case 的一些补充信息信息的；（有时候没有这三位，ID 就是 16 位数字；）
应用服务器
应用服务器次要包含五大外围模块：
- Metadata Cache：用于寄存那些最近用到的和比拟罕用的 Metadata 来减速利用的生成。
- 大规模数据处理引擎：次要用来减速解决大量的数据读写和在线事务。
- 多租户感知的查问优化引擎：这个引擎将通过保护多租户的信息来帮忙 Oracle 自带的基于老本的查问优化器更好地适应多租户环境。
- 运行时利用生成器：这个生成器次要依据用户的申请来动静生成利用，并且利用下面提到的查问优化引擎来晋升效率。
- 全文检索引擎：在数据库对数据进行更新的同时，这个引擎会异步更新这个数据的相干索引。
共享数据库
图 1. Force.com 的架构（图源自参 [1]）
整个共享数据库次要有三种类型的数据库表：
- Metadata 表：次要寄存用户定制的对象和对象所蕴含的字段的构造信息，也被称为 ”UDD”。
- 数据表：次要存储那些用户定制的对象和对象所蕴含的字段的数据。
- Pivot 表：用来保护那些用于检索（indexing），唯一性和关系等 denormalized（去规范化）数据以优化零碎的效率。
还有，在物理层面，数据库外面所有表格，包含底下的索引，都依据每个租户不同的租户 ID（OrgID）来应用 Oracle 的 Hash 分区技术进行分区。通过 Hash 分区这种久经考验的技术可能将大规模的数据均匀地宰割成多个更小的和更容易治理的分块，从而帮忙大数据库系统可能在多租户的环境下晋升速度，伸缩性和可用性等。
虚构利用
Force.com 会有一套引擎来通过剖析数据库中的 Metadata 来动静生成一个虚构利用实例和这个利用所需的模块（Virtual Application Componets），比方公共 UI（Common Application Screen），定制 UI（Tenant-Specific Screen）和其余对象等。
多租户解决
在很大水平上，Force.com 的体现和扩大十分好，因为 salesforce.com 依据两个重要准则构建了服务。
- 尽可能提高效率。
- 帮忙开发者尽可能高效地实现所有工作。
多租户查询处理
为了提供足够的统计信息来确定多租户零碎中的最佳查问执行打算，Force.com 为每个虚构多租户对象保护一组残缺的优化器统计信息（租户，组和用户级别）。统计数据反映了特定查问可能拜访的行数，认真思考了整个租户特定的对象统计信息（例如，整个租户领有的总行数）以及更准确的统计数据（例如，数字特定特权组或最终用户可能拜访的行）。
Force.com 还保护其余类型的统计数据，这些统计数据证实对特定查问有帮忙例如，该服务保护所有自定义索引的统计信息，以揭示相应字段中非空和惟一值的总数以及揭示每个列表值的基数的选项列表字段的直方图。
当现有的统计数据不存在或不被认为有帮忙时，Force.com 的优化器会应用一些不同的策略来帮忙构建正当的最佳查问。在其余状况下，优化器将在运行时动静生成短少的统计信息。
与优化器统计联合应用时，Force.com 的优化器还依赖与外部平安相干的表（组，会员，GroupBlowout 和 CustomShare）保护无关零碎用户平安域的信息，包含给定用户的组成员身份和自定义拜访权限对象和行。这样的信息在确定每个用户的查问过滤器的选择性方面是十分有价值的。
多租户搜寻解决
基于 Web 的应用程序用户冀望具备交互式搜寻性能，可能扫描应用程序数据库的全副或选定范畴，返回最新的排名后果，并在亚秒级响应工夫内实现。为了为应用程序提供弱小的搜寻性能，Force.com 应用与其事务引擎离开的搜索引擎。下图形容了两个引擎之间的关系。搜索引擎从事务引擎接收数据，并用它创立搜寻索引。事务引擎将搜寻申请转发给搜索引擎，搜索引擎返回事务引擎用于查找满足搜寻申请的行的后果。
多租户隔离和爱护
为了避免共享的多租户系统资源受到歹意或无心的垄断，Force.com 领有大量与 Force.com 代码执行相干的管理员和资源限度。例如，Force.com 亲密监督代码脚本的执行状况，并限度它能够应用多少 CPU 工夫，能够应用多少内存，能够执行多少个查问和 DML 语句，能够执行多少个数学计算，以及如何执行许多出站 Web 服务调用它能够做，等等。Force.com 的优化器认为执行代价过高的个别查问会向调用方抛出运行时异样。只管这些限度听起来有些限度，但它们对于爱护所有相干应用程序的共享数据库系统的整体可扩展性和性能是必要的。从久远来看，这些措施有助于促成开发人员之间更好的编码技术，并为应用该平台的每个人发明更好的体验。例如，最后尝试编码循环的开发人员因为资源限度而无奈无效更新每行一千行的行，将会收到运行时异样，而后开始应用 Force.com 的高效批量解决 API 调用。
为了进一步防止由编写不佳的应用程序引起的潜在零碎问题，部署新的生产应用程序是一个严格管理的过程。在组织能够将新应用程序从开发转换为生产状态之前，salesforce.com 须要进行单元测试，以验证应用程序的 Force.com 代码例程的性能。提交的单元测试必须笼罩不低于应用程序源代码的 75%。Salesforce.com 在 Force.com 的沙箱开发环境中执行提交的单元测试，以确定利用程序代码是否会对整个多租户人群的性能和可扩展性产生不利影响。单个单元测试的后果示意根本信息，例如执行的总行数，以及无关代码未被测试执行的特定信息。
多租户批量操作
事务密集型应用程序产生的开销较小，并且在批量组合和执行反复操作时性能会更好。例如，比照应用程序可能加载许多新行的两种形式。一种效率低下的办法是应用一个带有循环的例程，该循环插入独自的行，为每个行插入创立一个 API 调用。更无效的办法是创立一个行数组，并让这个例程通过一个 API 调用来插入所有这些行。
应用 Force.com 进行高效的批量解决对开发人员来说很简略，因为它曾经被退出到 API 调用中。在外部，Force.com 还批量解决与显式批量操作相干的所有外部步骤。
Force.com 的批量解决引擎会主动计算在此过程中遇到的孤立故障。批量操作在局部保留模式下启动时，引擎会辨认已知的启动状态，而后尝试执行流程中的每个步骤（批量验证现场数据，批量火灾预触发器，批量保留记录等）。如果引擎在任何步骤中检测到谬误，引擎会回滚违规操作和所有副作用，删除引发故障的行并持续尝试批量解决残余行的子集。这个过程遍历每个后续阶段，直到引擎能够提交行的一个子集而没有任何谬误。应用程序能够查看返回对象以确定哪些行失败以及引发了哪些异样。
留神：依据你的判断，批量操作能够应用全空模式。此外，批量操作期间触发器的执行受制于限度工作量的外部管理员。
多租户模式批改
某些类型的对象定义批改须要的不仅仅是简略的 UDD 元数据更新。在这种状况下，Force.com 应用无效的机制来帮忙缩小整体性能对云数据库服务的影响。
例如，思考当您将列的数据类型从选取列表批改为文本时产生的结果。Force.com 首先为列的数据调配一个新插槽，批量复制与以后值关联的选取列表标签，而后更新列的元数据以使其指向新插槽。产生所有这些状况时，拜访数据是失常的，应用程序持续运行，没有任何显著的影响。
作为另一个例子，请思考在将汇总摘要字段增加到对象时会产生什么状况。在这种状况下，Force.com 应用高效批量操作在后盾异步计算初始摘要。在进行背景计算时，查看新字段的用户会收到 Force.com 以后正在计算字段值的批示。
APEX
APEX 的语言是为 Force.com 度身定做的一门语法上相似 Java 的强类型面向对象语言，次要能够通过 APEX 在 Force.com 上创立 Web Service，编辑简单的商业逻辑和整合多个 Force.com 的模块等。APEX 次要以两种形式执行：其一是以独自脚本的模式，依照用户的须要执行。其二是以触发器的模式，当一个特定的数据处理事件产生的之前或者之后，与这个事件绑定的 APEX 代码将会被执行。而且所有 APEX 代码将会以 Metadata 的模式存储在 Metadata 表内。当一段 APEX 代码被调用的时候，APEX 的翻译器（runtime interpreter）将会从 Metadata Cache 读取编译之后的 APEX 代码，而且可能同时被多个租户共享以晋升效率。
那么为什么要在 Force.com 引入 APEX 这门新的语言，而不是像 Google App Engine 那样反对曾经有肯定市场占有率的语言，比方 Java 和 Pyhon。Salesforce 的首席架构师在谈到这点时，他提出了一个十分重要的起因，那就是平安，首先，Salesforce 会 APEX 语言度身设计一组管理工具，通过这个工具可能十分不便地监控 APEX 脚本的执行，并且能晓得这个脚本在执行过程所消耗的 CPU 工夫，内存容量和 SQL 语句的数量等数据来判断是否须要中断这个 APEX 脚本，以防止影响到属于其余租户的利用，如果中断的话，零碎会抛出一个 runtime exception 给下层的调用者。其次，基于 APEX 语言的代码可能对其内嵌的 SOQL（Sforce Object Query Language）和 SOSL（Sforce Object Search Language）进行验证来防止理论运行时呈现谬误。还有，在平安方面除了 APEX 自带的性能之外，Salesforce 还要求每个上传到 Force.com 的 APEX 脚本，都须要自带能笼罩其 75% 代码的测试用例，这种做法不仅显著地晋升 APEX 代码的品质从而确保平台整体运行的稳固，而且在 Force.com 本人更新的时候，能应用这些用例来确保新的更新不会影响现有的基于 Force.com 的利用。
设计理念
依据 Craig Weissman 的演讲和几份官网的白皮书，在 Force.com 的设计方面 Salesforce 团队次要有上面这五大考量：
- 数据驱动：因为 Salesforce 次要面向企业用户，导致其下面运行的利用，无论是 CRM，还是报表工具，都是以数据的 CRUD（增删改查）为外围，所以 Force.com 须要由数据来驱动，而且也须要为此做肯定水平的优化。
- 规模经济：因为须要在低价格和灵便付费的根底上提供可定制化利用，所以须要让尽可能多用户共享同一套零碎，来大幅减低基础设施和治理等资源的投入，并实现规模经济的效益。
- 平安为先：因为在一套物理设施上将承载数以万计客户的企业级利用，那么如果呈现重大的程序谬误或者数据方面遗失或者错乱，将会产生十分重大的结果，所以平安问题是一个 Salesforce 绝不能鄙视的问题。
- 定制不便：尽管各个企业都会存在一部分比拟通用的流程，然而每个企业都可能存在一部分公有或者独特的流程，所以 Force.com 须要提供方便的定制性能来帮忙用户将更快捷地将企业的业务迁徙到其上。
- 功能丰富：尽管用户能在 Force.com 上进行开发和定制，然而如果 Force.com 能提供更多的功能模块或者能让用户购买和整合第三方的利用将十分无效地帮忙用户开发利用。
尽管这些设计理念说起来很容易，然而实现起来是十分艰巨的。可贵地是，Salesforce 团队在开发 Force.com 的过程中根本实现了这些设计理念。
总结
对于本系列的总结，也次要包含五个方面：
- Trade-Off 是不免的：为了满足设计指标，有时不得不做 Trade-Off。因为 Salesforce 所须要承载的多租户利用的规模之大，定制化需要之高都是前所未见的，所以 Salesforce 并没有采纳常见的 ddl 变更模型，而是从长计议，采纳了更灵便但技术要求更高的 Metadata 形式。还有为了防止在数据库中执行老本十分高并会 Locking 整个数据库的 DDL（数据库定义语句）操作，所以在 Force.com 运行的时候是无奈创立和批改数据库表，而这样将会晋升实现的难度。
- 优化很重要，尽管 Force.com 的多租户架构就像 Java 一样，采纳了很多动静生成的机制。很显然，如果像晚期的 Java 那样不足优化的话，那么 Force.com 整体的性能将会十分蹩脚，从而无奈实现其设计要求。但侥幸的是，Salesforce 团队不仅做了优化，而且凭借着其很多核心成员来自于 Oracle 的背景，在数据库端做了很多高水平的优化，比方增加了很多貌似累赘的 Pivot 表来放慢局部罕用数据的读取。
- 人才很重要：通过本系列的介绍，能够看出 Force.com 的整个架构并不全是在现有的框架和库的根底上构建的，而是为了设计指标开发了很多比拟底层和比较复杂的模块，而且这些模块是只有那些顶级的程序员能力编写进去的，所以说如果没有硅谷那个宏大的优良程序员池，Salesforce 就很难走到明天。
- 软件是一个进化的工程：刚开始的时候 Salesforce 架构是普普通通的 B/S 架构，然而随着用户一直地提出定制化的要求，Salesforce 也不得不在架构中引入多租户的概念，之后，因为用户须要更灵便的，可伸缩的和性能更弱小的平台，导致 Salesforce 一直地对其架构进行重构，到最初，终于整出了 Force.com 这一优良的 PaaS 平台。
- 有用的翻新才宝贵：Salesforce 不仅在 Force.com 引入很多翻新，而且都十分无效。在这些翻新当中，最有用的除了 Metadata 驱动这种多租户架构实现机制之外，还有一个名为 ” 回收站（Recycle Bin）” 的概念，这个回收站次要存储 30 天来那些从数据表外面删除的数据，如果用户在 30 天内发现数据是误删，能够对数据进行复原，这样既减低数据误删的可能性，而且能回收局部物理资源，比方硬盘空间等。
若有播种，就点个赞吧
