Force.com的多租户架构 [转]

由于Force.com所负载的应用不论是在定制方面的灵活性上,还是所承受的负载上,对基于多租户的架构而言,都是史无前例的,导致之前提到的一些模型或者改动已经无法满足要求了,所以Salesforce在Force.com引入了通过Metadata(元数据)驱动的多租户架构来动态生成快速的,可伸缩的和可定制的应用。接下来,将一步步为大家揭开Force.com多租户架构的神秘面纱,首先是它的总体架构。

 

总体架构

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

 Force.com architecture

图1. Force.com的架构图

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

接下来,将介绍Force.com是如何通过Metadata来动态生成和定制应用的。

 

Metadata驱动

首先,Force.com的Metadata是基于大家非常熟悉的面向对象的概念,所以也可以把Metadata认为是对象,也就是说Force.com是由一个个对象组装而成,而且Force.com中的对象可以是表格,也可以是UI,甚至可以是用户权益等。一个Force.com的对象和这个对象下面的字段可以对应一个数据库的表和这个表的列,而且Force.com对象之间的关系(relationship)在功能上类似于数据库的引用完整性約束(referential integrity constraint),但与数据库中每个数据库表对应于独立的存储地址不同的是,Force.com使用几个共享的大数据库表来作为堆存储(heap storage)来放置所有对象,另外这些存储Metadata的表也被称为“UDD(Universal Data Dictionary)”。

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

Virtual App

图2. 虚拟应用模块图(源自参[1])

还有,虽然Metadata驱动这种和Java很类似的动态生成机制在速度上有天生缺陷,但是Force.com也内置与Sun的Hotspot技术有异曲同工之妙的Metadata Cache来加速常用Metadata的读取。

下面,将分别介绍Force.com的两大组成部分:应用服务器和共享数据库。

 

应用服务器

Force App Arch

应用服务器主要包括五大核心模块:

  1.  
    1. Metadata Cache:用于存放那些最近用到的和比较常用的Metadata来加速应用的生成。
    2. 大规模数据处理引擎:主要用来加速处理大量的数据读写和在线事务。
    3. 多租户感知的查询优化引擎:这个引擎将通过维护多租户的信息来帮助Oracle自带的基于成本的查询优化器更好地适应多租户环境。
    4. 运行时应用生成器:这个生成器主要根据用户的请求来动态生成应用,并且利用上面提到的查询优化引擎来提升效率。
    5. 全文检索引擎:在数据库对数据进行更新的同时,这个引擎会异步更新这个数据的相关索引。

 

 

共享数据库

Force DB Architecture

图1. Force.com的架构(图源自参[1])

整个共享数据库主要有三种类型的数据库表:

  1.  
    1. Metadata表:主要存放用户定制的对象和对象所包含的字段的结构信息,也被称为“UDD”。
    2. 数据表:主要存储那些用户定制的对象和对象所包含的字段的数据。
    3. Pivot表:用来维护那些用于检索(indexing),唯一性和关系等denormalized (去规范化)数据以优化系统的效率。

 

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

 

大规模数据处理引擎

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

 

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

大多数现在数据库都自带基于成本的查询优化器,这种优化器主要是基于数据库表和索引数据等相关数值来进行计算和比较。但是由于传统的基于成本的优化器都是主要为单租户的环境设计的,所以他们并不能很好地适应多租户的环境,因为在数据库中是没有多租户这个概念。为了让优化器能够在多租户环境下良好工作,Salesforce在Oracle自带优化器的基础上搭建了一个多租户感知的查询优化引擎,它也主要有两个特点:其一是这个引擎为每个多租户对象维护了一整套便于优化的数据(租户层的,组层的和用户层的)。其二是这个引擎也维护租户和租户下面用户的安全信息,这样不仅能提升了效率,因为能避免将那些不属于这个租户的数据加入到计算,而且能提升数据的安全性。

 

全文检索引擎

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

 

数据库表的设计

下图为Force.com的数据库表结构:

Force com Database

图1. 数据库表的结构(图源自参[4])

Metadata表

Metadata表的作用是存储用户定制的对象和对象所包含的字段的结构信息,不保存具体的数据,主要有两大类:

  1.  
    1. Object Metadata表:这个表主要存储对象的信息,其中主要字段包括对象的ID(ObjID),拥有这个对象的租户的ID(OrgID)和这个对象的名字(ObjName)。
    2. Field Metadata表:这个表主要存储对象附带字段的信息,其中主要字段包括字段的ID(FieldID),拥有这个字段的租户的ID(OrgID),这个字段的名字(FieldName),这个字段的数据类型(datatype)和一个布尔字段(IsIndexed)来定义这个字段是否需要被检索。

 

Data表

Data表的作用和Metadata表正好相反,它主要存储那些用户定制的对象和对象所包含的字段的数据,主要也包括两大类:

  1.  
    1. Data表:这个表放置着上面那些对象和字段所对应的数据,核心字段有全局唯一的ID(GUID),租户ID(OrgID),对象的ID(ObjID)和存放对象名字的“Nature Name(自然名称)”,比如这行和一个会计对象有关,这行的““Nature Name”字段可能是“Account Name”,除了这些核心字段之外,这个表还有名字从Value0到Value500的501个数据列来存储数据,而且这些列都是varchar的形式来承载不同类型的数据,这种数据列也被称为“flex列”。
    2. Clob表:这个表主要存放那些CLOB(Character Large Object,字符大对象)数据,对象最大支持到32000个字符。

 

Pivot表

Pivot表,也称为“数据透视表”,在Force.com中是以denormalized (去规范化)格式存储那些用于特殊目的的数据,比如用于检索(indexing),唯一性和关系等,主要作用是加速这些特殊数据的读取以提升系统整体的性能。主要有五种Pivot表:

  1.  
    1. Index Pivot表:由于Data表里面数据都是以“flex列”的形式存储,所以很难在Data表的基础上对表中的数据进行检索,所以Force.com引入Index Pivot表来解决这个问题,系统在运行的时候会将需要索引的数据从Data表同步到Index Pivot表中相对应的字段来方便检索,比如这个数据的类型是日期型的,那么它将会被同步到Index Pivot表中的日期字段。
    2. UniqueFields Pivot表:这个表是用来帮助系统在Data表中字段实现唯一性。
    3. Relationships Pivot表:Force.com提供了“Relationship”这个数据类型来定义多个对象之间的关系,而Relationships Pivot表则起到方便和加速“Relationship”数据读取的作用。
    4. NameDenorm表:是一个简单的数据表用于存储对象的ID(ObjID)和这个对象的实例的名字,主要让一些仅需获取名字的查询调用,从而让一些简单的查询无需查询规模庞大的Data表。
    5. FallbackIndex表:这个表将记录所有对象的名字,来免去成本高昂的“UNION”操作,从而加速查询。

 

 

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的应用。