我的《云计算核心技术剖析》读书笔记之多租户的介绍及Force.com的多租户架构

概念

虽然对我们而言，多租户町以算是一个非常新颖的槪念，但是这个槪念其实已经由来已久 了。简单而言，多租户指的就是一个单独的软件实例可以为多个组织服务。一个支持多租户的 软件需要仵设计.h能对它的数据和配置信息进行虚拟分区，从而使得毎个使用这个软件的组织 都能用到一个单独的虚拟实例，并且可以对这个虚拟实例进行进一步的定制。佴是要让一个软 件支持多租户并非易亊，因为不仅要对它的软件架构进行相应的修改，而且要对它的数据库结 构进行特殊设计，N时在安全和隔离性方而也要有所保障。

为了帮助大家进一步理解多租户这个槪念，特别选取两个和多租户比较接近的槪念来进行 进一步分析。

1. 多租户和多用户的区别

多用户的关键在于不N的用户拥有不同的访问权限，但是多个用户共享同-个实例。而在 多租户中，多个组织使用的实例就算是同一个，也会存在一定的差异。

2. 多租户和虚拟化的区别

多租户和虚拟化在概念上比较类似，都是给每个用户一个虚拟的实例，并且都支持定制化， 但是它们作用的M次不间，虚拟化主要是虚拟出一个操作系统的实例，而多租户则主要是虚拟

出一个应用的实例。

多租户技术的优缺点

1. 多租户技术的优点_

在优点方面，多租户技术主要在下面这3个方面具有一定的优势。

□经济。因为一个软件实例能被多个组织共享，所以降低了整体资源的消耗，也同时降低 了应用运行的成本和相应的管理开支。

□易于更新和开发。因为所有组织都共享同一套核心代码，所以能够让软件更新和开发更 简单。

□管理方便。首先，使用多租户架构能减少物理资源和软件资源，这将简化管理。其次， 由于多租户软件主要山有经验的云供应商运营，所以能依赖那些非常有经验的管理人员 来提升效率。

2. 多租户技术的不足之处

和其他技术一样，多租户技术也有一些不尽如人意的地方，具体如下所示。

□技术复杂。一个软件需要作大量修改才能支持多租户架构，而且这种修改往往会增加整 个软件在架构方面的复杂性。

□不够安全。因为众多组织的应用和数据共享了同一套软件和基础设施，所以如果出现机 器宕机、软件出现问题或者大规模的数据被暴露等情况，将会造成更严重的后果。

常见的多租户模型

在现有的实现中，主要有3种常见的多租户模型，它们之间的区别主要在于其底层采用的 数据库模式。

1. 私有表

它是最简单的扩展模式，就是为每个租户的自定义数据创建一个新表。优点是简单。缺 点是涉及高成本的DDL (Data Definition Language，数据定义语句）操作，并且它的整合度

不高。

2. 扩展表

总体而言，扩展表比较类似于私有表，但是一个扩展表会被多个租户共享，所以无论是共 享表还是基本表都会有租户栏位。扩展表比私有表有更髙的整合度和吏少的DDL操作，但是 在架构上比私有表更复杂。

3. 通用表

通用表主要用来存放所有自定义信息，里面有租户栏位和许许多多统一的数据栏位（比如 500个)。这种统一的数据栏位会使用非常灵活的格式转储各种类型的数据，比如Varchar。由 于每一行中的数据栏位都会以一个键、一个值的形式存放所有自定义数据，这样通用表的行都 会很宽，而且会出现很多空值，所以通用表这种方式也被称为稀疏列。其好处是具有极高的整 

合度并避免了 DDL操作，但是在整体实现方面难度加大。

在实战中，具体选择哪个模型，主要还是看哪个模型更适合。下面将分两节深入介绍 Force.coai的多租户架构。

Force.com的多租户架构（上）

由干Force.com所负载的应用不论是在定制的灵活性上，还是在所承受的负载上，对多租 户架构而H都是史无前例的，这导致之前提到的一些模型或者改动已经无法满足要求了，所以 Sa丨csforce在Force.com中引入了通过元数据驱动的多租户架构来动态生成快速的、可伸缩的和 可定制的应用。接下来，将一步步为大家揭开Force.com多租户架构的神秘面纱。首先介绍一 下它的总体架构，接着介绍Metadata驱动，最后介绍Force.com的两大组成部分。

总体架构

在介绍Force.com的整个架构之前，请看图4-2,它是根据Salesforce首席架构师Craig Wdssman在2009年旧金山QCon大会上的演讲总结而成的。

首先，最前面是网关，它将接受所有汸问Force.com的请求，无论它是访问Sales Cloud, 还是关于第三方定制程序的。接下来，网关会根据这个请求所属的租户把请求转发给对应的 POD。那么什么是POD呢？简单地来说，P0D就是一组集群服务器，每个POD都运行一整 套Force.com系统，而且每个POD支持成千上万个租户。Salesforce现有10多个POD来支撑 它所有服务的运营，并把所有租户平衡地分配给每个P0D，而且主要通过建立新的POD来支 撑新的租户。当POD收到淸求之后，它会先通过其内置的负载均衡器来将请求转发给负栽略 轻的应用服务器。为了简化架构和方便伸缩，应用服务器是无状态的，而且在一个POD内会 有多个应用服务器以应对大规模的请求。最后，当应用服务器在处理请求的时候，如果发现请 求所需的数据没有被缓存的话，应用服务器会调用这个租户所属的共享数据库来取得相关数 据。虽然共享数据库是使用成熟的Oracle数据库产品，但是在数据库表的设计上为多租户作 了很多优化工作。 

元数据驱动

首先，Forcexom的元数据基于大家非常熟悉的面向对象的槪念，所以也可以认为元数据 是对象。也就是说，Force.com是由一个个对象组装而成的，而且Force.com中的对象可以是表 格，也可以是UI,甚至可以是用户权限等。一个Force.com的对象和这个对象下面的字段可以 对应一个数据库的表和这个表的列，而且Force.com对象之间的关系在功能上类似于数据库的 引用完整性约束。但与数据库中每个数据库表都对应于独立的存储地址不同的是，Force.com 使用几个共享的大数据库表来作为堆存储来放置所有对象，而这些存储元数据的表也被称为 UDD (Universal Data Dictionary，通用数据字典）。

接若，是关于应用的。一个在Force.com上运行的应用实例是通过组合许许多多个对象来 生成的，也可以说一个应用实例是使用元数据来描述的。比如在应用初始的时候，每个客户都 使用同一个版本和同样规模的对象，而且用户通过添加和更:新对象来定制应用，比如增加新的 UI和字段等，同时系统会对共享的和定制的对象进行严格分离，这样既能非常方便地更新共享 代码，也能保证某个用户定制过的部分不会影响到其他用户。在实现上，Forcc.com实际上并 没有为-个新对象生成一个数据库表，而是以元数据的形式存储在几张大表中。在运行时， Force.com使用一整套引擎分析数据库中的元数据来动态生成一个虚拟应用实例和这个应用所 需的模块，比如公共UI、定制UI和其他对象等。

还有，虽然元数据驱动这种和Java很类似的动态生成机制在速度上有天生缺陷，但是 Force.com也内置有与Sim的Hotspot技术有异曲同工之妙的元数据缓存來加速常用元数据的读取。

应用服务器

应用服务器主要用于处理用户大量的请求，如图4-3所示的那样，共包括5大核心模块。

□元数据缓存。用于存放那些最近用到的和比较常用的元数据，加速应用的生成。 □大规模数据处理引擎。主要用来加速处理太S的数据读写和在线事务。 

□多租户感知的查询优化引擎。这个引擎将通过维护多租户的信息来帮助Oracle自带的 基于成本的査询优化器更好地适应多租户环境。

□运行时应用生成器。这个生成器主要根据用户的请求来动态生成应用，并且利用上面提 到的査询优化引擎来提升效率。

□全文检索引擎。在数据库对数据进行更新的同时，这个引擎会异步更新这个数据的相关 索引。

共享数据库

整个共享数据库主要由3种类型的数据库表——元数据丧、 数据表和数据透视表组成，如图4-4所示。

还有，在物理层面，数据库里面的所有表格（包括底下的 索引）都会根据不同的租户ID (OrgID)来使用Oracle的散列 分区技术。通过散列分区技术，能够将大规模的数据平均地分 割成多个更小的、更容易管理的分块，从而帮助大数据库系统 能够在多租户的环境下提升速度、伸缩性和可用性等。

 Force.com的多租户架构（下)

本节是上节的延续，并对前尚提到的几个模块进行进一步介绍和分析。

一、应用服务器的模块

在应用服务器方面，主要将深入介绍其中3个模块，它们分别是大规模数据处理引擎、多 租户感知的查询优化引擎和全文检索引擎。

1. 大规模数据处理引擎

由于Force.com需要处理的数据量（不论是来自网页端，还是来自Web服务端）都是非常 巨大的，所以Salesforce在Force.com中引入了特制的大规模数据处理引擎来处理大量的数据读 写和在线事务。它土要有两大特点。-其一是对大规模数据处理进行了优化，特别是当一个API 调用发来很多待处理的数据时，这个引擎能非常快速地处理。艽二是这个引擎内置锆误恢复机 制，当处理大规模数据时，假如其中一个步骤发生错误，这个引擎会捕捉和修复这个错误，并 且保存这个步骤之前的正确结果以避免整个操作重做。

2. 多租户感知的查询优化引擎

现在的数据库大多都自带基干成木的査询优化器，这种优化器主要基于数据库表和索引数 据等相关数值来进行计算和比较。但是由于传统的基于成本的优化器都是主要为争租户环境设 计的，所以它们并不能很好地适应多租户的环境。为了让优化器能够在多租户环境下良奸工作, Salesforce在Oracle自带优化器的基础上搭建了一个多租户感知的査询优化引擎。它主要冇两  

个特点.•其-是这个引擎为每个多租户对象维护了一整套便于优化的数据；其二是这个引擎也 维护租户和租户下面用户的安全信息，这样不仅能提升效率（因为能避免将那些不厲于这个租 户的数据加入到计算中），而且能提升数据的安全性。

3. 全文检索引擎

对Web应用而言全文检索功能可以算是一种基本功能，而对基于Forcexom的应用而言， 同样如此。Force.com为此内置一个全文检索引擎，它基于大名鼎鼎的Lucene技术。当一个运 行在Force.com平台上的应用对数据库中的数据进行更新时，会有一组称为检索服务器的后台 进程来异步更新数据相关的索引。通过这种异步机制，不仅能够保证检索工作不影响处理事务 的效率，而且同时也能让用户用到最新的搜索结果。为T优化这个检索流程，系统会同步将修 改过的数据复制到-个内部“等待检索”的表，之后检索服务器会访问这个表来进行检索，这 样做的好处是减少了检索服务器的I/O处理S。为了更好地适应多租户环境，检索引擎自动为 每个租户维护一个独立的索引。

二、数据库表的设计

就像上节所介绍的那样，Force.com的共享数据库主要由元数据表、数据表和数据透视表 组成，接下来，将对这3种类型的数据表进行深入的介绍。

1. 元数据表

元数据表的作用是存储用户定制的对象和对象所包含的字段的结构信息，不保存具体的数 据。在运行的时候，系统会读取元数据表来生成应用。元数据表主要有两大类：其一是对象元 数据表，这个表主要存储对象的信息，其主要字段包括对象的ID (ObjlD)、拥有这个对象的 租户的ID (OirgID)和这个对象的名字（ObjName);其二是字段元数据表，这个表主要存储对 象附带字段的信息，其主要字段包括字段的ID(FieldlD)、拥有这个字段的租户的丨D(OrglD)、 这个字段的名字(FieldName)、这个字段的数据类型(datatype)和一个布尔字段（Islndexed) (用来定义这个字段是否需要被索引）。

2. 数据表

数据表的作用和元数据表正好相反，它主要存储那些用户定制的对象和对象所包含的字段 的数据。主要包括两大类。首先是Data表，这个表中放置着上面那些对象和字段所对应的数据。 核心字段有全局唯一的ID (GUID)、租户ID (OrglD)、对象的ID (ObjID)和存放对象名字 的“自然名称”（NatureName),比如这行和一个会计对象有关，这行的“自然名称”字段可能 是AccountName,除了这些核心字段之外，这个表还有名字从valueO到value500的501个 数据列，它们用来存储数据，其中valiieO对应字段元数据表中这个对象所设定的第一个字段， 之后依次类推。另外，这些列都是用varchar的形式来承载不同类型的数据的，这种数据列也 被称为“灵活列”。也就是说，无论数据表的数据在系统中是以何种形式存在的，但在数据库中 总会以Varchar的形式存在。其次是Clob表，这个表主要存放那些CLOB (Character Large Object,字符大对象）数据。对象最大支持32 000个字符。

3. 数据透视表

数据透视表在Forcexom中是以去规范化格式存储那些用于特殊目的的数据的，主要作用 是加速这些特殊数据的读取以提升系统整体的性能，也就是给系统提供某种“短路径”。以索引 数据透视表为例，由于数据表里面的数据都是以“灵活列”的形式存储的，所以系统在运行的 时候会将需要索引的数据从数据表同步到索引数据透视表中相对应的字段来方便索引，比如这 个数据的类型是整型的，那么它将会被同步到索引数据透视表中的整型字段。

在Force.com的数据库中，主要有下面几种数据透视表。

□索引数据透视表。具体细节上面已经提到了。

口唯一字段数据透视表。这个表用来帮助系统在数据表中实现字段的唯一性。

□关系数据透视表。Force.com提供了“关系”这种数据类型来定义多个对象之间的关系, 而关系数据透视表则起到方便和加速“关系”相关数据的读取。

□去规范化名称表。它是一个简单的数据表，用于存储对象的ID (ObjlD)和这个对象的 实例的名字，主要让一些仅需获取实例名字的査询调用，从而让一些简单的查询无需查 询规模庞大的数据表。

为了数据安全，整个系统的权限粒度应该是行级的，因为很多表（包括元数据表和数据表) 都有租户ID (OrgiD)这个字段，所以可以依据租户的设定来给每行设置不同的权限。

三、Apex

Apex语言是为Force.com量身定做的-门语法上类似Java的强类型面向对象语言。主要可 以通过Apex在Force.com上创建Web服务，编辑复杂的商业逻辑和整合多个Forcc.com的模块 等。Apex主要以两种方式执行：其一是以单独脚本的形式，按照用户的需求来执行；其二是以 触发器的形式，当一个特定的数据处理事件发生之前或者之后，与这个事件绑定的Apex代码 将会被执行。同时所有Apex代码将会以元数据的形式存储在元数据表内。当一段Apex代码被 调用的时候，Apex的翻译器（Runtime Interpreter)将会从元数据缓存中读取编译之后的Apex 代码，而且这些编译之后的代码能够同时被多个租户共享以提升效率。

那么为什么要在Force.com中引入Apex这门新的语言，而不是像Google App Engine那样 支持Q经有一定市场占有率的语言（比如Java和Python)呢？ Salesforce的首席架构师在谈到 这点时，提出了一个非常重要的原因，那就是安全.•首先，Salesforce会为Apex语言量身设计 一组管理工具。通过这个工具，能够非常方便地监控Apex脚本的执行，并且能知道这个脚本 在执行过程所耗费的CPU时间、内存容董和SQL语句的数量等，从而可以判断是否需要中断 这个Apex脚本的执行，以避免影响到其他租户的应用。如果中断的话，系统会抛出一个运ft 时异常给上层的调用者。艿次，基于Apex语言的代码能够对其内嵌的SOQL (Salesforce ObjectQuery Language, Salesforce 对象査询语言）和 SOSL (Salesforce Object Search Language, Salesforce对象搜索语言）进行验证来避免实际运行时出现错误。还有，在安全方面除了 Apex 自带的功能之外，Salesforce还要求每个上传到Forcexom的Apex脚本，都需要自带能覆盖其 75%代码的测试用例，这种做法不仅显著提升了 Apex代码的质量，从而确保平台整体运行的稳 定，而且在Force.com自己更新的时候，能使用这些用例来确保新的更新不会影响现有的基于 Force.com 的应用。

总结

在多租户架构方面，F〇rCe.C〇rn是一个非常不错的例子，不仅让我们领略了多租户的魅力， 而且同时也U：我们了解了实现一个多租户架构是多么不易。在本章最后，我将会根据一些官方 资料和个人的理解来总结一下Force.com的一些设计理念和经验教训。

一、设计理念

根据Craig Weissman的演讲和几份官方的I^皮书，在Force.com的设计方面，Salesforce 团队主要有下面这5大考量。

□数据驱动。由于Salesforce主要面向企业用户，其上面运行的应用（无论是CRM还是 报表工具）都是以数据的CRUD为核心，所以F〇rCe.c〇m需要由数据来驱动，而且也需 要为此作一定程度的优化。

□规模经济。由于需要在低价格和灵活付费的某础上提供可定制化的应用，所以需要让尽 可能多的用户共享同一套系统，来大幅降低甚础设施和管理等资源的投入，并实现规模 经济的效益。

□安全为先。由干在一套物理设备上将承载数以万计客户的企业级应用，如果出现严重的 程序错误或者在数据方面有遗失、错乱这类现象，将会发生非常严重的后果，所以安全 问题是一个Salesforce绝不能轻视的问题。

□定制方便。虽然各个企业都会存在一部分比较通用的流程，佴是每个企业都可能存在一 部分私有或者独特的流程，因此Force.com需要提供方便的定制功能来帮助用户更快捷 地将企业的业务迁移到其上。

□功能丰富。虽然用户能在Force.com上进行开发和定制，但是如果Force.com能提供 更多的功能模块或者能让用户购买和整合第三方的应用的话将非常有助于用户幵发 应用。

虽然这些设计理念说起来很容易，但是实现起来是非常艰难的。可贵的是，Salesforce团队 在开发Forcexom的过程中通过长时间不断地优化，已经基本实现了这些设计理念。

二、经验教训

虽然到现在为止，SalesforceForcexom还不能算是一个巨大的商业胜利，但是它在产品和 思路等方而有很多值得我们借鉴的地方，下面是其中的5点。

□权衡是难免的。为了满足设计目标，有时不得不做权衡。由于Salesforce所需要承载的

多租户应用的规模之大、定制化需求之髙都是前所未见的，所以Salesforce并没有采用 前面提到的几种常见模型，而是从长计议，采用了更灵活但技术要求吏高的元数据方式。 另外，为了避免在数据库中执行成本非常高并会锁住整个数据库的DDL操作，所以在 Force.com运行的时候无法创建和修改数据库表，而这将会提升实现的难度。

□优化很重要。Force.com的多租户架构就像Java—样，采用了很多动态生成的机制。很 显然，如果像早期的Java那样缺乏优化的话，那么Force.com的整体性能将会非常槽糕, 从而无法实现其设计要求。但幸运的是，Salesforce闭队不仅做了优化，而且凭借着其 很多核心成员来自于Oracle的背景，在数据库端做了很多髙水平的优化，比如添加了很 多貌似冗余的数据透视表来加快部分常用数据的读取。

□人才很重要。可以看出，Force.com的整个架构并不全是在现有框架和库的基础上构建 的，而是为了设计目标开发了很多比较底层、比较复杂的模块，而且这些模块都是只有 那些顶级的程序员才能编写出来的，所以说如果没有硅爸那个庞大的优秀程序员池的 话，Salesforce就很难走到今天。

□软件是一个进化的工程。刚幵始的时候，Salesforce架构是普普通通的BIT/S架构，但 是随着用户不断地提出定制化的要求，Salesforce也不得不在架构中引入多租户的概念。 之后由于用户需要更灵活的、可伸缩的和功能更强大的平台，Salesforce不断地对其架 构进行重构。最后终于研发出了 Forcexom这一优秀的PaaS平台。

□有用的创新才珍贵。Salesforce不仅在Force.com中引入很多创新，而且都非常有效。在 这些创新当中，最杳用的除了元数据驱动这种多租户架构实现机制之外，还有一个名为 “回收站”（Recycle Bin)的槪念。这个冋收站主要存储30天来那些从数据表里面删除 的数据，如果用户仵30天内发现数据楚误删，可以对数据进行恢复，这样既减低数据 误删的可能性，而且能回收部分物理资源，比如硬盘空间等。

虽然多租户架构不容易理解，同时也不易于实现，但是在很多情况下非常有竞争力，这点也在Force.com上得到了充分的证明。