关于angular:JNPF云平台之多租户的探索

​

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

什么是租户

刚开始接触这个概念时，你必定感觉“租户”这个词怪怪的。但假如咱们换个词，我置信你立刻就有感觉了。这个词就是“客户”（这里的客户指的就是商业下面的客户）。

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

为什么须要多租户反对

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

• 服务执行时假如离开，则运维的老本与客户数成正比（比如更新部署大量客户的场景）
• 节俭资源（将服务所需资源利用最大化：运维团队对立、硬件应用）

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

• 咱们仅仅须要思考怎么实现单用户的服务逻辑：业务逻辑相应其全副客户都是同样的，不论什么客户来应用，程序提供的服务都是一样的。进一步说，在业务层面咱们开发这个服务时实践上不须要思考多客户反对，咱们仅仅用关注该服务的业务逻辑怎么实现
• 多客户的治理性能可能进行对立：开发人员应该不必思考客户治理性能，这部分应该是由云平台对立提供的

多租户场景举例

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

在不反对多租户的环境中，为了隔离每一个用户的数据，至多咱们在设计数据库表时会思考大多数表都存在一个 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”，即多租户共享一个利用，相应一套基础设施。

 一种平台设计

 后面谈了这么多，现在咱们可能脑补出一种反对利用多租户的云平台：

​

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

总结

• 租户和客户的概念相似
• 对多租户的反对咱们个别指的是利用对多租户的反对
• 在技术层面反对多租户须要实现数据 / 状态隔离
• 应用命名空间进行隔离实现形象
• 租户到命名空间的映射可由平台集成