云平台多租户设计

《云平台多租户设计》由会员分享，可在线阅读，更多相关《云平台多租户设计（7页珍藏版）》请在装配图网上搜索。

1、在云领域我们经常会听到一个词：多租户。这个词在不同的语境中有着不同的含义，本文将介绍云平台中的多租户的概念以及实现多租户支持的思路。什么是租户刚开始接触这个概念时，你肯定感觉“租户”这个词怪怪的，但如果我们换个词，我相信你马上就有感觉了，这个词就是“客户”（这里的客户指的就是商业上面的客户）。一个租户就是一个客户，比如我们开发的服务是给XXX企业使用的，那该企业就是我们的一个客户/租户；如果这个服务是面向互联网的，那么使用该服务的每个互联网用户都是一个客户/租户。为什么需要多租户支持开发者辛辛苦苦开发出一个服务，提供给了个人/企业使用，这样就完事了么？当然不应该只是这样，我们开发出一个服务，最

2、好是能够同时提供给多个个人/企业使用，而且这些客户最好是共享同一套服务运行时（Runtime），这样可以大大降低服务的运维成本：服务运行时如果分开，则运维的成本与客户数成正比（比如更新部署大量客户的场景）节省资源（将服务所需资源利用最大化：运维团队统一、硬件使用）另外，这样也可以降低服务的开发成本:我们只需要考虑如何实现单用户的服务逻辑：业务逻辑对应其所有客户都是相同的，无论什么客户来使用，程序提供的服务都是一样的。进一步说，在业务层面我们开发这个服务时理论上不需要考虑多客户支持，我们只用关注该服务的业务逻辑如何实现多客户的管理功能可以进行统一：开发者应该不用考虑客户管理功能，这部分应该是由云

3、平台统一提供的多租户场景举例假设我们要开发的服务是一个博客平台，这个服务是面向互联网用户的，每个互联网用户都是我们的客户（一个用户就是一个租户）。在不支持多租户的环境中，为了隔离每个用户的数据，至少我们在设计数据库表时会考虑大多数表都存在一个user_id字段，用于CRUD数据时使用该字段进行用户隔离。比如现在的业务是“发布文章”，需要将文章数据保存在article表中，在实现时实际上我们关注了两件事情：CRUD:这是业务逻辑实现的一部分用户隔离：需要加入user_id，做业务关联1是“纯”业务逻辑部分的实现，这是必须实现的；2则是为了多用户博客平台而需要考虑的，这并不是博客平台本身的业务逻辑

4、。这里如果能得到平台的多租户支持，就不用考虑第2点了，这样可以将注意力集中于第1点业务逻辑实现上，这是非常典型的一个多租户场景。多租户支持我们可以这样理解多租户支持：从服务提供的角度看，我们开发的一个服务运行时可以同时提供给多个客户使用，并且客户之间的数据/状态是保持隔离的从服务使用的角度看，我和你可以作为不同的客户同时使用同一个运行的服务，此时我们使用该服务完成的业务是相互不影响的，就好像我们在使用自己独享的服务一样那么这个服务就是支持多“客户”的，即该服务支持多租户。这里的“服务”可以是应用，可以是SaaS平台，也可以是PaaS平台。不过按目前我们熟悉的云平台看，应用的多租户支持应该是最常

5、规的，这是因为应用面向的是用户，这个群体是很庞大的。多租户支持从实现的角度看，“是一种软件架构技术”，之所以强调它是属于架构层面是因为要实现它必须在做技术架构时就要将其考虑在内。一种租户模型本文一开始我们提到使用“客户”来置换“租户”来理解租户的含义，再从“商业”这个方面来看的话，我们不难发现租户其实就是其云环境中的商业模式实现的一部分。商业模式是多样的，这意味着租户的划分也是多样的，这里我们描述其中一种可能的租户栈：应用程序是提供给用户使用的，对于应用来说，用户就是它的租户（这一点业界比较统一）SaaS提供的服务是给应用开发商使用的，对于SaaS来说，应用开发商就是它的租户PaaS提供的服务

6、是给应用系统使用的，对于PaaS来说，相关应用的组合就是它的租户SaaS和PaaS面向的是开发商、系统等非端用户角色，这一部分一般是由云平台开发者决定的（捆绑商业模式），特别是私有/企业云平台一般不会考虑形如“在PaaS平台上支持运行多个SaaS平台”这样的场景。所以下面我们更多的是围绕“应用对多租户支持”进行讨论。应用多租户应用多租户的使用场景前面已经介绍过了，现在假设我们是一个云平台开发者，为了满足支持应用支持多租户的需求，在云平台中我们需要提供下面几个支持：租户管理：CRUD，统计租户隔离/共享的服务：队列、缓存、数据库等租户隔离的统计：日志、配额这些支持可以分为两类：租户的管理：不会直

7、接面向应用的端用户，面向的是应用的运维，平台应该提供具体实现租户数据/状态的隔离：从请求开始就应该可以区分这个请求是来自于哪个租户，请求处理时在调用链路上也需要带上租户上下文，数据的存取是按照租户隔离的，调用平台提供的服务时也是租户隔离的第1点比较容易实现，这是一个业务模型方面的问题，可以根据业务域来抽象租户模型，比如企业应用一般是按照“组织机构”来区分租户的；第2点是一个纯技术的需求，需要在平台技术实现上支持按“租户”的运行时隔离，我们强调的是隔离，因为在实现时我们要达到的目标就是隔离，只不过这里是按租户（租户只是一个商业概念，技术层面我们最好能够将其进行抽象，尽量减小商业模式多样化对技术架

8、构的冲击），我们可以将租户映射到一个抽象概念上，这个抽象概念可以实现我们的隔离需求。命名空间前面我们讨论多租户支持都是自上而下的：从应用多租户需求到数据隔离实现；现在我们再换种视角，自下而上：先通过命名空间隔离数据，再将命名空间提供给应用多租户的实现使用。自下而上的目的主要是在平台内部，我们可以通过“命名空间”来进行数据/状态隔离的抽象，最终的理想情况是命名空间不仅能够支持应用多租户实现，还能够可选择性地暴露命名空间APIs，让应用可以进行某些数据的隔离（比如缓存），方便业务实现。隔离的实现租户请求从开始到结束平台都需要知晓这个请求映射的命名空间，从请求处理栈我们可以这样大致划分一下：负载均衡

9、器（LB）应用容器（APP）平台服务接口（RPC）平台服务实现（DB/Cache/MQ.）在这个栈中每一层平台都是需要知道这个请求对应的命名空间的。平台可以提供一个统一登录的服务，将租户信息映射为命名空间并保存到用户会话中，这样每次该用户的请求：过LB时就可以区分出命名空间来在APP容器中可以通过会话RPC时传递命名空间根据服务的不同进行命名空间实现（例如DB根据命名空间使用不同的Schema,MQ根据命名空间使用不同的队列）这里我们使用的隔离实现基本思路是“Sharedapplication”，即多租户共享一个应用，对应一套基础设施（请参考：将单租户应用程序转换为多租户应用程序一种平台设计前

10、面谈了这么多，现在我们可以脑补出一种支持应用多租户的云平台:租户命运堆整合(Runtime管理、租户管理)Runtiime1Runtime2基砒设触(这里的设计思路也包含了有的租户要求独享资源的场景)总结租户X的请求APP1APPn租户亠命名空间映射(1:1)由Runtime透明完成租卢到命名空间的映射基础服务(DB/MQ/Cache等)租户和客户的概念类似APP1APPnAPPn 对多租户的支持我们一般指的是应用对多租户的支持在技术层面支持多租户需要实现数据/状态隔离使用命名空间进行隔离实现抽象租户到命名空间的映射可由平台集成Wikipedia:多租户技术客户的概念将单租户应用程序转换为多租户应用程序云计算环境下的JVM虚拟化特性初探GAE多租户支持