据维基百科定义,多租户是一种软件架构技术,它是在探讨与实现如何于多用户的环境下共用相同的系统或程序组件,并且仍可确保各用户间数据的隔离性。在多租户技术中,租户(tenant)是指使用系统或电脑运算资源的客户。
普通WEB应用几乎都是服务于一个独立客户,并且一般运行于客户的服务器资产上。如何把普通WEB应用转换为多租户应用?我们认为需要从多租户支持、租户管理、安全、性能、租户个性化等五个方面改造。
一,多租户支持
多租户可以根据共享的程度分为几个不同的类别,Gartner的划分,如下图:
根据应用场景的不同我们可以选择不同的租户共享级别,比如,若租户规模较小,技术力量薄弱,可以选择第二种Shared Hardware的方式,购买虚拟机,在硬件虚拟化层面实现多租户。由于应用场景、技术积累的不同我们也可以采用其它的多租户方案。普通WEB应用转化为多租户,可以分两个方面考虑:
1,不修改应用的基础架构
如果我们不修改WEB应用的基础结构,可以在程序级别来完成把普通WEB应用转化为多租户应用,这种方式更接近上图划分中第7种,优点可以保护以前的WEB应用中的投资,不用购买昂贵的虚拟化软件,自己控制方便灵活;缺点是租户扩展性差。核心只有两点:
1,修改数据库模式,向每个表和视图添加一个租户标识符(tenant_id)。
2,对程序中的SQL语句添加租户过滤条件(查询数据,新增数据)。如果代码中任何必要的部分缺少这一逻辑,那么都将损害应用程序的数据安全性。
对数据库模式的修改相对简单,只要加上tenant_id字段即可,但对于修改代码中SQL语句我们可以采用多种策略:
1,扫描代码,采用第三方或自己编写的代码扫描工具,把所有的SQL语句或者O/R Mapping工具的xQL语句,手动加上租户过滤条件,这需要大量的测试以保证全部修改正确。
2,动态修改SQL语句,增加租户过滤条件。并不修改程序代中的SQL语句,而是扩展程序代码依赖的第三方库(如对Hibernate、JDBC进行扩展),对执行的SQL语句动态修改。商业产品 Corent 就是采用这种策略。
3,修改数据库的存储、查询引擎,使其对多租户感知,这个难度非常大。
2,修改应用的基础架构
如果要实现大规模运营,特别是企业应用的运营,如果要实现每个租户的个性化扩展,Shared Everything 的架构技术是我们最好的选择。这种架构通常采用元数据驱动的方式,需要更改应用的整体架构。EEPlat提供了这种技术,最后一部分会有所涉及。
二,租户管理
租户管理包含很多方面,如:
1)自主注册、订阅
2)计费、优惠策略
3)租户监控、管理
4)服务水平协议(SLA)管理
由于是新增的模块,和改造的关系不大,不展开讨论。
三,安全
云计算对网络安全提出了更严格的要求。从云计算租户的角度来看,网络、设备、应用、数据都不在自己的控制之下,甚至都不知道具体的物理位置,如何保障数据安全和业务连续性显然就成了最大的挑战。
从云提供商的角度来看,传统模式下的网络安全需求并没有什么变化,无论从信息安全的保密性、完整性、可用性,还是根据网络层次划分的从物理层到应用层安全,仍然是需要解决的问题。传统模式下的网络安全解决方案中,最重要的一点就是建立网络边界,区分信任域和非信任域,然后在网络边界进行访问控制和安全防御。而云计算资源池与Internet之间仍然是有边界的,在资源池内部由于管理的需要,也会有不同域的划分,从而形成内部边界。这意味着传统的网络安全产品能继续发挥其作用。我们认为除了常规安全配置,还可以从以下几个方面加强:
1,数据安全,采用的策略可以有:
1),SSL传输
2),租户数据独立加密
3),数据多处、多物理位置存储
4),在线定时备份
这些策略对原有应用的的改造较小,只是增加了基础设置的安全性。
2,程序安全,采用的策略可以有:
1),程序代码经过如fortify 此类代码扫描工具的检查,重点防止的漏洞包括XSS攻击、SQL注入、Header Manipulation 、Path Manipulation等等。
2),必要时修改代码,以增加代码的安全性, 如图片验证码,手机短信确认等,以防止机器人。
这些策略对应用的的改造取决于其代码安全成熟度和业务场景,由于普通WEB应用大多运行于内网,开发者并没有把它放入公网的安全意识,大多数应用都需要修改。
3,认证安全,采用的策略可以有:
1),保证每个访问帐号的唯一性
2),访问机器的授权
3),密码控件
4),短信登录
5),软证书或U盾的采用
6),用户Session控制
这些策略对应用的的改造主要集中于登录模块。
性能和可扩展性
考虑到租户规模以及业务数据会不断增加,我们需要面对性能和扩展性的问题,现在大型网站已经有很多相关经验分享,可以参考采用,由于企业业务和多租户的特点,我们还可以从以下方面加强:
1,数据库租户分区优化
需要采用支持分区的数据库版本,如mysql 从5.1 才开始支持。随共享数据库由于采用分区技术,也几乎相当于“独享”。
2,关系数据库和NoSQL结合
NoSQL数据库处理海量数据有天然的优势,可以考虑把一些非关键、非事务的数据放入NoSQL。
3,使用租户感知的缓存
缓存的使用可以大大减少磁盘的IO,采用租户感知的缓存系统可以大大提高缓存的命中率,以及增强了数据安全。
4,无状态的系统设计
无状态系统设计是大规模运营的关键,即不依赖于本机的会话(session)以及本地文件系统等。
租户个性化
对于多租户的应用,不同租户的需求几乎都是有差异的,每个租户要求定制化他们的应用也是很自然的。如果这个多租户应用是静态编译的二进制文件,那么满足这些多租户的要求及其他个性化的挑战是几乎不可能的。除了一些功能单一的应用(如邮件服务),多租户的应用,应该在其功能、界面等方面,满足不同租户的合理要求。
普通WEB应用大多数是静态编译的二进制文件,如果满足租户的个性化需求,必须修改应用程序。即是在程序中很小心的采用多态技术,但是随着租户的增加,子类的爆炸也会使其程序很难维护,维护成本无法承受,另外原有程序的多态改造的成本也非常高。
解决租户个性化的根本途径是采用元数据驱动的方式改造程序架构。云鹤PaaS应用平台(EEPlat)可以作为改造的基础。云鹤PaaS应用平台(EEPlat)可以根据不同租户定义的元数据生成相对应的应用程序,而不是采用经过编译的 二进制的可执行文件。
模型驱动开发是EEPlat的核心和基础,在模型的基础上,EEPlat又进行了进一步的抽象,称之为元模型 (metamodel),这样又进一步提高了系统的灵活性和可扩展性。
EEPlat执行引擎、基础功能元数据(通用模型)、每个租户的元数据(租户相关模型),每个租户的业务数据之间有一个明确的分离。这些明显的边界使我们可以安全得定制或修改租户的应用程序而不会影响其它租户。
下图中,我们把模型分为了通用模型和租户相关模型,在EEPlat的具体实现上,通用模型和租户相关业务几乎没有任何关系,只是为了完成模型本身的管理,和保持元模型的版本一致性。
云鹤PaaS应用平台可以分为三大部分:数据存储、元模型体系、执行引擎,下图是整体架构图:
更多EEPlat的资料参见http://code.google.com/p/eeplat/ 。
普通WEB应用转化多租户应用,可以根据应用的不同有裁剪得采用不同的策略。如果转化进度紧迫,或者功能单一,可以不修改其程序架构。如果需要长期运行、功能复杂、租户有个性化要求,那么修改程序架构为元数据驱动是更好的选择。