剖析多租户-SaaS-PaaS.doc

1 Salesforce 的简介的简介在云计算方面，Salesforce 可以称为业界的领袖，它不仅在产品方面比较成熟，而且在思维方面也是引领潮流的，特别是在 SaaS（Software as a Service，软件即服务）和PaaS（Platform as a Service，平台即服务）这个两个领域内图 1. Salesforce 商标（图源自 S）首先，简要地介绍一下 Salesforce 的历史：S 在 1999 年由前甲骨文高管 Marc Benioff 创立，他创办 Salesforce 的核心理念就是“No Software（消灭软件）“，但是其意义并不是排斥所有的软件，而是主要排斥运行在企业数据中心的软件（On-Premise Software），也就是希望让用户能直接通过互联网来诸如 CRM 等软件服务，并同时让用户无需自己搭建和维护软件所需的硬件和系统等资源Salesforce 的主要产品包括 Sales Cloud（CRM）、Service Cloud、Chatter 和 F 等下面是它的主要发展史：1999 年，Salesforce 在美国旧金山成立 2001 年，推出了第一款 SaaS 应用 CRM，同时也受到众多厂商和客户的热议。

2004 年，Sunguard 成为 Salesforce 第 1000 位用户 2005 年，推出了名为“AppExchange“的程序商店，以丰富用户选择 2006 年，推出了首个运行在云计算平台的语言 Apex，并在语法上类似 Java 2007 年，推出了它的 PaaS 平台 F，来让用户更方便地在 Saleforce 平台上开发应用，同时 Salesforce 凭借 F 得到了华尔街日报的科技创新奖（Technology Innovation Award） 2009 年，Salesforce 成为首家年收入达到 10 亿美元的云计算公司，并在年初推出了名为“Service Cloud“客户服务应用 2010 年，Salesforce 将推出名为“Chatter“的企业级 SNS 服务，类似于企业内部的“LinkedIn“，同时其 CRM 应用已更名为“Sales Cloud“ 1.1 Salesforce 的整体架构的整体架构虽然 Salesforce 这些产品从表面而言有所不同，但是从全局而言，它们却是一个整体，具体可看下图：图 2. Salesforce 的整体架构 （图部分源自 S）从这张 Salesforce 的整体架构图可以看成，F 是 Salesforce 整体架构的核心，因为它首先整合和控制了底层的物理的基础设施，接着给上层的 Sales Cloud，Service Cloud，Chatter 和基于 F 的定制应用提供 PaaS 服务，最后，那些 F 上层的应用以 SaaS 形式供用户使用。

这样做的好处主要有两方面：其一是关于成本的，因为通过这个统一的架构能极大地整合多种应用，从而降低了在基础设施方面的投入其二是在软件架构方面，因为使用这个统一的架构，使得所有上层的 SaaS 服务都依赖F 的 API，这样将有效地确保 API 的稳定性并避免了重复，从而方便了用户和Saelsforce 在这个平台上开发应用虽然 Salesforce 的“Sales Cloud“等 SaaS 应用也比较经典，但由于 F 堪称整个架构的核心，同时也是最值得的学习和借鉴的部分，所以本系列接下来将会把重点对准F1.2 FF 是 Salesforce 在 2007 推出的 PaaS 平台，并且已经有超过 47000 位企业已经使用了这个平台F 基于多租户的架构，其主要通过提供完善的开发环境等功能来帮助企业和第三方供应商交付健壮的，可靠的和可伸缩的应用图 1. F 商标（图源自参[3]）总体而言，F 主要有五方面功能：强大的定制功能：在 F，不仅 UI 能够定制，而且诸如 Workflow 和表格等也能被定制 提供完善的开发环境：首先，通过 Visualforce 能方便地使用“Drag & Drop“的方式来设计页面。

其次，Salesforce 提供基于 Eclipse 的 IDE 来快速地开发应用最后，Salesforce 还提供 Sandbox 来方便用户测试 支持复杂的事务和流程：通过 F 专属的 APEX 语言，能方便地设计和开发复杂的事务和流程 优秀的整合功能：用户除了可以在 AppExchange 购买其所需的功能和应用，而且还可以通过 F 的 Web Service 接口来和其他应用整合，比如 SAP 等 久经考验的基础设施：由于 Salesforce 除了通过在多个大洲建有数据中心来应对灾难的发生，而且在可用性和安全性等方面也有一定积累，所以在 Salesforce 能长时间地支持众多服务的正常运行 2 多租户的介绍多租户的介绍2.1 概念概念虽然对我们而言，多租户(Multitenancy)可以算是一个非常新颖的概念，但是其实这个概念已经由来已久了简单而言，多租户指得就是一个单独的软件实例可以为多个组织服务一个支持多租户的软件需要在设计上能对它的数据和配置信息进行虚拟分区，从而使得每个使用这个软件的组织能使用到一个单独的虚拟实例，并且可以对这个虚拟实例进行定制化但是要让一个软件支持多租户并非易事，因为不仅对它的软件架构进行相应的修改，而且需要对它的数据库结构进行特殊的设计，同时在安全和隔离性方面也要有所保障。

还有，为了帮助大家进一步理解多租户这个概念，特别选取两个和多租户比较接近的概念来进行进一步的辨析多租户和多用户的区别多租户和多用户的区别多用户的关键点在于不同的用户拥有不同的访问权限，但是多个用户共享同一个的实例而在多租户中，多个组织使用的实例各不相同多租户和虚拟化的区别多租户和虚拟化的区别多租户和虚拟化在概念是比较类似，都是给每个用户一个虚拟的实例，并且都支持定制化，但是它们作用的层次不同：虚拟化主要是虚拟出一个操作系统的实例，而多租户则是主要虚拟出一个应用的实例2.2 优缺点优缺点多租户的优点：经济：因为通过一个软件实例被多个组织共享，从而减低了整体资源的消耗，也同时减低应用运行的成本和相应的管理开支 易于更新和开发：因为所有组织都共享同一套核心代码，所以能够让软件更新和开发更简单 管理方便：首先，通过使用了多租户架构能减少物理资源和软件资源，这将简化管理由于多租户软件主要由有经验的云供应商运营，所以能依赖那些非常经验的管理人员来提升效率 多租户的缺点：更复杂：由于一个软件需要做出极大地修改，才能支持多租户架构，而且这种修改，往往会增加整个软件在架构方面的复杂性 不够安全：因为众多组织的应用和数据共享同一套软件和基础设施，如果出现机器宕机，软件出现问题或者大规模的数据被暴露等情况，将会造成更严重的后果，因为影响面更大。

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

3 F 的多租户架构的多租户架构由于 F 所负载的应用不论是在定制方面的灵活性上，还是所承受的负载上，对基于多租户的架构而言，都是史无前例的，导致之前提到的一些模型或者改动已经无法满足要求了，所以 Salesforce 在 F 引入了通过 Metadata（元数据）驱动的多租户架构来动态生成快速的，可伸缩的和可定制的应用接下来，将一步步为大家揭开F 多租户架构的神秘面纱，首先是它的总体架构3.1 总体架构总体架构在介绍 F 的整个架构之前，请看下图，此图是根据 Salesforce 首席架构师Craig Weissman 在 2009 年旧金山 QCon 大会上的演讲总结而成图 1. F 的架构图首先，在最前面是 Gateway（网关），网关将接受所有访问 F 的请求，无论它是访问 Sales Cloud，还是关于第三方定制程序的接下来，网关会根据这个请求所属的租户把请求转发给对应的 POD，什么是 POD？简单的来说，POD 就是一组集群服务器，每个POD 都运行同一套 F 系统，而且每个 POD 支持成千上万个租户，Salesforce 总共有 10 多个 POD 来支撑它所有服务的运营，并把所有租户平衡地分配给每个 POD，而且主要通过建立新的 POD 来支撑新的租户。

当 POD 收到请求之后，POD 会先通过其内置的Load Balancer（负载均衡器）来将请求转发给负载略轻的 App Server（应用服务器），由于为了简化架构和方便伸缩（Scale），所以应用服务器是 Stateless（无状态），而且在一个 POD 内会有多个应用服务器以应对大规模的请求最后，当应用服务器在处理请求的时候，如果发现请求所需的数据没有被 Cache 住的话，应用服务器会调用这个租户所属的Shared DB（共享数据库）来取得相关数据，虽然共享数据库是使用成熟的 Oracle 数据库产品，但是在数据库表的设计上面为多租户做了很多地优化接下来，将介绍 F 是如何通过 Metadata 来动态生成和定制应用的3.2 Metadata 驱动驱动 首先，F 的 Metadata 是基于大家非常熟悉的面向对象的概念，所以也可以把Metadata 认为是对象，也就是说 F 是由一个个对象组装而成，而且 F 中的对象可以是表格，也可以是 UI，甚至可以是用户权益等一个 F 的对象和这个对象下面的字段可以对应一个数据库的表和这个表的列，而且 F 对象之间的关系（relationship）在功能上类似于数据库的引用完整性約束（referential integrity constraint），但与数据库中每个数据库表对应于独立的存储地址不同的是，F。