Salesforce多租户架构

多租户架构(Multitenancy)已成为软件行业的一个口号。你只要询问某家公司它对这个主题有什么看法，就能判断该公司从事什么业务。对于靠该架构起家的公司(Salesforce。com和谷歌)而言，多租户架构必不可少。对于传统的老牌开发商(微软、SAP和甲骨文)而言，多租户架构分别被认为是一种威胁、无名小卒或者是一种额外的交付模式。本文详细介绍多租户架构以及它在如何改变软件行业。

　　什么是多租户架构?

　　多租户架构的核心思想就是，软件采用这种方式来开发：应用程序的一个实例可处理多个客户即租户的要求。以Salesforce的模式为例，每个客户开始时都使用应用程序的同一版本。数据存储在共享数据库中，但每个客户只可以访问自己的信息。整个应用程序由所谓的元数据(Metadata)来描述;元数据就是命令指示，描述了应用程序如何运行的各个方面。如果客户想定制应用程序，可以创建及配置新的元数据，以描述新的屏幕、数据库字段或所需行为。

　　多租户架构之外的选择是单租户架构;在这种模式中，每个客户都运行自己的软件实例，软件可通过元数据或其他方式来配置。SAP公司为其Business by Design软件采用了单租户模式，该软件实施了众多商业应用程序。

　　多租户模式与单租户架构模式存在大片的潜在灰色区，往往被人们所忽视。单租户应用程序可由云环境中的虚拟化服务器或数据中心内的服务器来提供，单租户应用程序的各部分可以共享或不共享。比方说，应用程序采用单租户模式、而数据库进行共享这种现象并不罕见。

　　Salesforce在多租户架构方面表明了这个看法：它让软件开发商只需要为在一个运作环境下运行的软件的一个版本而操心。不需要为不同的软硬件配置支持多个版本。因为Salesforce的所有客户都运行同一软件的同一版本，他们就能看清楚什么在顺畅运行、什么需要改进。

　　一旦Salesforce进行了改进，所有客户就可以同时获得改进之处，不过客户总是可以选择启用新特性，还是任由新特性被禁用。由于加大了关注度和集中化，创新步伐更快了。合作伙伴在开发兼容产品时，也可以把主要精力放在支持软件的一个版本上。

　　与单租户架构相比，多租户架构的一个缺点就是，某一客户的问题会影响整个系统。另外，如果集中式运作出问题，所有客户都会受到影响。没有哪家软件即服务(SaaS)提供商是完美无缺的。它们都遇到过严重的服务停用事件。不过与大多数内部数据中心的糟糕记录相比，它们的情况似乎都相当好。

　　Salesforce通过Force。com平台把多租户架构的优点扩大到了其他软件开发人员;该平台让第三方公司可以使用其软件的原始构建模块和高级应用程序组件，开发自己的多租户应用程序。这种模式被称为“平台即服务”(Platform-as-a-Service);谷歌等其他公司也有类似服务，支持多租户应用程序的开发。

　　随着支持应用程序的构建模块变得更加通用、较少经过改动以便开发多租户应用程序，你就会慢慢进入到基础架构即服务(Infrastructure-as-a-Service)领域，这种服务提供了原始计算功能。显然，弄清楚所有这些层绝非易事。

　　多租户架构是SaaS供应商取得成功的关键?

　　对用户和开发人员来说，真正的问题是，为什么应当在乎某应用程序或某平台采用单租户架构还是采用多租户架构?Salesforce的首席执行官　Marc Benioff在公开演讲中坚持认为，SaaS供应商要取得成功，就必须采用多租户架构，另一些知名的分析师也这么认为。但真是这样吗?SaaS模式为客户减掉了开发及管理基础架构的负担。针对单租户架构，同样可以做到这一点。

　　使用应用程序的惟一理由就是它可以完成你想要它完成的功能，而Salesforce已证明成千上万的客户需要它的软件。但在其他领域，多租户架构还没有证明它就是灵丹妙药。比方说，Netsuite提供了采用多租户架构的企业资源规划(ERP)软件包。SAP有其Business ByDesign产品，这套商业应用程序采用了单租户架构。这两家公司都还没有拥有Salesforce。com那么众多的客户。

　　可以解释Salesforce及其多租户服务取得成功的另一个理由与需求的共性有关。如果你认为客户关系管理(CRM)是存在需求共性的一个领域，可以认为ERP领域的需求共性更为明显。

　　大多数客户需要从CRM获得所有可能功能中相同的20%。对ERP而言，可能每个客户需要的是不同的20%。按照这条思路来推理，SaaS公司的成功关键也许在于选择正确的产品，对所有客户来说最常见的一个产品。Salesforce采用多租户方案主攻这个领域，结果受益良多，但它所做的最明智的举动恐怕就是当初先选择CRM作为主攻市场。

　　从开发人员的角度来看，多租户架构不是最值得注意的。使用一个平台的目的在于，迅速开发出所需的产品。有些公司会发现，由于Force.com或谷歌应用引擎(Google App Engine)目前提供了广泛的功能范围(functional footprint)，能够尽快让自己实现想要企及的目标。其他公司会因使用Ruby on Rails或Engine Yard用于主机托管所获得的极大灵活性而更快地取得成功。

　　要是阅读Salesforce的白皮书，你会看到一幅图片，上面介绍了新的元数据驱动型编程模式，应用程序恰好是用多租户架构来提供的。与通过元数据大大提高抽象程度(这也许是Salesforce的最大成就)这个成就相比，多租户架构是次要的。如果一家公司能够为客户提供通过元数据、轻松获取及配置应用程序的一种方式，它就能成功。但许多软件公司一直在提供可通过元数据来配置的软件。Salesforce有什么质的不同吗?

　　Salesforce的成功秘诀在于，该公司选择了一个领域即CRM，许多客户对此有着共同的需求。然后，　Salesforce致力于基于多租户架构，创建可以扩展的运作环境(SaaS模式)。多租户架构的最大价值倒并不在于Salesforce指出的种种优点，而在于这个事实：该架构迫使Salesforce更好地开发元数据驱动的应用程序。

　　确保软件取得成功的一个关键方面在于可配置性。通过基于元数据的配置来满足客户要求越是容易，应用程序越有希望成功，不管采用的是单租户架构还是多租户架构。但我们回答不了的一个问题是，基于元数据的可配置性方面是不是存在极限。换句话说，简化像适用于世界上每个国家的会计科目表这样的复杂对象到底有没有可能?是不是有些问题复杂到总是很难处理、因而无法配置的地步?

　　对我们来说，多租户架构的未来方面值得关注的问题在于，Salesforce取得的成就是否就是操作系统、应用服务器层和编程语言向虚拟化环境扩展的先兆?Salesforce是从应用程序起家的。

　　其他厂商不会对迅猛发展的Force.com坐视不管;他们正开始从其他方向来解决这个问题。SAP、微软、甲骨文、IBM、惠普和谷歌都在积极开发自己的产品。

Salesforce多租户架构
多租户架构（Multitenancy）已成为软件行业的一个口号。你只要询问某家公司它对这个主题有什么看法，就能判断该公司从事什么业务。对于靠该架构起家的公司而言，多租户架构必不可少。

多租户架构(Multitenancy)已成为软件行业的一个口号。你只要询问某家公司它对这个主题有什么看法，就能判断该公司从事什么业务。对于靠该架构起家的公司(Salesforce。com和谷歌)而言，多租户架构必不可少。对于传统的老牌开发商(微软、SAP和甲骨文)而言，多租户架构分别被认为是一种威胁、无名小卒或者是一种额外的交付模式。本文详细介绍多租户架构以及它在如何改变软件行业。

　　什么是多租户架构?

　　多租户架构的核心思想就是，软件采用这种方式来开发：应用程序的一个实例可处理多个客户即租户的要求。以Salesforce的模式为例，每个客户开始时都使用应用程序的同一版本。数据存储在共享数据库中，但每个客户只可以访问自己的信息。整个应用程序由所谓的元数据(Metadata)来描述;元数据就是命令指示，描述了应用程序如何运行的各个方面。如果客户想定制应用程序，可以创建及配置新的元数据，以描述新的屏幕、数据库字段或所需行为。

　　多租户架构之外的选择是单租户架构;在这种模式中，每个客户都运行自己的软件实例，软件可通过元数据或其他方式来配置。SAP公司为其Business by Design软件采用了单租户模式，该软件实施了众多商业应用程序。

　　多租户模式与单租户架构模式存在大片的潜在灰色区，往往被人们所忽视。单租户应用程序可由云环境中的虚拟化服务器或数据中心内的服务器来提供，单租户应用程序的各部分可以共享或不共享。比方说，应用程序采用单租户模式、而数据库进行共享这种现象并不罕见。

　　Salesforce在多租户架构方面表明了这个看法：它让软件开发商只需要为在一个运作环境下运行的软件的一个版本而操心。不需要为不同的软硬件配置支持多个版本。因为Salesforce的所有客户都运行同一软件的同一版本，他们就能看清楚什么在顺畅运行、什么需要改进。

　　一旦Salesforce进行了改进，所有客户就可以同时获得改进之处，不过客户总是可以选择启用新特性，还是任由新特性被禁用。由于加大了关注度和集中化，创新步伐更快了。合作伙伴在开发兼容产品时，也可以把主要精力放在支持软件的一个版本上。

　　与单租户架构相比，多租户架构的一个缺点就是，某一客户的问题会影响整个系统。另外，如果集中式运作出问题，所有客户都会受到影响。没有哪家软件即服务(SaaS)提供商是完美无缺的。它们都遇到过严重的服务停用事件。不过与大多数内部数据中心的糟糕记录相比，它们的情况似乎都相当好。

　　Salesforce通过Force。com平台把多租户架构的优点扩大到了其他软件开发人员;该平台让第三方公司可以使用其软件的原始构建模块和高级应用程序组件，开发自己的多租户应用程序。这种模式被称为“平台即服务”(Platform-as-a-Service);谷歌等其他公司也有类似服务，支持多租户应用程序的开发。

　　随着支持应用程序的构建模块变得更加通用、较少经过改动以便开发多租户应用程序，你就会慢慢进入到基础架构即服务(Infrastructure-as-a-Service)领域，这种服务提供了原始计算功能。显然，弄清楚所有这些层绝非易事。

　　多租户架构是SaaS供应商取得成功的关键?

　　对用户和开发人员来说，真正的问题是，为什么应当在乎某应用程序或某平台采用单租户架构还是采用多租户架构?Salesforce的首席执行官　Marc Benioff在公开演讲中坚持认为，SaaS供应商要取得成功，就必须采用多租户架构，另一些知名的分析师也这么认为。但真是这样吗?SaaS模式为客户减掉了开发及管理基础架构的负担。针对单租户架构，同样可以做到这一点。

　　使用应用程序的惟一理由就是它可以完成你想要它完成的功能，而Salesforce已证明成千上万的客户需要它的软件。但在其他领域，多租户架构还没有证明它就是灵丹妙药。比方说，Netsuite提供了采用多租户架构的企业资源规划(ERP)软件包。SAP有其Business ByDesign产品，这套商业应用程序采用了单租户架构。这两家公司都还没有拥有Salesforce。com那么众多的客户。

　　可以解释Salesforce及其多租户服务取得成功的另一个理由与需求的共性有关。如果你认为客户关系管理(CRM)是存在需求共性的一个领域，可以认为ERP领域的需求共性更为明显。

　　大多数客户需要从CRM获得所有可能功能中相同的20%。对ERP而言，可能每个客户需要的是不同的20%。按照这条思路来推理，SaaS公司的成功关键也许在于选择正确的产品，对所有客户来说最常见的一个产品。Salesforce采用多租户方案主攻这个领域，结果受益良多，但它所做的最明智的举动恐怕就是当初先选择CRM作为主攻市场。

　　从开发人员的角度来看，多租户架构不是最值得注意的。使用一个平台的目的在于，迅速开发出所需的产品。有些公司会发现，由于Force.com或谷歌应用引擎(Google App Engine)目前提供了广泛的功能范围(functional footprint)，能够尽快让自己实现想要企及的目标。其他公司会因使用Ruby on Rails或Engine Yard用于主机托管所获得的极大灵活性而更快地取得成功。

　　要是阅读Salesforce的白皮书，你会看到一幅图片，上面介绍了新的元数据驱动型编程模式，应用程序恰好是用多租户架构来提供的。与通过元数据大大提高抽象程度(这也许是Salesforce的最大成就)这个成就相比，多租户架构是次要的。如果一家公司能够为客户提供通过元数据、轻松获取及配置应用程序的一种方式，它就能成功。但许多软件公司一直在提供可通过元数据来配置的软件。Salesforce有什么质的不同吗?

　　Salesforce的成功秘诀在于，该公司选择了一个领域即CRM，许多客户对此有着共同的需求。然后，　Salesforce致力于基于多租户架构，创建可以扩展的运作环境(SaaS模式)。多租户架构的最大价值倒并不在于Salesforce指出的种种优点，而在于这个事实：该架构迫使Salesforce更好地开发元数据驱动的应用程序。

　　确保软件取得成功的一个关键方面在于可配置性。通过基于元数据的配置来满足客户要求越是容易，应用程序越有希望成功，不管采用的是单租户架构还是多租户架构。但我们回答不了的一个问题是，基于元数据的可配置性方面是不是存在极限。换句话说，简化像适用于世界上每个国家的会计科目表这样的复杂对象到底有没有可能?是不是有些问题复杂到总是很难处理、因而无法配置的地步?

　　对我们来说，多租户架构的未来方面值得关注的问题在于，Salesforce取得的成就是否就是操作系统、应用服务器层和编程语言向虚拟化环境扩展的先兆?Salesforce是从应用程序起家的。

　　其他厂商不会对迅猛发展的Force.com坐视不管;他们正开始从其他方向来解决这个问题。SAP、微软、甲骨文、IBM、惠普和谷歌都在积极开发自己的产品。