系列文章之软件即服务的架构指导

系列文章之软件即服务的架构指导Copyright©MicrosoftCorporation2006.AllRightsReserved多用户数据体系结构2006年6月作者：FrederickChong、GianpaoloCarraro以及RogerWolter微软公司2©MicrosoftCorporation2006年版权所有。保留所有权力。致谢非常感谢PaulHenry在撰写技术内容方面给予的帮助。说明本文档所包含的信息代表了在发布之日，MicrosoftCorporation对所讨论问题的当前看法。因为微软必须顺应不断变化的市场情况，因而该文档不应理解为Microsoft单方面的承诺，Microsoft不保证所给信息在发布之日以后的准确性。本文档仅供参考。对于本文档中的信息，Microsoft不做任何明示、默示或法定的担保。遵守所有适用的版权法律是用户的责任。在不对版权法所规定的权利加以限制的情况下，若未获得MicrosoftCorporation明确的书面许可，不得为任何目的、以任何形式或手段（电子的、机械的、影印、录制等等）复制或传播本文的任何部分，也不得将其存储或引入到检索系统中。Microsoft可能拥有本文档主题所涉及到的专利、专利申请、商标、版权或其他知识产权。除非在Microsoft的任何书面许可协议中明确表述，否则获得本文档不代表您将同时获得这些专利、商标、版权或其他知识产权的任何许可证。除非另外注明，否则此处作为例子提到的公司、组织、产品、域名、电子邮件地址、徽标、人员、地点以及事件纯属虚构，决不意指，也不应由此臆测任何真实的公司、组织、产品、域名、电子邮件地址、徽标、人员、地点和事件。©2005MicrosoftCorporation，保留所有权利。Microsoft、VisualStudio以及.NET徽标均是MicrosoftCorporation在美国和／或其他国家的注册商标或商标。所有其他商标均是其各自所有者的财产。3©MicrosoftCorporation2006年版权所有。保留所有权力。引言信任，或是缺乏充分信任，都是妨碍“软件即服务”(SaaS)推广的首要问题。我们可以说，关于产品、客户、雇员、供应商等的数据是商业运营中最重要的资产。当然，SaaS的核心也是数据。SaaS应用使客户能通过网络集中存取数据，成本低于使用本地安装的应用。不过，为了充分发挥SaaS的优势，企业必须在一定程度上放弃对自身数据的控制，要在确保数据安全并避免泄密方面充分信赖SaaS服务商。为了赢得客户的信任，希望开展SaaS业务的架构师首先应创建成熟稳定、安全可靠的SaaS数据体系结构，使用户和客户都能够放心地将重要的商业数据交给第三方合伙伙伴进行管理和控制，而且该架构还应该能够以极低成本实现高效管理和维护。本文是我们介绍多用户应用设计系列文章中的第二篇。第一篇文章《抓住长尾市场的架构战略》从较高层面介绍了SaaS模式及其挑战和优势。该文的网络版刊登在MSDN上，网址为：msdn.microsoft.com/library/en-us/dnbda/html/ArchStratCtchLngTail.asp。本系列的其他文章将侧要于讨论工作流程、用户界面设计以及整体安全性等问题。在本文中，我们将讨论如何处理从完全隔离的数据直到完全共享的数据，并根据不同地点的数据隔离和共享情况指出创建数据体系结构的三种方法。随后，我们将探讨决定采用何种方法时应考虑的技术和商业因素。最后，针对确保安全性、创建可扩展数据模型以及数据基础结构的可扩展性等方面，我们将提出一些设计模式。管理多用户数据的三种方法共享数据和隔离数据之间并不是完全断裂的，而是在完全隔离到完全共享的两个极端上，数据在连续性层面上有许多不同。根据技术与商务考虑事项的不同，SaaS应用的数据架构在实现优化隔离的程度上会有很大差异。经验丰富的数据架构师在设计过程中要考虑多种选择，以解决一系列具体的问题，SaaS模式也不例外。我们将讨论三种基本方法，每种方法都对应于数据在隔离和共享之间不同的共享和隔离程度。独立数据库在彼此独立的数据库中存储用户数据是数据隔离的最简单方法。4©MicrosoftCorporation2006年版权所有。保留所有权力。图1.该方法针对每个用户采用不同的数据库。所有用户通常在服务器上共享计算资源和应用代码，但每个用户都拥有自己独立的一套数据，这些数据在逻辑上彼此隔离。元数据将每个数据库与相应的用户关联，数据库的安全机制防止用户无意或恶意存取其他用户的数据。为不同用户提供独立的数据库有助于简化应用数据模型（下面我们还会谈到这一点）的扩展，以满足不同用户的独特需求，而且在发生故障时从备份中恢复用户的数据也相对简单。不幸的是，这种方法通常会加大设备维护和用户数据备份的成本。硬件成本也高于采用其他方法的情况，因为给定数据库服务器上能够支持的数据库数量有限，这也就限制了其可以容纳的用户数量。（在无有效连接的情况下，我们可用自动关闭功能清空存储器中的数据库，从而提高应用的扩展性，进而增加每个服务器能支持的数据库数量。）将用户数据分别存储到不同的数据库中是“最佳”方法，不过这会导致硬件与维护要求较高，成本不菲，仅适用于那些愿意支付高额代价来换取更高安全性和可定制性的客户。举例来说，银行业或医疗记录管理等领域的客户通常有着较高的数据隔离要求，如果应用不能为有关数据提供独立的数据库，那么根本就不会考虑选择这种应用。共享数据库，不同用户采用不同架构另一种方法是让不同用户使用相同的数据库，每个用户都拥有自己的表集，形成用户各自专门的架构。5©MicrosoftCorporation2006年版权所有。保留所有权力。图2.就这种方法而言，用户共用数据库，每个用户都有自己的表集。客户最初成为此类服务的用户时，配置子系统会为该用户创建离散的表集，并将其与用户自己的架构相关联。客户可用SQLCREATE命令来创建方案，并授权能够存取该方案的用户账户。例如，在Microsoft®SQLServer™2005中：CREATESCHEMAContosoSchemaAUTHORIZATIONContoso这样，应用就能使用SchemaName.TableName约定来创建并存取用户架构中的表格：CREATETABLEContosoSchema.Resumes(EmployeeIDintidentityprimarykey,Resumenvarchar(MAX))创建架构后，将其设为用户账户的默认架构：ALTERUSERContosoWITHDEFAULT_SCHEMA=ContosoSchema用户账户通过指定表格名称即能存取默认架构中的表格，而不是采用SchemaName.TableName约定。这样，我们就可针对所有用户创建一组SQL语句，每个用户都能用来存取自己的数据：SELECT*FROMResumes与隔离式方法一样，独立架构方法也相对容易实施，用户能够像采用独立数据库方案一样轻松地扩展数据模型。（我们用标准的默认集创建表格，但如果表格一旦创建完成，就无需符合默认集，用户可根据需要添加或修改列甚至是表格。）这种方法为要求高安全性的用户提供了一定程度的逻辑数据隔离，不过并不能实现系统的完全隔离，同时每个数据库服务器能够支持的用户数量更多。独立架构式方案的主要缺点在于，如果发生故障，我们将难以恢复用户数据。如果每个用户都拥有自己的数据库，那么如果要恢复单个用户的数据，则只需从最近的备份中恢复即可。在采用独立架构式方案的情况下，恢复整个数据库意味着我们要用备份数据覆盖数据库上每个用户的数据，而不管具体哪个用户的数据是不是出了问题。因此，为了恢复单个客户的数据，管理员不得不将数据库恢复到临时服务器上，再将客户的表格导入至生成服务器，这一过程非常复杂，而且可能花费很长时间。6©MicrosoftCorporation2006年版权所有。保留所有权力。独立架构式方法适用于数据库表格数量相对较少的应用，每个用户的表格约为100或更少。采用这种方法，每个服务器支持的用户数量通常高于独立数据库方法，因此能降低应用的成本，但客户首先要接受让自己的数据与其他用户的数据共用数据库。共享数据库，共享架构第三种方案是针对多用户数据采用相同的数据库和相同的表集。给定表格包括以任一顺序存储的多个用户的记录；用户ID列将每条记录与相应用户关联。图3.采用这种方法，所有用户共享相同的表集，用户ID将用户与其所属行相关联。在已经介绍的三种方法中，共享架构方案的硬件和备份成本最低，因为其允许每个数据库服务器能够支持用户的数量最多。不过，由于多个用户共享同一组数据库表格，因此这种方法在安全性方面会加大开发工作量，以确保用户即便在发生故障或遭到攻击情况下也不会存取其他用户的数据。对于第三种方法而言，用户数据的恢复过程类似于共享架构方法，不过会增加一定的复杂性，需要删除生成数据库中的各行，然后再从临时数据库中重新插入。如果受影响表格中的行数非常多，那么这会使该数据库服务的所有用户的性能都大受影响。如果应用必须以较少的服务器为大量用户服务，而且新用户愿意为降低成本而牺牲数据隔离，那么共享架构方法就非常适用。方案选择在上面介绍的三种方法中，每种方法都有其自己的优缺点，有的情况适用，有的情况则不适用，这取决于各种商业和技术方面的考虑。我们将在下列部分介绍一些有关考虑事项。经济问题针对共享方法而精心优化的应用通常比采用隔离程度较高的方法要做更多的开发工作（因为开发共享体系结构相对较复杂），因而初期成本较高。由于共享体系结构在每台服务器上能免支持更多用户，因此这种方法的运营成本相对偏低。7©MicrosoftCorporation2006年版权所有。保留所有权力。图4：两种假设SaaS应用的时间成本；一种应用采用隔离方案，另一种则采用共享方案。开发工作通常会受商业与经济因素的制约，并会在方案的选择上发挥影响。从长期来看，共享架构方案有助于节约资金，不过在在创造收入之前需要较大量的初期开发工作。如果您不能承担共享架构应用的开发成本，或者您需要比超大规模开发所能允许的时间更为快速地向市场推出应用，那么您就可以考虑隔离式方法。安全性考虑因素由于应用会存储敏感的用户数据，因此潜在的客户对安全性会有很高要求，服务级别协议(SLA)将需要提供强大的数据安全保障。人们通常误认为，只有物理隔离才能确保安全。事实上，共享方案存储的数据也能实现强大的数据安全性，但这要求采用更先进的设计技术。用户考虑事项您预计要服务的用户数量、性质以及需求等都会在各个方面影响数据体系结构的决策。以于下列某些问题，隔离方法与共享方法各有千秋。•您预计要为多少潜在用户提供服务？您可能很难准确地估计潜在的使用量，不过大致应当有个数量级范围，如应用是为数百用户提供服务，还是数千、数万、乃至更多？您预计接受服务的用户数量越多，您就会越倾向于考虑共享方案。•您预计用户数据平均占用多大的存储空间？如果您预计部分用户或全部用户会存储大量数据，那么隔离式方法会更适用。（事实上，数据存储需求本身就需要独立数据库模型。因此，我们宁可从一开始就采用独立数据库方案来设计应用，而不是以后再进行移植。）•您预计需要同时支持的平均用户数有多少？同时支持的最终用户越多，就越应当采用隔离式方案，这样才有助于满足最终用户的要求。•您是否预计要提供针对每个用户的增值服务，如针对特定用户的备份和恢复功能？隔离式方案更适合提供此类服务。8©MicrosoftCorporation2006年版权所有。保留所有权力。NumberofTenantsDatabasesizepertenantNumberofuserspertenantPer-tenantvalue-addedservicesIsolatedShared图5：与用户相关的因素及其对“隔离式或共享式”数据体系结构决策的影响。行业监管考虑相关监管法规会对企业、组织和政府部门的安全和记录存储要求产生影响。您应针对将要开展运营的市场中客户所处的