分类归档: Arch

剖析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–

本系列文章列表

剖析Force.com的多租户架构（1）- Salesforce的简介

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

在云计算方面，Salesforce 可以称为业界的领袖，它不仅在产品方面比较成熟，而且在思维方面也是引领潮流的，特别是在SaaS（Software as a Service，软件即服务）和PaaS（Platform as a Service，平台即服务）这个两个领域内。

图1. Salesforce 商标（图源自Salesforce.com）

首先，简要地介绍一下Salesforce的历史：Salesforce.com在1999年由前甲骨文高管 Marc Benioff 创立，他创办Salesforce的核心理念就是”No Software（消灭软件）”，但是其意义并不是排斥所有的软件，而是主要排斥运行在企业数据中心的软件（On-Premise Software），也就是希望让用户能直接通过互联网来诸如CRM等软件服务，并同时让用户无需自己搭建和维护软件所需的硬件和系统等资源。Salesforce的主要产品包括Sales Cloud（CRM）、Service Cloud、Chatter和Force.com等。下面是它的主要发展史：

1999年，Salesforce在美国旧金山成立。
2001年，推出了第一款SaaS应用CRM，同时也受到众多厂商和客户的热议。
2004年，Sunguard成为Salesforce第1000位用户。
2005年，推出了名为”AppExchange”的程序商店，以丰富用户选择。
2006年，推出了首个运行在云计算平台的语言Apex，并在语法上类似Java。
2007年，推出了它的PaaS平台Force.com，来让用户更方便地在Saleforce平台上开发在线应用，同时Salesforce凭借Force.com得到了华尔街日报的科技创新奖（Technology Innovation Award）。
2009年，Salesforce成为首家年收入达到10亿美元的云计算公司，并在年初推出了名为”Service Cloud”在线客户服务应用。
2010年，Salesforce将推出名为”Chatter”的企业级在线SNS服务，类似于企业内部的”LinkedIn”，同时其CRM应用已更名为”Sales Cloud”。

Salesforce的整体架构

虽然Salesforce这些产品从表面而言有所不同，但是从全局而言，它们却是一个整体，具体可看下图：

Salesforce Architecture.PNG

图2. Salesforce的整体架构（图部分源自Salesforce.com）

从这张Salesforce的整体架构图可以看成，Force.com 是 Salesforce 整体架构的核心，因为它首先整合和控制了底层的物理的基础设施，接着给上层的Sales Cloud，Service Cloud，Chatter和基于Force.com的定制应用提供PaaS服务，最后，那些Force.com上层的应用以SaaS形式供用户使用。这样做的好处主要有两方面：其一是关于成本的，因为通过这个统一的架构能极大地整合多种应用，从而降低了在基础设施方面的投入。其二是在软件架构方面，因为使用这个统一的架构，使得所有上层的SaaS服务都依赖Force.com的API，这样将有效地确保API的稳定性并避免了重复，从而方便了用户和Saelsforce在这个平台上开发应用。

虽然Salesforce的”Sales Cloud”等SaaS应用也比较经典，但由于Force.com堪称整个架构的核心，同时也是最值得的学习和借鉴的部分，所以本系列接下来将会把重点对准Force.com。

Force.com

Force.com是Salesforce在2007推出的PaaS平台，并且已经有超过47000位企业已经使用了这个平台。Force.com基于多租户的架构，其主要通过提供完善的开发环境等功能来帮助企业和第三方供应商交付健壮的，可靠的和可伸缩的在线应用。

force.com logo.PNG

图1. Force.com 商标（图源自参[3]）

总体而言，Force.com主要有五方面功能：

强大的定制功能：在Force.com，不仅UI能够定制，而且诸如Workflow和表格等也能被定制。
提供完善的开发环境：首先，通过Visualforce能方便地使用”Drag & Drop”的方式来设计页面。其次，Salesforce提供基于Eclipse的IDE来快速地开发应用。最后，Salesforce还提供Sandbox来方便用户测试。
支持复杂的事务和流程：通过Force.com专属的APEX语言，能方便地设计和开发复杂的事务和流程。
优秀的整合功能：用户除了可以在AppExchange购买其所需的功能和应用，而且还可以通过Force.com的Web Service接口来和其他应用整合，比如SAP等。
久经考验的基础设施：由于Salesforce除了通过在多个大洲建有数据中心来应对灾难的发生，而且在可用性和安全性等方面也有一定积累，所以在Salesforce能长时间地支持众多服务的正常运行。

下一篇：《多租户的介绍》
–EOF–

本系列文章列表

QCon Beijing 后记

这次参加 QCon Beijing 2010 技术大会稍有点匆忙。23号早晨从杭州赶往北京，中午才到会场。25号下午原计划回杭州，结果因为天气原因没能成行，第二天上午才回来。在会场的时间安排的也比较紧凑，没时间整理，回到家里也是一堆事儿，一直没空出来时间写一下这次参会的感受。

到了会场就遇到不少熟人，也有网上熟悉但素未谋面的朋友，比如创建监控宝的郭欣，还遇到来自盛大创新院的不少朋友。每次会议都会结识新朋友，和老朋友叙旧，大家在一起开开玩笑，诉诉苦，也会宣布一下个人的一些动向。

下午在听了一场比较扯淡的演讲之后(据说25号还有一个某大厂更扯淡的广告话题)，重点听了一下豆瓣首席架构师洪强宁 (@hongqn)的《Python于Web 2.0网站的应用》
，这是一次很好的 Python 技术布道，尤其是后半段，由浅入深讲解了好几个应用场景实现的技巧。我后来看了网上的评论，发现不少人忽略了这些案例的重要性，有点惋惜。我在Twitter上说了一句，经过这次的布道，相信明年就会有更多的开发人员用 Python 了。豆瓣的技术团队对外策略挺有意思，老耿(@flycondor)说”把每个人都打造成技术明星”，期待更多豆瓣牛人出来分享。

第一天的技术演讲，偏重语言方面的内容。下午除了观摩老赵 (@jeffz_cn)的主持风格之外，更多时间是和场外的一些朋友进行交流。晚上和几个朋友赶到奇遇花园咖啡馆参加推友聚会，相当的热闹，相当的开心。和技术Geek们在一起就是有趣啊。透漏一下，各个团队似乎都在面临技术人才荒，而且大家都说”钱不是问题”。一个秘密：虽然我在Twitter上花了这么多精力，但是推友聚会还真是头一回参加。

24日起来的稍微晚了一点，只听到了半场 Facebook 的 Marc Kwiatkowski 的演讲，关于 Memcached 的，个人感觉内容较为平淡，可能之前和我大致了解了他要讲解的内容有关吧。然后认真听了一下 Twitter 大牛 Nick Kallen (@nk)的演讲，很过瘾，对 Twitter 的架构设计有了进一步了解。整个演讲几乎是围绕数据的处理场景进行的，符合我的技术胃口。现在能记住的也就是最后 Nick 总结的几个原则了，包括：Twitter 解决扩展问题依赖的是一些通用的技术手段(索引、分区、复制)；不要追求完美够用就行；实时查询的数据必须在内存中。具体的细节还要重新看一遍 PPT 与视频才好。

下午的事情是我这次参会的主要目的：主持人。第二次担任网站架构案例分析(CASE STUDIES)这个分会场的主持人，很有压力啊 :) 之前和演讲嘉宾的沟通没有像去年那么频繁，好在效率有保证，所幸，各位大牛的演讲 PPT 都是经过几次大规模修订，质量没得说。

第一场是潘磊介绍了阿里巴巴国际站架构以及镜像解决方案，以及相关经验。Alibaba.com 是国内少数横跨中美有多个 IDC 的公司，业务也有其独特的复杂性，印象中这是 Alibaba B2B 第一次对外分享技术经验，潘磊开了一个好头。接着旅游搜索引擎去哪儿(qunar.com)的 CTO 吴永强介绍了监控与虚拟化的实战经验，演讲完了我才知道因为当天凌晨有重要项目发布，老吴4点解决完了问题杀到的会场(创业公司相当辛苦啊)，下午结束后就回去休息了。人人网的黄晶介绍了 RenRen.com 的架构经验以及他们的开源项目，演讲结束后的提问可以看出大家对开源项目是相当有兴趣，问题差不多都问到了点子上。最后是来自新浪的杨卫华 (Tim Yang , @xmpp) 介绍可扩展的微博架构，也是相当精彩，和上午 Twitter 的演讲刚好互补。作为主持人，其实最担心自己场地内的人少… 另外的场地同时和这边 PK 的有淘宝章文嵩博士的技术演讲，还好，我偷着去看了一下，两边会场人数平分秋色。Tim 之前的精心准备很值得。

再次利用主持人的便利鼓动大家支持技术图书出版行业，也帮着会场外面的多背一公斤宣传了一下。

说说 24 号晚场的技术沙龙吧。最近自己似乎有转向娱乐圈的趋势，在前一段时间的数据库会议上客串了一次技术沙龙的主持人的活儿，不到一个月，这又硬着头皮做了一回主持人。老实说，做这样的事情对我来说是挺煎熬的。前20分钟，自己也感觉比较平淡；中间阶段互动问答也稍微有点温吞；后半段讨论到各公司的开源项目的时候才真的有感觉了。会上不少公司都非正式的宣布了接下来都会有一些开源项目要回馈给社区，其实也是各家公司对于开放(Open)的认识与认同。要感谢参加沙龙的各位嘉宾以及一起参与互动的各大公司的朋友们! 这是一个美妙的夜晚。

25 号这一天，下午要赶着回去，淘宝赵泽欣（小马，@zhaozexin）的演讲《淘宝网前端应用与发展》没有听完就走了，挺遗憾。这里透漏一个趣事：我在会场里看到小马的时候差不多都是在改进自己的 PPT，可能这也是 UED 人的一个特质吧。

出于技术方向的原因，这次会议也错过了好几场很重要的演讲，像邓草原( @dcaoyuan )大侠布道Scala与Erlang、熊节( @gigix )分享敏捷改造的经验、蔡学镛(@KongXuan)分享复杂事件处理(CEP)等等话题，听多位朋友的反馈都是非常的好。 Douglas Crockford 的压轴演讲据说也是相当的精彩，从 Twitter 上的火爆讨论可见一斑。

恭贺 InfoQ 成功举办了这次技术盛会。600 余技术人济济一堂。感谢泰稳 @taiwen)的努力。

自己的另外一个感慨是，英语交流能力太差了，错过了和国外技术大牛的深入交流。

总算一点点写完了这次 QCon 的流水帐。对于墙内的用户，建议也不妨翻墙搜索一下 Twitter 上 #QCon 的内容，不同人眼中的 QCon 是怎样的，非常有趣。经过我的测试，用 Dabr 的代理似乎搜索 HashTag 快一点（你懂的)。

下一次 QCon 我会以另外的身份参加了。

–EOF–

如果你也是 QCon 参会者且是 Twitter 用户，不妨参加一下这个”QCon Beijing 参会推友小调查“(非官方)