云计算中的多租户与多租户架构

1、云计算中的多租户与多租户架构什么是多租户(Multitenancy)“多租户的概念最早起源于软件领域，指一个软件实例效劳于多个用户的架构。每个用户称为一个租户。云计算中的多租户“多租户也是“云计算的根本属性之一。云计算的三种效劳层次SaaS、PaaS和IaaS均表达了对“多租户不同的支持。SaaSPaaSIaaS出租的资源举例说明软件的使用权。典型如：电子邮件系统。用户租户拥有使用账号。租户登录使用系统。软件开发平台资源如开发支撑系列工具，应用存储空间，运行容器，平台效劳等等。如：某租户拥有1G应用存储空间，应用容器数量不限，总内存上限4G，2个缓存效劳。硬件根底设施如CPU、内存，存储，IP

2、，网络设备等等。如：某租户拥有2颗CPU，8G内存，80G硬盘，10IP，2负载均衡器，创立主机数量不限【隐藏】多租户是云计算的根本属性之一多租户与多租户架构应用实现对“多租户的支持，需要相应的“多租户架构Multi-tenancy architecture。在云计算时代，伴随着技术的开展， 应用的“多租户架构获得了极大的丰富。经典的多租户架构：Shared nothingShared hardwareShared everything多租户架构总览Gartner对当前云应用“多租户架构进展了总结并给出了参考架构，如下：为什么要“多租户？“多租户架构已经是云计算时代应用根本架构，那么，为什么采

3、用“多租户？它有什么优势？ 事实上，“多租户的模式并非IT独有，在我们日常生活的许多方面，均有表达。下面，我们以一个旅馆的例子，来探究为什么要“多租户。Why multitenancy？一个旅馆的例子1个旅馆，出租给多个人换个角度，多个人共租用了1旅馆的空间资源，旅馆正在面对“多租户。1个空间资源多人共用，如何划分房间资源分配？不划分，全部共用。旅客共享居住空间，床铺。大通铺方案木板隔断方案划分，用木板隔离。一个隔断中容纳几名旅客。几名旅客共享居住空间，每名旅客独享床铺。水泥墙隔断方案划分，用水泥墙隔离。一个隔断中只容纳一名旅客。每名旅客独享居住空间，床铺。本例中，我们从居住空间和床铺两个方面

4、考量。一个旅馆的例子大通铺木板隔离水泥墙隔离释意容纳旅客数504025进行分隔时必然会消耗空间，不同方案消耗空间不同，使得等量空间最终容纳旅客数不同。旅客体验私密性差中好旅客的行动是否会被其他旅客知晓决定了私密性。分差、中、好三个等级，对应私密性由低到高。本例中，多人共享居住空间还是单人独享居住空间决定了私密性。舒适性差中好居住空间如何分享，床铺如何分享共同决定了舒适性。二者均独享的方式舒适性最好。均共享的舒适性最低。住宿价格（元/每天）202540本例假设旅馆满员，每天计划总收入1000元。住宿价格=1000/容纳旅客数我们来评价一下按照不同划分方案划分的结果：一个旅馆的例子大通铺木板隔离水

5、泥墙隔离容纳旅客数504025旅客体验私密性差中好舒适性差中好住宿价格（元/每天）202540高低资源利用率资源利用率 = 1 / 容纳旅客数低高旅客体验低高住宿价格旅馆视角资源出租者旅客视角资源承租者一个旅馆的例子大通铺共享居住空间、床铺（Shared Everything）木板隔离共享居住空间、独享床铺水泥墙隔离独享居住空间、床铺（Shared Nothing）资源利用率高中低租户间共享资源多中少/无租户间隔离性低中高单位资源价格低中高如果再抽象一点：一个旅馆的例子结论不难得出结论：租户间共享资源越多，根底资源的利用率越高，单位资源本钱越低, 租户间隔离性越差。现在回到开场的问题：为什么要

6、多租户？希望利用多租户带来的资源高度共享模式架构，提高资源利用率，降低单位资源本钱。但，同时必须抑制租户间隔离性下降给租户带来的不便。不同架构差异少多租户间共享资源现在回到云应用“多租户架构的讨论，基于刚刚的分析与结论，首先分析一下各种架构，可见：随着“多租户在应用架构中实现层次的增高，租户间共享资源也越来越多。多租户实现层次不同架构差异根据之前的结论，图中架构从1-7，租户间共享资源越来越多，资源利用率越来也高，单位资源本钱越来越低，租户间的隔离性越来越差。显然，租户间共享资源越多的架构，租户隔离难度越大，本钱越高。租户隔离难度越大，应用开发难度，测试与维护本钱都会上升。租户间隔离性降低，会

7、导致许多问题：如数据平安性降低，租户间性能、异常相互影响等等。这些问题是应用为保证对租户的效劳质量而必须解决的。这类行为业内称为租户隔离。低高资源利用率高低单位资源本钱低高租户隔离本钱理论上，在单位资源本钱和租户隔离本钱取最正确平衡点，就能找到最合理的架构。业内的实践如此多的“多租户架构，业内知名厂商是如何实践的？业内的实践业内厂商“多租户架构多集中在Shared Hardware 和 Shared Everything。为何如此？理论上，各厂商选择的是单位资源本钱和租户隔离本钱取最正确平衡点的架构。厂商选择的“多租户架构与其擅长的业务领域的技术积累严密相关：SalesForce 与 Goog

8、le 在Shared Everything多租户高共享架构方面积累深厚，因此其优先选择了共享程度较高、同时实现难度也较大的架构。对于“多租户高共享方面积累尚浅的厂商，随着虚拟化技术出现而产生的Shared Hardware架构，方案成熟，难度适中，是一个好的选择。还有一个重要因素租户的需求是否有共性。SalesForce的实际上是面对特定领域CRM的，且其领域用户需求共性明显，因此，采用Shared Everything架构非常适合，且取得巨大成功。如果租户间需求没有趋同，比方租户的需求是来自多个领域的，或者同领域、但有大量定制，会使得采用Shared Everything架构十分困难。此时，

9、选择共享程度低的架构反而是个明智的选择。附录：关于PaaS“应用容器集群EAF在筹划时创造了“应用容器集群的提法。此提法基于如下考虑：PaaS平台需要为其租户提供一个由平台管理的应用运行的环境。应用运行在应用容器中，因此，组成应用运行环境的是应用运行容器，因为有大量的容器，且会使用集群技术，因此取名“应用容器集群。关于“应用容器集群的实现。EAF原方案采用Shared OS多租户架构实现应用容器集群。即多个容器共享一个操作系统的方式。结合实际。就是一台虚拟机上，会有多于一个的应用运行容器类似于Cloudbees。而常见的Shared Hardware架构， Shared Hardware架构中，一台虚拟机上只有一个应用运行容器。类似于AWS Beanstalk、Aclome BC附录：关于PaaS“应用容器集群比照“应用容器集群Shared OS与Shared Hardware架构的实现二者比照， “应用容器集群在调度容器时， Shared OS架构实际调度的是应用效劳器实例，而Shared Hardware架构实际调度的是虚拟机。在进展应用弹性伸缩时， Shared OS架构调度的最小单位应用容器模版远小于Shared Hardware架构调度最小单位虚拟机模版的体积，因此具有资源利用率高，弹性响应速度快的优点。未来Sha