剖析Force.com的多租户架构（3）- Force.com的多租户架构（上）

按：此为客座博文系列。投稿人吴朱华，曾在IBM中国研究院从事与云计算相关的研究，现在则致力于研发下一代云计算系统，撰写一些与云计算相关的文章，他的个人站点: PeopleYun.com。(文章版权属于原作者，转载请勿混淆。本篇原文地址)

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

总体架构

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

Force com Architecture new.PNG

图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.png

图2. 虚拟应用模块图（源自参[1]）

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

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

应用服务器

Force App arch.png

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

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

共享数据库

Force DB arch.PNG

图1. Force.com的架构（图源自参[1]）

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

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

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

本篇结束，下篇将主要对应用服务器内部的一些模块（比如查询优化引擎，外部全文检索引擎等）和数据库表的设计进行详细的描述。

本系列文章列表

–EOF–


Leave a Reply

Your email address will not be published. Required fields are marked *