作者文章: Fenng

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

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

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

总体架构

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

图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–

剖析Force.com的多租户架构（2）- 多租户的介绍

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

本文将首先介绍一下多租户的概念和多租户的优缺点，之后会讲解几个常见的多租户模型。

概念

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

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

多租户和多用户的区别

多用户的关键点在于不同的用户拥有不同的访问权限，但是多个用户共享同一个的实例。而在多租户中，多个组织使用的实例各不相同。

多租户和虚拟化的区别

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

优缺点

多租户的优点：

经济：因为通过一个软件实例被多个组织共享，从而减低了整体资源的消耗，也同时减低应用运行的成本和相应的管理开支。
易于更新和开发：因为所有组织都共享同一套核心代码，所以能够让软件更新和开发更简单。
管理方便：首先，通过使用了多租户架构能减少物理资源和软件资源，这将简化管理。其次。由于多租户软件主要由有经验的云供应商运营，所以能依赖那些非常经验的管理人员来提升效率。

多租户的缺点：

更复杂：由于一个软件需要做出极大地修改，才能支持多租户架构，而且这种修改，往往会增加整个软件在架构方面的复杂性。
不够安全：因为众多组织的应用和数据共享同一套软件和基础设施，如果出现机器宕机，软件出现问题或者大规模的数据被暴露等情况，将会造成更严重的后果，因为影响面更大。

几种模型

在现有的实现中，主要有三种常见的模型，而且区别主要在于采用不同的数据库模式（Database Schema）：

私有表（图1-a）：它是最简单的扩展模式，就是为每个租户的自定义数据创建一个新表。优点是简单。缺点是涉及到高成本的DDL操作，并且它的整合度不高。
扩展表（图1-b）：总体而言，比较类似于私有表，但是一个扩展表会被多个租户共享，所以无论是共享表还是基本表都会有租户栏位。好处是比私有表更高的整合度和更少的DDL操作，但是在架构上比私有表更复杂。
通用表（图1-c）：主要通过一个通用表来存放所有自定义信息，里面有租户栏位和许许多多统一的数据栏位（比如500个）。像这种统一的数据栏位会使用非常灵活的格式让转储各种类型的数据，比如VARCHAR。由于在每一行中的数据栏位都会以一个Key一个Value形式存放所有自定义数据，导致通用表的行都会很宽，而且会出现很多空值，所以通用表这种方式也被称为”Sparse Column”。好处是极高的整合度并避免了DDL操作，但是在处理数据方面难度加大。

multi modes.PNG

图1. 多种模式（图源自参[7]）

差异与取舍

模型	机制	优点	缺点
私有表	为每个租户的自定义数据创建一个新表	简单	需要DDL操作，低整合度
扩展表	一个扩展表会被多个租户共享	高整合度，少DDL操作	有点复杂
通用表	通过一个通用表来存放所有自定义信息	极高整合度，无DDL操作	实现难度高

在实战中，具体选择那个模型，主要还是看那个模型更适合。

关于多租户的介绍已经基本结束了，下一篇将详细介绍Force.com的多租户架构。

–EOF–

本系列文章列表

国内互联网的”轻”模式与”王兴效应”

轻模式

和一些朋友的聊天中，我有好几次说国内的一些快速成长的”轻模式”的网站可能会给一些”次传统”模式的网站带来致命的冲击。

行业	轻模式	次传统模式
社区	豆瓣 (Douban.com)	天涯 (Tianya.cn)
旅游	途牛(Tuniu.com)	携程 (Ctrip.com)
房产	安居客 (anjuke.com)	搜房 (Soufun.com)
游戏平台	4399 (4399.com)	盛大游戏 (Shandagames.com)

这个表格其实还可以列举出来一些内容的。至于什么是”轻模式”与”次传统”，这里也没办法给出更详细的解释，可能大家端详一下上面这个表格就差不多明白了，可意会不可言传。”轻模式”的网站重视技术与业务运作灵活性，而”次传统”网站则业务为主导，较多依赖传统渠道带来的优势。所以，选择创业的时候不妨考虑一下你做的业务能否革掉哪家网站的命。

以上观点平媒请勿抄袭。当然，这个只是我个人的一点看法而已(延伸参考 Tim O’Reilly 在 What is Web 2.0 大作中列出的那个著名的表格)。

王兴效应

我前一段时间在 Twitter 上看开玩笑定义了一下”王兴效应”，没想到这个说法不胫而走。原话是这样的：

我觉得中文互联网应该弄一个”王兴效应”，就是王兴同学要做哪一类型的网站，这一类型的网站就要火，而且离后续跟进者胜出就不远了。(refer Twitter)。

王兴做校内，成就了开心网；做饭否，成就了新浪微博；这次做团购，不知道会成就谁。当然，不排除成就他自己。

–EOF–

米团团购iPad以及iPad初体验

从米团( http://mituan.com ) 团购的 iPad 到手了。团购价格是 3999，可以用”米粒”（邀请用户注册可以获得”米粒”）作折价券，整体下来还是蛮划算的，最后花了 RMB 2999，省了不少钱。团购的一个小技巧是要提前把钱充入自己在米团的账户，否则到时候临时充值的话就比较耽误时间了，值得注意的是，网银或者支付宝到帐可能会滞后几分钟的。估计有朋友因为这个问题而扼腕长叹了吧。

其实团购不是拼价格战，米团这次算是自己贴钱营销吧。应该说，整个团购过程很靠谱，第二天就给我来电话确认发货地址。机器到手后，欣赏的过程中出了一点插曲，iPad 屏幕那张默认的”流星雨”的图片让我误认为屏幕被划了，线上联系了米团客服同学，二话没说答应给换。这个小乌龙让我很不好意思。

数天前第一次体验贝塔咖啡几位朋友买的 iPad ，给我的第一个感觉并不是太好，对虚拟键盘很不习惯–或许是习惯了 iPhone 上比较小的虚拟键盘的缘故，面对大一点的键盘反而不适应。我之所以喜欢上 iPad 居然是因为一款游戏，我说的不是植物大战僵尸，而是 Zombie Attack!

，这是一款 3D 塔防类游戏，我这个很少玩游戏的人居然被 iPad 带来的方便灵活的交互能力给镇住了，iPad 绝非简单的大号 iPhone ，全新的体验(屏幕大的确能带来很多新的体验)让我爱不释手。

当然，买这台机器的初衷不是为了玩游戏。对我而言，这个设备的功能主要有三个：电子邮件(Gmail)、Twitter、地图(Google Map)。iPhone 毕竟屏幕太小了，处理这三个应用有其短板，而笔记本背着又太重了。对于 iPad 的电子书功能，我还没有体验，稍后再说。

如果说有什么我不太满意的地方，可能就是必须依赖 Wi-Fi 才可以上网吧(笑，当然，我没期望用来打电话)。接下来期待什么时候米团来一次 iPad 3G 版的团购吧，当然，价格不奢望还这么优惠了，适度即可。

–EOF–