多租户已死！云架构上位

多租户系统是企业软件中的常见模式，JavaEE 7开始就策划多租户系统，Oracle 12c的PDB是一种多租户系统的实现，但是随着云架构发展，多租户系统的概念也许稍纵即逝。

多租户系统目标是基于共享一个系统基础上为每个租户提供专门的定制，多租户系统的主要优点是创建一个（逻辑上）客户实例的即时性。从某种意义上说，它有点像一栋公寓楼：你不需要为每个新租户建造一座新建筑，而是在一栋建筑物内安置许多租户，并辅以走廊和共用管道等共同基础设施。

无软件运动

在最近的IT世界中，基于多租户架构最直接成功的公司是Salesforce。在Salesforce 成为云计算平台的流行术语之前，它就采用了软件即服务模式。从本质上讲，Salesforce运行了一个由客户隔离的大型数据库，该模型非常成功，得益于有效的“无软件”营销活动，该活动充分利用了企业的焦虑，他们发现（并且经常体验）软件需要很长时间的部署过程，并在此过程中引发各种问题，相反，Salesforce几乎可以立即注册为新客户。

挑战

虽然多租户系统对客户具有明显的优势，但它们带来了若干架构挑战。为了使单个系统看起来像一组单独的系统，必须在租户之间隔离数据，配置以及诸如性能之类的非功能特性。这种隔离会在应用程序和数据库模式中引入复杂性，例如需要在代码里和通过数据传播租户标识，使得具体应用依赖于基础设施。

计算机基础设施的最新发展趋势使得我们能够重新审视这种类型的架构。

Duck架构

面向对象的世界有一个“duck类型”的概念，不是像 Java 那样引入一种全局类型机制对对象进行分类，而是根据其可观察行为进行类型分类。所以，不能将鸭子归类水禽，而应该归类为鸟类，你可以通过观察它的行为定义它是一只鸭子：如果它像鸭子一样呱呱叫，像鸭子一样走路，它就被认为是一只鸭子。

在软件设计中，这意味着类的内部构型或类型层次结构取决于对象的可观察行为：如果对象具有获取当前时间的方法，则可能是Clock对象。

让我们将相同的行为类型概念应用于大规模系统架构。然后，我们可以重新审视多租户这个概念，多租户传统上通常被认为是属于系统的架构属性，因为多个租户是描述了架构的构造方式，例如通过用户对数据库和配置进行分段。但是，如果按照“类似鸭子”的逻辑，多租户应该是一个可观察的属性，即如果一个系统能够几乎瞬间创建新的和单独的用户实例，它就可以被认为是多租户能力。

结构遵循行为

如果我们采用后一种观点，我们可以接受系统架构的目的是展示一组特定的可观察行为，这意味着它的结构是由设想的行为驱动的。按照这个逻辑，一旦我们看到系统结构，我们必然会问这个结构为什么是这样一种方式呢？这是任何架构最重要的问题之一。

再看约束

质疑架构的“原因”是特别有用的，因为形成架构决策的特定约束可能已经改变或消失，可能使过去架构决策的动机无效。

在多租户系统下，驱动设计的关键约束是：每次实例化一个新系统实例是一个复杂且耗时的过程，这意味着如果您希望为独立用户提供他们自己的逻辑实例并且能够实现近乎即时访问的话，那么就需要构建一个基于现有实例的系统，但在逻辑上必须将其划分为看似单独的实例。这样的系统不必为每个新客户创建新的系统实例（系统实例创建耗费资源，比如安装 linux 过程很复杂），因此可以轻松地设置新客户。

次要约束是：在单独的虚拟或物理机器上具有许多单独的系统实例是低效的。每个实例都带有操作系统、存储、监视等的开销，这些开销会多次重复，浪费计算和存储资源。

我之前曾说过，云计算不仅仅是有关基础设施的，它还与软件交付和自动化一样，与运行时基础架构有很重要关系。自动化这一方面使我们能够将多租户视为结构系统属性，但是由于云自动化，部署和配置新系统实例和数据库变得非常容易和快速，因此，系统可以简单地通过创建新实例来展示多租户系统的属性，从而避免多租户架构的复杂性。那么，它的行为就像一个多租户系统，却不是结构属性。

此外，容器技术显着降低了与每个实例相关的开销，因为它不会为每个实例复制整个操作系统，借助像Kubernetes这样的容器编排，管理多个实例也更容易。在Kubernetes集群上运行数千个容器实例并不罕见。因此，这也可以解决上面架构次要约束。

结合起来，这意味着云自动化和容器化能够让具有多租户架构的传统系统被多的单租户系统取代，该系统更具有可比较特性，但遵循更简单的架构。当然，云运行时也遵循多租户设计，但云提供商已经吸收了这种复杂性，因此没有理由为每个应用程序重新设计它。

高效的单户住宅

就像文章一开始就使用建筑比喻一样，结束时我们还是使用建筑做比喻，云计算使我们能够从公寓建筑转移到易于复制和高效的单户住宅：它们更容易建造，每个租户都有自己的建筑。幸运的是，我们可以在云计算中比在现实世界中更有效地做到这一点，因此我们不必担心城市蔓延。