JNPF云平台之多租户的探索

​

在云领域咱们经常会听到一个词：多租户。这个词在不一样的语境中有着不一样的含义。本文将介绍云平台中的多租户的概念以及实现多租户支持的思路。

什么是租户

刚开始接触这个概念时，你确定感受“租户”这个词怪怪的。但假设咱们换个词，我相信你当即就有感受了。这个词就是“客户”（这里的客户指的就是商业上面的客户）。

一个租户就是一个客户，比方咱们开发的服务是给 XXX 企业使用的，那该企业就是咱们的一个客户/租户；假设这个服务是面向互联网的，那么使用该服务的每个互联网用户都是一个客户/租户。

为何需要多租户支持

开发人员辛辛苦苦开发出一个服务。提供给了我的/企业使用，这样就完事了么？固然不该该仅仅是这样。咱们开发出一个服务。最好是能够同一时候提供给多个我的/企业使用。而且这些客户最好是共享同一套服务执行时（Runtime），这样能够大大减小服务的运维成本：

• 服务执行时假设分开，则运维的成本与客户数成正比（比方更新部署大量客户的场景）
• 节省资源（将服务所需资源利用最大化：运维团队统1、硬件使用）

另外，这样也可以减小服务的开发成本：

• 咱们仅仅需要考虑怎样实现单用户的服务逻辑：业务逻辑相应其所有客户都是一样的，无论什么客户来使用，程序提供的服务都是同样的。进一步说，在业务层面咱们开发这个服务时理论上不需要考虑多客户支持，咱们仅仅用关注该服务的业务逻辑怎样实现
• 多客户的管理功能可以进行统一：开发人员应该不用考虑客户管理功能，这部分应该是由云平台统一提供的

多租户场景举例

若是咱们要开发的服务是一个博客平台，这个服务是面向互联网用户的，每个互联网用户都是咱们的客户（一个用户就是一个租户）。

在不支持多租户的环境中，为了隔离每个用户的数据，至少咱们在设计数据库表时会考虑大多数表都存在一个 user_id 字段。用于 CRUD 数据时使用该字段进行用户隔离。

比方现在的业务是“公布文章”。需要将文章数据保存在 article 表中，在实现时实际上咱们关注了两件事情：

1. CRUD：这是业务逻辑实现的一部分
2. 用户隔离：需要增长 user_id。作业务关联

1 是“纯”业务逻辑部分的实现。这是必须实现的；

2 则是为了多用户博客平台而需要考虑的，这并不是博客平台自己的业务逻辑。

这里假设能获得平台的多租户支持，就不用考虑第 2 点了。这样可以将注意力集中于第 1 点业务逻辑实现上，这是很典型的一个多租户场景。

多租户支持

咱们可以这样理解多租户支持：

• 从服务提供的角度看。咱们开发的一个服务执行时可以同一时候提供给多个客户使用。并且客户之间的数据/状态是保持隔离的
• 从服务使用的角度看，我和你可以做为不一样的客户同一时候使用同一个执行的服务，此时咱们使用该服务完毕的业务是相互不影响的，就好像咱们在使用本身独享的服务同样

那么这个服务就是支持多“客户”的，即该服务支持多租户。这里的“服务”可以是应用，可以是 SaaS 平台，也可以是 PaaS 平台。只是按眼下咱们熟悉的云平台看，应用的多租户支持应该是最常规的。这是因为应用面向的是用户，这个群体是很是庞大的。

多租户支持从实现的角度看。“是一种软件架构技术”，之因此强调它是属于架构层面是因为要实现它必须在作技术架构时就要将其考虑在内。

一种租户模型

本文一开始咱们提到使用“客户”来置换“租户”来理解租户的含义。再从“商业”这个方面来看的话，咱们不难发现租户事实上就是其云环境中的商业模式实现的一部分。商业模式是多样的。这意味着租户的划分也是多样的。这里咱们描写叙述当中一种可能的租户栈：

• 应用程序是提供给用户使用的，对于应用来讲，用户就是它的租户（这一点业界比較统一）
• SaaS 提供的服务是给应用开发商使用的，对于 SaaS 来讲，应用开发商就是它的租户
• PaaS 提供的服务是给应用系统使用的，对于 PaaS 来讲。相关应用的组合就是它的租户

SaaS 和 PaaS 面向的是开发商、系统等非端用户角色。这一部分一般是由云平台开发人员决定的（捆绑商业模式）。特别是私有/企业云平台通常不会考虑形如“在 PaaS 平台上支持执行多个 SaaS 平台”这种场景。因此如下咱们不少其它的是环绕“应用对多租户支持”进行讨论。

应用多租户

应用多租户的使用场景前面已经介绍过了。现在若是咱们是一个云平台开发人员，为了知足支持应用支持多租户的需求，在云平台中咱们需要提供如下几个支持：

• 租户管理：CRUD，统计
• 租户隔离/共享的服务：队列、缓存、数据库等
• 租户隔离的统计：日志、配额

这些支持可以分为两类：

1. 租户的管理：不会直接面向应用的端用户。面向的是应用的运维。平台应该提供详细实现
2. 租户数据/状态的隔离：从请求開始就应该可以区分这个请求是来自于哪一个租户，请求处理时在调用链路上也需要带上租户上下文。数据的存取是依照租户隔离的。调用平台提供的服务时也是租户隔离的

第 1 点比较easy实现。这是一个业务模型方面的问题，可以依据业务域来抽象租户模型，比方企业应用一般是依照“组织机构”来区分租户的；

第 2 点是一个纯技术的需求。需要在平台技术实现上支持按“租户”的执行时隔离，咱们强调的是隔离，因为在实现时咱们要达到的目标就是隔离，仅仅只是这里是按租户（租户仅仅是一个商业概念，技术层面咱们最好可以将其进行抽象。尽可能减少商业模式多样化对技术架构的冲击）。咱们可以将租户映射到一个抽象概念上，这个抽象概念可以实现咱们的隔离需求。

命名空间

前面咱们讨论多租户支持都是自上而下的：从应用多租户需求到数据隔离实现；现在咱们再换种视角，自下而上：先经过命名空间隔离数据，再将命名空间提供给应用多租户的实现使用。自下而上的目的主要是在平台内部，咱们能够经过“命名空间”来进行数据/状态隔离的抽象。终于的理想状况是命名空间不只能够支持应用多租户实现，还能够可选择性地暴露命名空间 APIs。让应用能够进行某些数据的隔离（比方缓存）。方便业务实现。

隔离的实现

租户请求从开始到结束平台都需要知晓这个请求映射的命名空间。从请求处理栈咱们可以这样大体划分一下：

• 负载均衡器（LB）
• 应用容器（APP）
• 平台服务接口（RPC）
• 平台服务实现（DB/Cache/MQ....）

在这个栈中每一层平台都是需要知道这个请求相应的命名空间的。平台可以提供一个统一登陆的服务，将租户信息映射为命名空间并保存到用户会话中，这样每次该用户的请求：

• 过 LB 时就可以区分出命名空间来
• 在 APP 容器中可以经过会话
• RPC 时传递命名空间
• 依据服务的不一样进行命名空间实现（好比 DB 依据命名空间使用不一样的 Schema，MQ 依据命名空间使用不一样的队列）

这里咱们使用的隔离实现基本思路是“Shared application”，即多租户共享一个应用，相应一套基础设施。

 一种平台设计

 前面谈了这么多，现在咱们可以脑补出一种支持应用多租户的云平台：

​

（这里的设计思路也包括了有的租户要求独享资源的场景）

总结

• 租户和客户的概念相似
• 对多租户的支持咱们通常指的是应用对多租户的支持
• 在技术层面支持多租户需要实现数据/状态隔离
• 使用命名空间进行隔离实现抽象
• 租户到命名空间的映射可由平台集成