花千骨妖神续写甜文:多用户数据体系结构

系列文章之软件即服务的架构指导
Copyright © Microsoft Corporation 2006. All Rights Reserved
多用户数据体系结构
2006 年 6 月
作者：Frederick Chong、Gianpaolo Carraro 以及 Roger Wolter
微软公司
2
© Microsoft Corporation 2006 年版权所有。保留所有权力。
致谢
非常感谢 Paul Henry 在撰写技术内容方面给予的帮助。
说明
本文档所包含的信息代表了在发布之日，Microsoft Corporation 对所讨论问题的当前看法。因
为微软必须顺应不断变化的市场情况，因而该文档不应理解为 Microsoft 单方面的承诺，
Microsoft 不保证所给信息在发布之日以后的准确性。
本文档仅供参考。对于本文档中的信息，Microsoft 不做任何明示、默示或法定的担保。
遵守所有适用的版权法律是用户的责任。在不对版权法所规定的权利加以限制的情况下，若未
获得 Microsoft Corporation 明确的书面许可，不得为任何目的、以任何形式或手段（电子的、
机械的、影印、录制等等）复制或传播本文的任何部分，也不得将其存储或引入到检索系统
中。
Microsoft 可能拥有本文档主题所涉及到的专利、专利申请、商标、版权或其他知识产权。除非
在 Microsoft 的任何书面许可协议中明确表述，否则获得本文档不代表您将同时获得这些专
利、商标、版权或其他知识产权的任何许可证。
除非另外注明，否则此处作为例子提到的公司、组织、产品、域名、电子邮件地址、徽标、人
员、地点以及事件纯属虚构，决不意指，也不应由此臆测任何真实的公司、组织、产品、域
名、电子邮件地址、徽标、人员、地点和事件。
© 2005 Microsoft Corporation，保留所有权利。
Microsoft、Visual Studio 以及 .NET 徽标均是 Microsoft Corporation 在美国和／或其他国家的
注册商标或商标。
所有其他商标均是其各自所有者的财产。
3
© Microsoft Corporation 2006 年版权所有。保留所有权力。
引言
信任，或是缺乏充分信任，都是妨碍“软件即服务”(SaaS) 推广的首要问题。我们可以说，关于产
品、客户、雇员、供应商等的数据是商业运营中最重要的资产。当然，SaaS 的核心也是数据。SaaS
应用使客户能通过网络集中存取数据，成本低于使用本地安装的应用。不过，为了充分发挥 SaaS 的
优势，企业必须在一定程度上放弃对自身数据的控制，要在确保数据安全并避免泄密方面充分信赖
SaaS 服务商。
为了赢得客户的信任，希望开展 SaaS 业务的架构师首先应创建成熟稳定、安全可靠的 SaaS 数据体
系结构，使用户和客户都能够放心地将重要的商业数据交给第三方合伙伙伴进行管理和控制，而且该架
构还应该能够以极低成本实现高效管理和维护。
本文是我们介绍多用户应用设计系列文章中的第二篇。第一篇文章《抓住长尾市场的架构战略》从较高
层面介绍了 SaaS 模式及其挑战和优势。该文的网络版刊登在 MSDN 上，网址为：
msdn.microsoft.com/library/en-us/dnbda/html/ArchStratCtchLngTail.asp。本系列的其他文
章将侧要于讨论工作流程、用户界面设计以及整体安全性等问题。
在本文中，我们将讨论如何处理从完全隔离的数据直到完全共享的数据，并根据不同地点的数据隔离和
共享情况指出创建数据体系结构的三种方法。随后，我们将探讨决定采用何种方法时应考虑的技术和商
业因素。最后，针对确保安全性、创建可扩展数据模型以及数据基础结构的可扩展性等方面，我们将提
出一些设计模式。
管理多用户数据的三种方法
共享数据和隔离数据之间并不是完全断裂的，而是在完全隔离到完全共享的两个极端上，数据在连续性
层面上有许多不同。
根据技术与商务考虑事项的不同，SaaS 应用的数据架构在实现优化隔离的程度上会有很大差异。经验
丰富的数据架构师在设计过程中要考虑多种选择，以解决一系列具体的问题，SaaS 模式也不例外。我
们将讨论三种基本方法，每种方法都对应于数据在隔离和共享之间不同的共享和隔离程度。
独立数据库
在彼此独立的数据库中存储用户数据是数据隔离的最简单方法。
4
© Microsoft Corporation 2006 年版权所有。保留所有权力。
图 1. 该方法针对每个用户采用不同的数据库。
所有用户通常在服务器上共享计算资源和应用代码，但每个用户都拥有自己独立的一套数据，这些数据
在逻辑上彼此隔离。元数据将每个数据库与相应的用户关联，数据库的安全机制防止用户无意或恶意存
取其他用户的数据。
为不同用户提供独立的数据库有助于简化应用数据模型（下面我们还会谈到这一点）的扩展，以满足不
同用户的独特需求，而且在发生故障时从备份中恢复用户的数据也相对简单。不幸的是，这种方法通常
会加大设备维护和用户数据备份的成本。硬件成本也高于采用其他方法的情况，因为给定数据库服务器
上能够支持的数据库数量有限，这也就限制了其可以容纳的用户数量。（在无有效连接的情况下，我们
可用自动关闭功能清空存储器中的数据库，从而提高应用的扩展性，进而增加每个服务器能支持的数据
库数量。）
将用户数据分别存储到不同的数据库中是“最佳”方法，不过这会导致硬件与维护要求较高，成本不
菲，仅适用于那些愿意支付高额代价来换取更高安全性和可定制性的客户。举例来说，银行业或医疗记
录管理等领域的客户通常有着较高的数据隔离要求，如果应用不能为有关数据提供独立的数据库，那么
根本就不会考虑选择这种应用。
共享数据库，不同用户采用不同架构
另一种方法是让不同用户使用相同的数据库，每个用户都拥有自己的表集，形成用户各自专门的架构。
5
© Microsoft Corporation 2006 年版权所有。保留所有权力。
图 2. 就这种方法而言，用户共用数据库，每个用户都有自己的表集。
客户最初成为此类服务的用户时，配置子系统会为该用户创建离散的表集，并将其与用户自己的架构相
关联。客户可用 SQL CREATE 命令来创建方案，并授权能够存取该方案的用户账户。例如，在
Microsoft® SQL Server™ 2005 中：
CREATE SCHEMA ContosoSchema AUTHORIZATION Contoso
这样，应用就能使用 SchemaName.TableName 约定来创建并存取用户架构中的表格：
CREATE TABLE ContosoSchema.Resumes (EmployeeID int identity primary key,
Resume nvarchar(MAX))
创建架构后，将其设为用户账户的默认架构：
ALTER USER Contoso WITH DEFAULT_SCHEMA = ContosoSchema
用户账户通过指定表格名称即能存取默认架构中的表格，而不是采用 SchemaName.TableName 约
定。这样，我们就可针对所有用户创建一组 SQL 语句，每个用户都能用来存取自己的数据：
SELECT * FROM Resumes
与隔离式方法一样，独立架构方法也相对容易实施，用户能够像采用独立数据库方案一样轻松地扩展数
据模型。（我们用标准的默认集创建表格，但如果表格一旦创建完成，就无需符合默认集，用户可根据
需要添加或修改列甚至是表格。）这种方法为要求高安全性的用户提供了一定程度的逻辑数据隔离，不
过并不能实现系统的完全隔离，同时每个数据库服务器能够支持的用户数量更多。
独立架构式方案的主要缺点在于，如果发生故障，我们将难以恢复用户数据。如果每个用户都拥有自己
的数据库，那么如果要恢复单个用户的数据，则只需从最近的备份中恢复即可。在采用独立架构式方案
的情况下，恢复整个数据库意味着我们要用备份数据覆盖数据库上每个用户的数据，而不管具体哪个用
户的数据是不是出了问题。因此，为了恢复单个客户的数据，管理员不得不将数据库恢复到临时服务器
上，再将客户的表格导入至生成服务器，这一过程非常复杂，而且可能花费很长时间。
6
© Microsoft Corporation 2006 年版权所有。保留所有权力。
独立架构式方法适用于数据库表格数量相对较少的应用，每个用户的表格约为 100 或更少。采用这种
方法，每个服务器支持的用户数量通常高于独立数据库方法，因此能降低应用的成本，但客户首先要接
受让自己的数据与其他用户的数据共用数据库。
共享数据库，共享架构
第三种方案是针对多用户数据采用相同的数据库和相同的表集。给定表格包括以任一顺序存储的多个用
户的记录；用户 ID 列将每条记录与相应用户关联。
图 3. 采用这种方法，所有用户共享相同的表集，用户 ID 将用户与其所属行相关联。
在已经介绍的三种方法中，共享架构方案的硬件和备份成本最低，因为其允许每个数据库服务器能够支
持用户的数量最多。不过，由于多个用户共享同一组数据库表格，因此这种方法在安全性方面会加大开
发工作量，以确保用户即便在发生故障或遭到攻击情况下也不会存取其他用户的数据。
对于第三种方法而言，用户数据的恢复过程类似于共享架构方法，不过会增加一定的复杂性，需要删除
生成数据库中的各行，然后再从临时数据库中重新插入。如果受影响表格中的行数非常多，那么这会使
该数据库服务的所有用户的性能都大受影响。
如果应用必须以较少的服务器为大量用户服务，而且新用户愿意为降低成本而牺牲数据隔离，那么共享
架构方法就非常适用。
方案选择
在上面介绍的三种方法中，每种方法都有其自己的优缺点，有的情况适用，有的情况则不适用，这取决
于各种商业和技术方面的考虑。我们将在下列部分介绍一些有关考虑事项。
经济问题
针对共享方法而精心优化的应用通常比采用隔离程度较高的方法要做更多的开发工作（因为开发共享体
系结构相对较复杂），因而初期成本较高。由于共享体系结构在每台服务器上能免支持更多用户，因此
这种方法的运营成本相对偏低。
7
© Microsoft Corporation 2006 年版权所有。保留所有权力。
图 4：两种假设 SaaS 应用的时间成本；一种应用采用隔离方案，另一种则采用共享方案。
开发工作通常会受商业与经济因素的制约，并会在方案的选择上发挥影响。从长期来看，共享架构方案
有助于节约资金，不过在在创造收入之前需要较大量的初期开发工作。如果您不能承担共享架构应用的
开发成本，或者您需要比超大规模开发所能允许的时间更为快速地向市场推出应用，那么您就可以考虑
隔离式方法。
安全性考虑因素
由于应用会存储敏感的用户数据，因此潜在的客户对安全性会有很高要求，服务级别协议 (SLA) 将需
要提供强大的数据安全保障。人们通常误认为，只有物理隔离才能确保安全。事实上，共享方案存储的
数据也能实现强大的数据安全性，但这要求采用更先进的设计技术。
用户考虑事项
您预计要服务的用户数量、性质以及需求等都会在各个方面影响数据体系结构的决策。以于下列某些问
题，隔离方法与共享方法各有千秋。
• 您预计要为多少潜在用户提供服务？您可能很难准确地估计潜在的使用量，不过大致应当有个数量
级范围，如应用是为数百用户提供服务，还是数千、数万、乃至更多？您预计接受服务的用户数量
越多，您就会越倾向于考虑共享方案。
• 您预计用户数据平均占用多大的存储空间？如果您预计部分用户或全部用户会存储大量数据，那么
隔离式方法会更适用。（事实上，数据存储需求本身就需要独立数据库模型。因此，我们宁可从一
开始就采用独立数据库方案来设计应用，而不是以后再进行移植。）
• 您预计需要同时支持的平均用户数有多少？同时支持的最终用户越多，就越应当采用隔离式方案，
这样才有助于满足最终用户的要求。
• 您是否预计要提供针对每个用户的增值服务，如针对特定用户的备份和恢复功能？隔离式方案更适
合提供此类服务。
8
© Microsoft Corporation 2006 年版权所有。保留所有权力。
Number of Tenants
Database size per tenant
Number of users per tenant
Per-tenant value-added services
Isolated Shared
图 5：与用户相关的因素及其对“隔离式或共享式”数据体系结构决策的影响。
行业监管考虑
相关监管法规会对企业、组织和政府部门的安全和记录存储要求产生影响。您应针对将要开展运营的市
场中客户所处的法律法规管理环境进行调查，确定其会对您的设计决策产生哪些影响。
综合技能考虑
单实例、多用户体系结构的设计仍是一门很新的技术，因而很难获得相关领域的专业知识。如果架构师
和支持人员在构建 SaaS 应用方面没什么经验，那么他们应掌握必需的知识，否则就必需聘请有经验
的人士。在有些情况下，相对于共享方案，隔离式方案更有助于员工充分利用一些传统软件开发的现有
知识。
实现多用户数据体系结构
本文其余部分将详细讨论一些规划和构建 SaaS 应用的模式。正如我们在引文中介绍的一样，良好设
计的 SaaS 应用需具备三大特点：可扩展性、可配置性以及多用户效率。下表针对三种方案列出了相
应的设计模式，并将其分成各自代表不同特点的部分。
在共享环境中优化多用户效率不得影响数据存取的安全性。以下列出的安全因素指出，您可通过诸如权
限、SQL 视图以及加密等“虚拟隔离”机制来进行应用设计。
可配置性使 SaaS 用户能改变应用的外观和行为，而无需针对每个特定的用户提供额外的应用实例。
可扩展性模式介绍了用户可分别用于扩展和配置单个数据模型的方法，以满足其独特需要。
您对 SaaS 应用数据体系结构所做的决策将影响体系结构扩展的选择，影响到您采取哪些措施才能满
足更多用户、更大用量的需求。可扩展模式解决了共享数据库和专用数据库在可扩展性所提出的不同挑
战。
方案 安全模式 可延伸模式 (Extensibility
Pattern)
可扩展模式
9
© Microsoft Corporation 2006 年版权所有。保留所有权力。
Error!
Reference
source not
found.
• 受信任数据库连接
• 安全的数据库表格
• 用户数据加密
• 定制列 • 单用户横向扩展
共享数据库， • 受信任数据库连接
• 安全的数据库表格
• 用户数据加密
• 定制列 • 基于用户的横向分
组
Error!
Reference
source not
found.
• 受信任数据库连接
• 用户视图过滤
• 用户数据加密
• 预分配字段
• 名称值对
• 基于用户的横向分
组
安全模式
对于 SaaS 架构设计师而言，确保应用的各个方面足够安全都是一顶非常重要的任务。推动 SaaS
理念的发展，就必须让潜在的客户放弃商业数据的部分控制。根据应用的不同，具体而言，这意味着可
能要放弃控制一些极为敏感的数据，如财务、商业秘密以及员工数据等。安全的 SaaS 应用能提供深
度防御，采用多种分级防御机制，互相配合，在不同情况下以不同方式确保数据安全，防范内外部风
险。
确保 SaaS 应用的安全性要求我们查看应用不同层次的问题，思考哪里会出风险，并解决风险。本部
分的安全模式依靠三种基本模式在正确的位置实现出色的安全性：
• 过滤：在用户和数据源之间采用功能像筛子一样的中间层 (intermediary layer)，以使用户感到
自己获取的数据就是数据库中唯一的数据；
• 权限：采用访问控制列表 (ACL) 来决定谁能访问应用中的数据，以及能对数据进行哪些操作；
• 加密：对每个用户的重要数据进行加密，以使未授权方无法对其进行访问，即便获得了这些数据，
也派不上用场。
在阅读本节其他部分时，请记住上述内容。
受信任的数据连接
在多层应用环境中，应用架构师传统上采用两种方法来确保安全存取数据库中存储的数据：一是模拟
(impersonation)，二是受信任的子系统帐户。
采用模拟存取方法时，对数据库进行设置以允许不同用户存取不同的表格、视图并进行查询、使用存储
的程序以及其他数据库对象等。如果终端用户执行的操作直接或间接要求数据库调用的话，那么应用就
作为该用户来处理数据库，具体而言就是以存取数据库为目的模拟该用户。（用技术术语来说，该应用
采用的是用户的安全上下文。）我们可采用 Kerberos 委派等机制来使应用进程代表用户连接至数据
库。
10
© Microsoft Corporation 2006 年版权所有。保留所有权力。
图 6. 应用以模拟方式连接至数据库。
采用受信任子系统存取方法时，应用总使用自己的应用进程身份与数据库连接，而不管用户的身份如
何；服务器随后授权应用存取数据库对象，以使应用可进行读取或操作。额外的安全机制应在应用内部
实施，以避免不同的最终用户存取不该获得的数据库对象。这种方法能简化安全管理，不再需要为每位
用户配置数据库对象的存取，但却难以为不同的用户确保数据库对象的安全。
图 7. 应用作为受信任子系统连接至数据库。
在 SaaS 应用中，“用户”的概念比在传统应用中更为复杂，因为我们应区别用户和最终用户。用户
是通过应用访问自己数据存储区的组织，其数据存储区在逻辑上通常与其他租户相隔离。每个用户为一
个或更多最终用户的应用存取授权，使其能够通过用户控制的最终用户帐户存取用户数据的某一部分。
在此情况下，我们可用综合方案来进行数据存取，结合采用模拟和受信任子系统存取方法。这使您能够
充分发挥数据库服务器本机安全机制的作用，确保用户数据的逻辑隔离最大化，而无须无谓地提高安全
模型的复杂性。
11
© Microsoft Corporation 2006 年版权所有。保留所有权力。
图 8. SaaS 应用结合采用模拟与受信任子系统方法与数据库连接。
这种方案需要为每个用户建立数据库存取帐户，并用 ACL 为每个用户账户授权，以使其能够访问被允
许使用的数据库对象。如果最终用户执行的操作直接或间接要求调用数据库，那么应用会采用与用户帐
户相关联的凭证、而不是与最终用户关联的凭证1。数据库服务器不区别区分来自相同用户的不同最终
用户请求，而是直接允许这些最终用户访问该用户的数据。在应用内部，安全代码可避免最终用户接收
和修改任何其无权访问的数据。
举例来说，我们不妨设想客户关系管理 (CRM) 应用中的一名最终用户，其执行某项操作以查询数据库
中匹配于某个字符串的记录。应用通过该用户的安全上下文向数据库发送请求，因此应用不会返回数据
库中的所有匹配记录，查询只会检索用户有权存取的匹配行。说到这里，上述应用还没有出现什么问
题。不过，我们不妨假设最终用户的角色只允许其访问某一地理区域内的客户记录2。这时，应用必须
截获查询结果，只向用户提供其权限范围内可以看到的记录。
安全的数据库表格
为了确保数据库在表格级的安全，可以使用 SQL 的 GRANT 命令为用户授予访问表格或其他数据库对
象的用户账户：
GRANT SELECT, UPDATE, INSERT, DELETE ON [TableName] FOR [UserName]
1 应用获得正确凭证的一种方法是通过模拟方式，并结合采用 Kerberos 等凭证体系。另一种方法是采
用安全令牌服务，以返回一组为用户建立的实际加密登录凭证，然后应用进程向数据库提交。
2 如欲了解有关角色的更多详情，敬请参见本系列文章中第一篇《抓住长尾市场的架构战略》的“认
证”部分。
12
© Microsoft Corporation 2006 年版权所有。保留所有权力。
这会向 ACL 表格添加用户帐户。如果您采用上述数据库存取的综合方式，那么应使最终用户与其相应
用户的安全上下文相关联，这仅需在用户配置过程中执行一次即可；随后由该用户创建的任何最终用户
帐户都能对表格进行存取。
上述方式适用于独立数据库和独立架构方案的使用方法。对于独立数据库方案而言，您只需限制与数据
库相关联用户对数据库的访问级别就可实现数据隔离，不过您也可以在表格层面上采用上述方法，从而
创建另一层的安全性。
用户视图过滤
可将 SQL 视图用于向各用户存取给定表格中的某些行授权，同时避免他们存取其他行。
在 SQL 中，视图是 SELECT 查询结果定义的虚拟表格。然后还可以对最终视图进行查询，并将其作
为实际数据库那样用于存储的程序中。例如，下列 SQL 语句将创建称作雇员的表格视图，该视图经过
过滤后仅显示属于单个用户的行：
CREATE VIEW TenantEmployees AS
SELECT * FROM Employees WHERE TenantID = SUSER_SID()
上述语句可获得存取数据库的用户帐户（如前所述，这是属于用户的帐户，而不属于最终用户）的安全
标识符 (SID)，并用其确定视图中应包含哪些行3。各个用户的数据存取帐户只有获得权限后才能使用
TenantEmployees 视图，但不会获得雇员源表本身的存取权限。您可以创建相关查询和共享程序
来充分发挥视图的优势，这使用户即便在多用户数据库中也能实现数据隔离的外观。
上述方法比安全数据库表略为复杂，不过适合在共享架构应用中确保用户数据的安全性，在该应用中
多个用户共享相同的表集。
用户数据加密
进一步保护用户数据的一种方法是在数据库中进行数据加密，这样即便数据落入他人之手，也能确保其
安全性。
加密方法分为对称式和非对称式。就对称式加密而言，我们要生成一个可进行数据加密和解密的密钥。
采用对称密钥加密的数据可用该密钥解密。就非对称式（也称为公钥加密）加密而言，我们采用两个密
钥，分别是公钥和私钥。用给定公钥加密的数据只能用相应的私钥解密，反之亦然。通常来说，应向任
一以及与密钥拥有方通信的所有相关方发布公钥，但需要对私钥严加保密。举例来说，如果爱丽丝想向
鲍勃发送加密信息，她需要通过双方同意的方式获得鲍勃的公钥，用其加密消息。只有拥有鲍勃私钥的
人才能对最终的加密消息或加密文本解密（从实践上说，这个人只能是鲍勃）。在这种情况下，鲍勃不
必与爱丽丝共用其私钥。如以对称加密方式向鲍勃发送信息，那么爱丽丝就要分别发送对称密钥，这就
会产生密钥传输时被第三方截获的风险。
公钥加密比对称加密的计算强度要求要高得多；强大的密钥对的数据加密和解密时间比类似质量的对称
密钥要长数百乃至数千倍。对于所有存储数据都加密的 SaaS 应用而言，要是所有数据都用公钥加密
的话，那么就最终的处理开销而言这实际上是不可能的。更好的办法是采用密钥封装 (key wrapping)
系统，以将两种系统的优势相结合。
3 本示例假设唯一用户 ID 与用户的 SID 相同。如果不同，那么应采用一步或更多步骤将用户与正确
的行相关联。
13
© Microsoft Corporation 2006 年版权所有。保留所有权力。
采用这种方案时，每个用户都会作为配置进程的一部分创建三个密钥：一个对称密钥、一个包含公钥和
私钥的非对称密钥对。可将效率较高的对称密钥用于加密用户的重要数据，以用于存储。为了增加另一
层安全性，可将公钥或私钥对用来加密并解密对称密钥，以确保其安全，防范非法入侵者。
最终用户登录时，应用以模拟方式使用用户的安全上下文存取数据库，这使应用进程能够访问用户的私
钥。应用（当然，仍以模拟方式作为用户）然后可用用户的私钥解码用户的对称密钥，用其读写数据。
这是深入防御理论的又一实用范例。对于重视安全性的 SaaS 服务商来说，用户数据的意外泄漏或遭
恶意攻击就是一场噩梦，我们可通过上述方法提供多级安全性。第一层防线是数据库级的防线，其需要
避免最终用户存取其他用户的专用数据。如果出现故障或数据库服务器中出现病毒，导致向用户提供不
正确的行，那么没有用户的私钥，行的解密数据也会是无效的。
SaaS 应用越趋于隔离/共享连续体的“共享”方案，加密的重要性就越高。对于牵涉高价值数据或重
视隐私的情况来说，或当多个用户共享同一组数据库表集时，加密尤其重要。
由于我们不能将已加密的列编入索引，因此选择表格哪些列进行加密时就要权衡考量，平衡数据安全性
和数据库的性能。在做加密决策时，我们要考虑数据模型中各种不同数据的使用情况和敏感性。
可延伸性模式
根据设计，应用自然会包括标准的数据库设置，带有与您解决方案属性相对应的默认表、字段、查询以
及关系等。但是，不同的企业会有着各自独特的需求，而僵化的、没有延伸性的默认数据模型是无法解
决这些具体问题的。举例来说，SaaS 职位跟踪系统 (SaaS job-tracking system) 的一个客户可能
需要配合每个记录存储外部生成的分类代码串，以将系统与其他进程全面集成。另一位客户可能不需要
分类字符串字段，但却要求支持跟踪整数类型的 ID 号。因此，在许多情况下，您所开发和实施的方法
都应使客户能延伸默认的数据模型以满足需要，同时又不会影响其他客户对数据模型的使用。
预分配字段
实现数据模型可延伸性的方法很简单，即在希望实现用户可延伸性的每个表格中创建一定预设数量的定
制字段。
图 9. 带有一组定制字段、标记为 C1 ～ C3 的表格。
在上图中，同一表格中混有不同客户的记录；用户 ID 字段将每个记录与相应的用户相关联。除了标准
的一组字段外，我们还提供一系列定制字段，每个客户可决定如何使用这些定制字段，以及如何针对这
些定制字段收集数据。
数据类型的问题怎么解决呢？这也很简单，您只需为所创建的每个定制字段选择一般的数据类型即可，
不过客户可能会觉得这种方法限制性过强。有的客户可能需要三个额外的字符串字段，而我们可能只提
供了一个字符串字段、一个整数字段以及一个布尔字段 (boolean field)。那怎么才能实现灵活性呢？
一种方法是针对每个定制字段采用字符串数据类型，并使用元数据来跟踪用户希望使用的“真实”数据
类型。
14
© Microsoft Corporation 2006 年版权所有。保留所有权力。
图 10. Web 页面上的定制字段由元数据表中的项目定义。
在上例中，用户使用了应用的可延伸特性向数据输入屏幕添加了称为“寄件人邮政编码”的文本框，并
将该文本框映射至称为 C1 的定制字段。创建文本框时，用户使用了确认逻辑（此处未显示）以要求
文本框包含的是整数。实施后，这一定制字段由元数据表中的一条记录来定义，该表包括了用户唯一的
ID 号 (1017)、用户为该字段所选的标记（“寄件人邮政编码”），以及用户希望该字段使用的数据
类型（“整数”）。
您可在统一的元数据表中跟踪所有应用的定制字段的字段定义，或为每个定制字段使用不同的表格；例
如，“C1”表会定义每个使用 C1 定制字段的用户，“C2”表执行的操作与此相同，如此类推。
图 11：在统一的元数据表格中存储字段定义（顶部表格）与在独立表格中存储不同的定制字段。
采用独立表格的主要优势在于，每个特定字段表格仅包含使用该字段的用户的行，这节约了数据库的空
间。（如果采用统一表格方案，那么每个至少采用一个定制字段的用户都会在统一表中获得行，尽管用
户实际并未使用空字段，但其却会表现为可用的定制字段。）采用单独表格的方法也有其弱点，因为它
会增加定制字段操作的复杂性，要求必须采用 SQL 的 JOIN 语句来调查单个用户的所有定制字段定
义。
当最终用户在字段中输入数量并保存记录时，应用在数据库中创建或更新记录前，会将寄件人邮政编
码的值转换为字符串。只要应用检索记录，就会检查元数据表中要使用的数据类型，并将定制字段中
的值转换回原类型。
名称值对
前面部分介绍的预分配字段模式是用户扩展并定制应用数据模型的一种简单方式。不过，这种方案存
在一定的局限性。在给定表格中决定提供多少定制字段需要进行综合权衡。如果定制字段太少，用户就
会感到应用有局限性；如果太多，数据库又会变得太大，造成浪费，并且很多字段都得不到利用。在这
极端情况下，两种情况都会发生，有的用户定制字段过多，有的用户则不够用。
15
© Microsoft Corporation 2006 年版权所有。保留所有权力。
避免发生上述局限性的一种方法是使客户自己能够对数据模型进行延伸，在独立的表格中存储定制数
据，并使用元数据来定义每个用户定制字段的标记和数据类型。
图 12. 表格延伸使每个用户都能自行定义一定数量的定制字段。
这时，元数据表格存储关于每个用户定义的各个定制字段的重要信息，其中包括字段名称（标记）和数
据类型。当最终用户采用定制字段保存记录时，会发生两件事。第一，记录本身在主要数据表中被创建
或更新；保存所有预定义字段的相关值，但不会保存定制字段。这时，应用为记录创建唯一的标识符，
在记录 ID 字段中保存它。第二，在延伸表中创建一个包含下列信息的新的行：
• 主要数据表格中与记录关联的 ID；
• 与正确定制字段定义关联的延伸 ID；
• 将正在被保存记录中定制字段的值转换成字符串。
上述方案使每个用户都能根据需要创建尽可能多的定制字段，以满足业务需求。当应用检索客户记录
时，会在延伸表中进行查找，选择与记录 ID 相对应的所有行，并为所用的每个定制字段返回一个值。
为了将这些值与正确的定制字段相关联并将其转换为正确的数据类型，应用会使用延伸表中与每个值关
联的延伸 ID 在元数据中查找定制字段信息。
上述方案使用户能自行决定数据模型的可延伸性，并同时保持了采用共享数据库的成本优势。这种方案
的主要弱点在于，其会增加诸如索引、查询以及更新记录等数据库功能的复杂程度。如果您希望使用共
享数据库，同时估计客户在延伸默认的数据模型时要求相当大的灵活性，那么这种方法通常是最可取
的。
定制列
可延伸数据模型的最简单类型是直接向用户的表格中添加列的情况。
16
© Microsoft Corporation 2006 年版权所有。保留所有权力。
图 13：在不更改其他用户数据模型的情况下向专用表格添加定制行。
这种模式适合独立数据库或独立架构应用，因为每个用户都拥有可独立修改、不影响其他客户端的表
集。从数据模型的角度看，这是三种可延伸模式中最简单的一种，因为这不需要您分别跟踪数据延伸。
不过，从应用的体系结构角度看，这种方法可能更难实施，因为其会允许用户更改表格中列的数量。即
便您能使用定制列模式，您也应当考虑能不能采取预分配字段或名称值对等其他模式，以减小开发难
度，从而使您编写的应用代码能够假定每个表格中的已知字段数量且固定不变。
采用数据模型延伸
不管您使用哪种方法创建可延伸的数据模型，都必须配套采用相关机制，以便将更多的字段集成至应用
功能中。客户实施的定制字段将需要对商业逻辑做出相应的修改（这样应用才能使用定制数据），或修
改演示逻辑（这样用户就能输入定制数据，并获得输出），或者二者同时修改。这样，您向客户提供的
配置界面应使其能够对所有三种模式进行修改，最好使用集成的模式进行修改。（本系列以后将以专文
介绍如何提供相关机制，以帮助客户修改商业逻辑和用户界面。）
可扩展性模式
大型企业软件旨在使数以千计的人同时使用。如果您有过构建这种企业应用的经验，您对创建可扩展体
系结构所面临的挑战肯定就具备了第一手经验。对于 SaaS 应用来说可扩展性尤为重要，因为您必须
支持所有属于客户的数据。对习惯于构建内部部署 (on-premise) 企业软件的独立软件服务商 (ISV)
来说，支持这样大规模的用户群就好像从低级别联赛晋级参加顶级联赛一样：规则虽然差不多，但赛事
本身则是完全不同的级别。这时您所构建的不是一个广泛部署的业务关键型企业应用，而是一个因特网
级的系统，需要积极支持数以百万计的潜在用户群。
数据库应该能够具备纵向可扩展性（移植至集成了更强大处理器、更多存储器以及更快速磁盘驱动器的
更大型服务器）及横向可扩展性（将数据库在多个服务器上进行分组）。在对共享数据库与专用数据库
进行扩展时，应分别采取不同的适用战略。4
扩展技术
在对数据库进行横向扩展时主要涉及两大工具，即复制与分组。复制是指将数据库的部分或全部数据拷
贝到其他位置，然后使副本与原件同步。在单主机复制情况下，只能写入原始主机（即复制主机），这
种情况比多主机复制（可写入部分或全部副本，并用某种同步机制来解决不同数据副本间的差异）要便
于管理得多。
4 在开发扩展战略时，重点在于区分扩展的是应用（增加应用承担的总工作负荷）还是数据（增加数据
存储和工作的容量）。本文侧重于讨论数据扩展。
17
© Microsoft Corporation 2006 年版权所有。保留所有权力。
分组是指从数据库中去除数据的子集，将剪切的数据转移至其他数据库或相同数据库中的其他表。您可
通过对整个表格的重定位来实现分组，也可将一个或多个表格横向或纵向分为更小的表格。横向分组是
指我们用相同的方案和结构将数据库分为两个或更多较小的数据库，但每个表格中的行数减少。纵向分
组是指我们将一个或更多表格分为较小的表格，行数相同，但每个表格包含原始表格的列的子集。我们
在扩展数据库时，通常结合使用复制和分组。
基于用户的横向分组
共享数据库如果不能满足基本的性能需求，如同时访问数据库的用户太多，或者数据库的容量不足导致
查询与更新所需的执行时间过长，抑或是运营与维护任务开始影响数据的可用性等，这时我们就应当对
其进行扩展。
对共享数据库进行横向扩展的最简单方法是根据用户 ID 通过基于行的横向分组来实现。SaaS 共享数
据库非常适合横向分组，因为每个用户都拥有自己的数据集，因此您可轻松地针对不同的用户数据进行
移动。
但是，如果您有 100 个用户，并希望将数据库分为五块，那么不能简单地认为我们可以一次分出 20
个用户将其转移。不同用户对应用的要求可能截然不同，我们必须进行认真的规划，避免简单地分出较
小的区，结果有的小分组仍然使用非常紧张，而有的小分组则资源遭到浪费。
如果因同时访问数据库的最终用户过多而影响了应用性能，那么这时您可考虑对数据库进行分组，对每
台服务器上正处于工作状态的最终用户账户的总数进行平均。举例来说，如果现有的数据库用户 A 和
B 各有 600 个正在工作的用户，而 C、D 和 E 各有 400 个工作用户，那么您在数据库分组时可将
C、D 和E 转移至新的服务器，这样两个数据库分别为 1200 名最终用户提供服务。
如果问题出在数据库的容量上，比方说执行查询等操作所需的时间过长，那么我们应采用更高效的分组
方法来解决数据库的容量问题，重新分配服务器上的用户数量，使每台服务器上的数据量大体相等。
您选择的分组方法可能会对应用开发造成极大影响。无论您选择哪种方法，重要的是您都应准确调查并
核实分组决策的标准。应在构建应用时加入对监控功能的支持，这样您就能准确了解用户的使用情况和
需要。此外，您可能还需要定期进行数据再分组，因为您的用户会不断发生变化，工作方式也会有所差
异。选择分组策略时，要确保不影响生产系统，而且只要有必要分组就能方便地执行。
一家用户有时可能会有非常多的最终用户同时使用数据库或者所使用的数据量非常大，这时有理由将其
转移到自有的专用数据库上。如欲了解执行扩展的更多详情，敬请参见下一章节内容“单个用户的横向
扩展”。
基于用户的横向分组模式适用于共享架构应用，其对数据库的扩展任务提出了一些特殊的限制。采用
这种方法，我们能对共享数据库进行扩展，并同时避免影响应用或性能（如无意中或毫无必要地将一个
用户的数据拆分到两个或更多服务器上）。
单个用户的横向扩展
如果部分或全部用户都存储并使用大量数据，那么用户数据库就会变得相当庞大，这时就有理由使整个
服务器专门为一个用户的数据库提供服务。这种情况下的可扩展性挑战类似于传统的单用户应用所遇到
的问题。如果针对一个庞大的数据库采用专门的服务器，那么纵向扩展就是解决数据量不断增长的最简
单方法。
如果数据库不断增长，那么将它转移到更强大的服务器这种做法最终在成本上也会变得不可取，这时我
们就要将数据库进行分组，横向扩展到一个乃至更多服务器上。专用数据库的横向扩展不同于共享数据
库的横向扩展。对于共享数据库而言，最有效的扩展方法是将用户的整个数据集从一个数据库转移至另
18
© Microsoft Corporation 2006 年版权所有。保留所有权力。
一个数据库，因此您所用的数据模型的性质并不重要。如果扩展的数据库是某个用户专用的，那么我们
就必须分析存储数据的类型，以明确最佳的扩展方案。
“SQL Server 2005 横向扩展”一文 (http://msdn.microsoft.com/library/enus/
dnbda/html/ScalOutSQL.asp) 包含了分析横向扩展数据的更多指导和建议。该文详细介绍了参
考数据、活动数据以及资源数据，对数据复制和分组给出了一些指导性建议，并讲解了影响横向扩展的
一些其他因素。我们应考虑的一些横向扩展指导原则如下：
• 用复制方法来创建不常更改的数据的只读副本。有些类型的数据很少更改，或者根本不发生变化，
如部件号或雇员社会保险编号等。其他类型的数据会在给定时间内经常发生变化，并进行归档，如
采购订单等。这种类型的数据很适合从参考数据库中进行单向复制；
• 位置、位置、位置。要确保数据贴近引用它的其他数据。（这里所说的“贴近”，是指逻辑上的靠
近，而不是物理上的接近，不过逻辑上的靠近常常同时也暗示着物理上的接近。）我们在决定是否
将不同的数据类型分开时，要考虑其彼此之间的关系，在适当时候用复制方法在不同数据库间分配
引用数据的只读副本；
举例来说，如果定期检索客户记录这一工作需要从另一表格中选择客户近期的采购订单，那么我们
就应在相同的数据库中保留上述两个表格，或通过复制来创建适当数据类型的副本。应尽量找到数
据的自然划分，尽可能减小跨数据库之间的通信。例如，我们通常可根据地理位置将与特定地点关
联的数据分在一起；
• 明确不应被分组的数据。仓库库存量等资源数据通常不适合复制或分组。我们可用横向扩展技术将
其他数据从服务器上移走，为资源数据腾出更多的增长空间。如果您已经移走所有能移走的数据，
但还是遇到问题，那么就应考虑纵向扩展，为资源数据采用更大容量的服务器；
• 必要时采用单主机复制。使相同数据的多个副本实现同步非常困难，因此只要可能，我们就应避免
采用多主机复制。如果必须更改已复制的数据，那么只能将更改写入主副本。
以上模式适用于全部三种方案，不过只有当单个服务器不能满足用户的数据需要时才会用到这些方法。
对于独立数据库方案而言，如果用户的数据存储要求不是很高，那么每台服务器可支持数十个数据库；
这时，对于特定服务器的扩展而言，我们只需将一个或多个数据库转移到新的服务器上，并修改应用的
元数据以反映新的数据位置即可。
如欲了解一般的扩展指南，敬请参见 Microsoft Patterns & Practices 开发团队发布的性能和可扩展
性资源，网址为：http://msdn.microsoft.com/practices/Topics/perfscale/default.aspx。
结论
对于成功设计 SaaS 应用而言，本文讨论的设计方案和模式为您提供了至关重要的信任基础。设计一
套既能实现竞争优势又可充分满足数据共享和隔离要求的 SaaS 数据体系结构，并不是一件容易的
事。不过，您可借助这些方案和模式来明确并解决将面临的众多关键性问题。尽管我们在此提出的意见
和建议在细节方面不尽相同，不过它们都有助于您充分利用可配制性、可扩展性以及多用户效率等基本
原则来进行设计，为 SaaS 应用创建安全可靠的可扩展数据体系结构。
本文对单实例、多用户数据体系结构的论述远不够全面。在本系列的后续文章中，我们还将讨论相关方
法，并通过演示和流程定制等来帮助用户更好地利用数据模型扩展。
19
© Microsoft Corporation 2006 年版权所有。保留所有权力。
反馈
本文作者欢迎您就本文内容提供反馈意见。请将您的反馈意见发送至以下电子邮件地址：
fredch@microsoft.com、gianpc@microsoft.com 或 rwolter@microsoft.com。谢谢！