在云领域我们经常会听到一个词:多租户。这个词在不同的语境中有着不同的含义,本文将介绍云平台中的多租户的概念以及实现多租户支持的思路。 什么是租户 刚开始接触这个概念时,你肯定感觉“租户”这个词怪怪的,但如果我们换个词,我相信你马上就有感觉了,这个词就是“客户”(这里的客户指的就是商业上面的客户)。一个租户就是一个客户,比如我们开发的服务是给 XXX 企业使用的,那该企业就是我们的一个客户/租户;如果这个服务是面向互联网的,那么使用该服务的每个互联网用户都是一个客户/租户。 为什么需要多租户支持 开发者辛辛苦苦开发出一个服务,提供给了个人/企业使用,这样就完事了么?当然不应该只是这样,我们开发出一个服务,最好是能够同时提供给多个个人/企业使用,而且这些客户最好是共享同一套服务运行时(Runtime),这样可以大大降低服务的运维成本: • 服务运行时如果分开,则运维的成本与客户数成正比(比如更新部署大量客户的场景) • 节省资源(将服务所需资源利用最大化:运维团队统一、硬件使用) 另外,这样也可以降低服务的开发成本: • 我们只需要考虑如何实现单用户的服务逻辑:业务逻辑对应其所有客户都是相同的,无论什么客户来使用,程序提供的服务都是一样的。进一步说,在业务层面我们开发这个服务时理论上不需要考虑多客户支持,我们只用关注该服务的业务逻辑如何实现 • 多客户的管理功能可以进行统一:开发者应该不用考虑客户管理功能,这部分应该是由云平台统一提供的 多租户场景举例 假设我们要开发的服务是一个博客平台,这个服务是面向互联网用户的,每个互联网用户都是我们的客户(一个用户就是一个租户)。 在不支持多租户的环境中,为了隔离每个用户的数据,至少我们在设计数据库表时会考虑大多数表都存在一个 user_id 字段,用于 CRUD 数据时使用该字段进行用户隔离。 比如现在的业务是“发布文章”,需要将文章数据保存在 article 表中,在实现时实际上我们关注了两件事情: 1. CRUD:这是业务逻辑实现的一部分 2. 用户隔离:需要加入 user_id,做业务关联 1 是“纯”业务逻辑部分的实现,这是必须实现的;2 则是为了多用户博客平台而需要考虑的,这并不是博客平台本身的业务逻辑。这里如果能得到平台的多租户支持,就不用考虑第 2 点了,这样可以将注意力集中于第 1 点业务逻辑实现上,这是非常典型的一个多租户场景。 多租户支持 我们可以这样理解...