数据隔离

　　对于IT软件服务商来说，他们所提供的传统企业软件系统大多基于multi-instance架构，即对于每一个客户组织，都有一个单独的软件系统实例为其服务，而搭建于云计算平台的软件系统则广泛的采用了Multi-tenancy架构，即单个软件系统实例服务于多个客户组织。在multi-instance架构下，由于每个客户拥有自己的软件实例，故不存在数据隔离的问题，但是在multi-tenancy架构下，由于所有客户数据将被共同保存在唯一一个软件系统实例内，因此需要开发额外的数据隔离机制来保证各个客户之间的数据不可见性并提供相应的灾备方案。

　　随着云计算技术的成熟，multi-tenancy也已不再是新鲜的概念，目前已经有几种相当成熟的架构用来帮助系统实现数据隔离：Shared schema multi-tenancy (下文简称为共享表架构)，Shared database， separated schema（下文简称为分离表架构）以及Separated database（下文简称为分离数据库架构）。

　　共享表架构：即所有的软件系统客户共享使用相同的数据库实例以及相同的数据库表，但是可以通过类似于下图中的TenantID字段来区分数据的从属。

　　因为共享表架构最大化的利用了单个数据库实例的存储能力，所以这种架构的硬件成本非常低廉，但是其程序开发者来说，却增加了额外的复杂度，由于多个客户的数据共存于相同的数据库表内，因此需要额外的业务逻辑来隔离各个客户的数据。此外，这种架构实现灾难备份的成本也十分高昂，不但需要专门编写代码实现数据备份，而且在恢复数据时，需要对数据库表进行大量的删除和插入操作，一旦数据库表包含大量其他客户的数据，势必对系统性能和其他客户的体验带来巨大的影响。

　　分离数据库架构： 即每个软件系统客户单独拥有自己的数据库实例。

　　相比于共享表架构，由于每个客户拥有单独的数据库实例，这种架构可以非常高效便捷的实现数据安全性和灾难备份，但是随之而来的缺点便是其硬件成本非常高昂。

　　分离表架构： 即软件系统客户共享相同的数据实例，但是每个客户单独拥有自己的由一系列数据库表组成的schema。

　　分离表架构 是一种折衷的multi-tenancy方案，在这种架构下，实现数据分离和灾难备份相对共享表架构更加容易一些，另一方面，它的硬件成本也较分离数据库架构为低。

　　无论是分离数据库还是分离表，抑或者是共享表，每种架构都有它的优点和不足，在设计云端系统时，系统架构师需要进行全面的分析和考量，综合各方面的因素以选择合适的multi-tenancy架构。一般说来，系统服务的客户数量越多，则越适合使用共享表的架构，对数据隔离性和安全性要求越高，则越适合使用分离数据库的架构。在超大型的云系统中，一般都会采用复合型的multi-tenancy架构，以平衡系统成本和性能，这其中Salesforce便是一个典型的案例。Salesforce.com最初搭建于共享表架构，但是随着新客户的不断签入，单纯的共享表架构已经很难满足日益增长的性能要求，Salesforce逐步开始在不同的物理区域搭建分布式系统。在全局上，salesforce.com以类似于分离数据库的架构运行，在单个区域内，系统则仍然按照共享表架构运行。

　　虽然在实施基于云平台的系统时，还存在着诸如技术曲线、第三方系统集成、运营管理等诸多障碍，但是如何解决私有数据安全问题仍旧会是影响未来云计算尤其是公有云计算发展的关键因素。当下，EMC，Cisco，VMWare等IT企业已经开始在云安全上加大研发力度，在不久的将来，基于云计算的数据安全有望得到解决，并使云计算真正迈向成熟。

    作者简介：李季奥博杰天技术经理，主要致力于基于Amazon EC2以及Windows A z u r e 平台的应用开发与研究工作。