软件即服务的架构指导

系列文章之软件即服务的架构指导
. Microsoft Corporation 2006 年保留所有版权。
抓住长尾市场的架构战略
2006 年 4 月
Frederick Chong 与 Gianpaolo Carraro
微软公司
Copyright . Microsoft Corporation 2006. All Rights Reserved.
2
致谢
非常感谢 Paul Henry 在撰写技术内容方面给予的帮助。
说明
本文档所包含的信息代表了在发布之日，Microsoft Corporation 对所讨论问题的当前看法。因
为微软必须顺应不断变化的市场情况，因而该文档不应理解为 Microsoft 单方面的承诺，
Microsoft 不保证所给信息在发布这日以后的准确性。
本文档仅供参考。对于本文档中的信息，Microsoft 不做任何明示、默示或法定的担保。
遵守所有适用的版权法律是用户的责任。在不对版权法所规定的权利加以限制的情况下，如未
得到 Microsoft Corporation 明确的书面许可，不得为任何目的、以任何形式或手段（电子的、
机械的、影印、录制等等）复制或传播本文的任何部分，也不得将其存储或引入到检索系统
中。
Microsoft 可能拥有本档主题涉及到的专利、专利申请、商标、版权或其他知识产权。除非在
Microsoft 的任何书面许可协议中明确表述，否则获得本文档不代表您将同时获得这些专利、商
标、版权或其他知识产权的任何许可证。
除非另外注明，否则此处作为例子提到的公司、组织、产品、域名、电子邮件地址、徽标、人
员、地点以及事件纯属虚构，决不意指，也不应由此臆测任何真实的公司、组织、产品、域
名、电子邮件地址、徽标、人员、地点和事件。
. 2005 Microsoft Corporation，保留所有权利。
Microsoft、Visual Studio 以及 .NET 徽标是 Microsoft Corporation 在美国和／或其他国家的注
册商标或商标。
所有其他商标均是其各自所有者的财产。
Copyright . Microsoft Corporation 2006. All Rights Reserved. 3
引言
软件即服务这一话题已是众口相传。软件业有关文献中关于“软件即服务” (SaaS) 的文章不胜枚
举，其中很多都用到了“革命性”和“产业格局”等措辞词。大家都知道（或以为自己知道）什么是软
件即服务，都认为这一理念意义重大。不过，很少有人能真正定义这一理念，了解如何实践这一理念的
人就更是寥寥无几了。
因此，既然 SaaS 对应用实施的未来发展如此重要，为什么人们在实践这一理念时很难获得有用的指
导呢？
我们认为，SaaS 确实将对软件产业发挥重大影响，因为软件即服务将改变人们构建、销售、购买以及
使用软件的方式。不过，为了将此变为现实，软件开发商需要高效开发 SaaS 应用的资源和信息。
本文是微软 (Microsoft) 介绍 SaaS 理念系列文章中的第一篇，后续系列文章将为读者解开 SaaS 的
神秘面纱，并为设计 SaaS 应用提供实际的、现实的指导。本文将概括介绍 SaaS 理念、其面临的挑
战，及其如何为有兴趣提供 SaaS 应用的公司带来好处。本系列随后的几篇文章将详细讨论有关问
题。
本文首先提出什么是软件即服务，并介绍 SaaS 供应商必须经历的概念转型，以了解新理念与传统的
内部部署软件的不同之处。随后，我们将讨论 SaaS 商务模型，了解软件即服务如何能在现实商务中
盈利。
本文将重点讨论架构问题，因此最大篇幅将集中在 SaaS 应用的架构上。我们给出四级成熟模型，介
绍 SaaS 的部分主要特性：可配置性、多用户效率以及可扩展性。我们将研究高级 SaaS 架构的组
件，并侧重探讨 SaaS 架构师通常面临的难题，即，如何为扩展多用户应用的数据模型提供适当机
制。
最后，我们将简要讨论 SaaS 应用投入部署后与开展支持工作相关的运营问题。
什么是软件即服务？
时至今日，如何准确定义“软件即服务”(SaaS) 仍然没有定论，问五个人可能就会有五种不同的答
案。不过，大多数专家可能会在 SaaS 区别于传统套装软件和简单 Web 站点的一些基本特点上达成
一致。简言之，软件即服务具备以下特点：
“软件部署为托管服务，通过因特网存取。”
我们不妨花些时间来思考一下这一定义的含意。这种定义既未限定具体的应用架构，也未指定特定的技
术或协议；没有在企业与个人消费者之间的服务进行区分，也没有要求具体的商业模型。根据上述定
义，软件即服务的主要特点在于应用代码所处的位置以及部署和存取应用代码的方式。1
根据这一定义，SaaS 将包括许多您意想不到的服务和应用。例如，我们不妨考虑一下基于 Web 的电
子邮件服务，如 Microsoft. Hotmail. 等。尽管您在考虑 SaaS 时很难率先想到 Hotmail 也属于
SaaS 的范畴，但 Hotmail 确实满足了所有 SaaS 的基本标准：供应商提供所有程序逻辑和数据的主
机服务，使最终用户能够通过基于 Web 的用户界面在公共因特网上存取数据。
从一般到具体，我们认为软件即服务有两大类别：
1 这种定义是不是过于简化了？简而言之，确实有一些简单化。随后我们将集中讨论一些能够定义和区
别拥有良好设计的成熟 SaaS 应用的重要属性。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
4
. 面向企业的服务 (Line-of-business service)，向各种规模的企业和组织提供的服务。面向企
业的服务通常是可定制的大型商务解决方案，旨在协助开展财务、供应链管理以及客户关系等商务
工作。这种服务通常采用用户预订的销售方式。
. 面向个人消费者的服务 (Consumer-oriented service)，向公众提供的一类服务。面向个人
消费者的服务有时以用户购买的方式销售，不过通常免费提供给用户，从广告中赚取收入。
本文将侧重讨论与开发面向企业的服务应用相关的架构及商业问题，文中给出的概念与范例都与企业应
用相关。不过，多用户定制和可扩展性、数据扩展以及隔离等问题也会出现在个人消费者领域（事实上
更便于解决），因而个人消费型 SaaS 服务的开发商阅读本文也将有所裨益。
将软件作为服务来考虑
为了实现从提供内部部署软件向软件即服务的转变，软件厂商应在三个相互关联的领域中转变思路：一
是商业模型；二是应用架构；三是运营结构。
Software
Services
Business
Model
Operational
Structure
Application
Architecture
在以下三部分中，我们将以 SaaS 的应用架构为侧重点更深入地讨论上述转变。
转变商业模式
转变商业模式将涉及以下一种乃至更多种情况：
. 将软件的“所有权”从客户转移至外部供应商；
. 将技术基础设施和管理等方面（如硬件与专业服务）的责任从客户重新分配给供应商；
. 通过专业化和规模经济降低提供软件服务的成本；
. 降低软件销售的最低成本，针对小型企业的长尾市场做工作。
为了实现 SaaS 理念的优势，供应商与客户都应进行思维转型，并且供应商还应帮助客户实现这种转
变。
Copyright . Microsoft Corporation 2006. All Rights Reserved. 5
谁“拥有”软件？
大多数软件的销售方式几十年以来一直一成不变。客户为使用软件而购买许可证，并在属于客户或归客
户控制的硬件上安装软件，而供应商则根据许可证协议或技术支持协议提供支持。在诚实公开的软件交
易中，“许可证”的技术性含义如下：从法律上说，客户购买的只是使用软件拷贝的权利，但从实际目
的而言，客户似乎是“拥有”软件的，并能根据需要随时使用软件，使用多长时间都可以。
软件作为产品的商业模式是软件市场的整体情况，在此环境下，软件即服务理念会让人感到相当陌生：
我们告诉客户，他们不是直接“拥有”重要的软件，而是要为运行在别人服务器上的软件支付使用费，
如果停止用户付费，就不能再获得软件使用权。因此，潜在的客户应了解 SaaS 为什么能比传统的模
式提供更直接、更可量化的经济收益，这一点特别重要。
转移 IT 工作责任
在一般的公司中，信息技术 (IT) 预算用于以下三大领域：
. 软件 —— 企业用于计算与信息处理的实际程序和数据；
. 硬件 —— 可为用户提供软件存取的台式计算机、服务器、网络组件以及移动设备 等；
. 专业服务 —— 确保系统能够不间断运行和可用的人员和机构，包括技术支持人员、咨询人员以及
厂商代表等。
在上述三大领域中，软件是最直接参与信息管理的部分，这也是所有 IT 公司要实现的最终目标。硬件
与专业服务尽管是 IT 环境的重要组成部分，但我们通常将其视为实现目的的手段，而不是目的本身，
因为这两者能确保软件实现高效信息管理的最终目标。（换言之，只要能有效地增加软件功能，又不必
添置额外的硬件，那么任何公司都愿意这么做。但是，如果没有增加软件功能的需要，任何公司都不会
无缘无故地添置硬件。）
在围绕内部部署软件构建起来的 IT 环境中，大部分预算通常花费在硬件和专业服务上，使得可用的软
件预算只占少数。
Hardware Professional
Services
Software
在这种模式下，软件预算主要用于购买商业软件套件的许可证以及定制的业务软件。硬件预算主要用于
最终用户使用的台式机和便携式计算机、存储数据和应用的服务器，以及可实现网络化连接的组件。专
Copyright . Microsoft Corporation 2006. All Rights Reserved.
6
业服务预算用于支付技术支持人员的薪水，他们负责部署并为软硬件提供支持，此外还要为咨询人员和
开发资源付费，这是设计并构建定制系统所需的。2
在主要采用 SaaS 模式的公司中，IT 预算的分配大为不同。
Hardware Services
Software
在这种模式下，SaaS 厂商在其公司内部的中央服务器上存储重要的应用和相关数据，并拥有专业的支
持人员来维护软硬件。这就使公司客户不用再为主机上运行的软件提供支持，也不必再为此而购买和维
护服务器硬件。此外，通过 Web 或智能客户端提供的应用对台式计算机的性能要求要显著低于本地安
装应用，这就使客户能大幅延长台式计算机的使用寿命。最终，绝大部分 IT 预算能用于软件，通常以
向 SaaS 供应商交纳的使用费的形式支付。
充分利用规模经济
上述情况是否仅是一种难以实现的空想呢？说到底，为了获得“软件”而支付给 SaaS 供应商的使用
费中的一部分，必定要用于 SaaS 供应商的硬件和专业服务成本。这时，就要考虑规模经济效应的问
题。假定 SaaS 供应商中央主机上运行的单套软件拥有 x 家客户，那么该供应商就能统一为所有客户
提供服务。例如，企业 SaaS 应用安装在五个服务器组成的负载平衡群集上，可支持 50 家中等规模
的客户，也就是说，每家客户只需负担一台服务器成本的十分之一。如果相同的应用由各家客户进行本
地安装，就要求每家客户专门为该应用提供服务器，有时如果负载平衡和可用性要求高的话，还需要甚
至不止一台服务器。因此，SaaS 模式比传统模式更节约成本，对于可扩展性较强的 SaaS 应用而
言，随着客户的增多，每家客户的运营成本会不断降低。同时，随着客户的增多，供应商将加强多用户
这一重要特性，以更低的成本提供更高质量的服务。因此，即便考虑到 SaaS 供应商的硬件和专业服
务成本，客户仍能用相同的 IT 预算实现高得多的纯软件功能。
2 各图中所示的比例分配仅用于说明性目的，并不代表资源分配的确切比例，贵公司的实际资源分配可
能与图示截然不同。
Copyright . Microsoft Corporation 2006. All Rights Reserved. 7
Hardware Services
Software
SaaS Vendor
Hardware
SaaS Vendor
Services
长尾部分的销售问题
作者 Chris Anderson 在他于《连线》杂志 2004 年 10 月刊3上撰写的“长尾”一文中，介绍了
Amazon.com 等网络零售商为什么处于有利地位，为什么能针对传统零售商难以以低成本提供服务的
领域填补需求空白，从而使“长尾”这一新概念通俗易懂。
The Long Tail
Demand
Popularity Rank
书籍、光盘等各种商品门类的需求往往符合“幂次定律分布”。在这种情况下，每年发布的书籍、CD
以及 DVD 数不胜数，但只有少数能长期成为畅销品，其他的往往属于反响平平的长尾类出版物：大量
出版物只让少部分有专门爱好的人感兴趣，出版量很小，甚至连几千份的拷贝都没有。
传统的实体型零售商致力于销售最流行的出版物，因为他们不可能把数以百万计的书籍、CD 以及
DVD 等出版物都拿来当存货。不过，网络零售商则不用担心存货问题，他们能直接从全球各大仓库直
接向客户发货，即便销售的出版物受欢迎程度很低，其广告和销售成本也毫不受影响，同样像畅销出版
物一样大作宣传。因而长尾类低销量出版物也能赢得大量收入。
3http://www.wired.com/wired/archive/12.10/tail.htm
Copyright . Microsoft Corporation 2006. All Rights Reserved.
8
大型的实体书店能在其书架上存放 13 万种不同的出版物。而 Anderson 指出，Amazon.com 书籍
销量的大部分都来自 13 万种流行出版物之外，换言之，Amazon.com 卖出的书中，大部分都是在传
统的实体书店中买不到的。
复杂的企业软件解决方案供应商面临着相似的市场境况。
与简单的套装软件不同，企业软件需要针对不同客户的需求进行定制，可能包括现场安装、厂商服务队
伍上门服务等，通常还需要专门的服务器硬件和支持人员加以管理。提供上述专门服务的成本会一定程
度上增加供应商销售软件的最低成本。因此，这种软件通常面向大型企业，只有大型企业才有实力来支
付专门服务。不过，相对于购买企业解决方案的大型企业数量而言，有着同样需求的中小型企业的数量
要多得多，但他们却难以承担高昂的成本。
Copyright . Microsoft Corporation 2006. All Rights Reserved. 9
SaaS 供应商可消除维护成本，利用规模经济效益将客户的硬件和服务需求加以整合，这样就能提供比
传统厂商价格低得多的解决方案，这不仅减轻了财务成本，而且大幅减少了客户增加 IT 基础设施建设
的需要。因此，SaaS 供应商能面向全新的客户群开展市场工作，而这部分客户是传统解决方案供应商
所无力顾及的，因为他们根本就没办法为这部分客户提供低价格的服务。
有效面向小型客户开展市场工作，这就要求习惯于通过人际交往以及传统厂家和客户关系搞营销的供应
商们进行思维转型；大多数供应商难以用大规模市场上的较低价格向更大的客户群体提供个性化服务。
搞 SaaS 营销就像销售手机彩铃或音乐下载服务一样，应该让客户能访问您的 Web 站点，成为您所
提供服务的付费用户，通过信用卡付费就能开始享受服务，整个过程无须供应商方面的人为介入。这不
是说您就不用对需求范围广的大规模客户群做人际联系工作。不过，在销售工作的设计、营销、供应和
定制过程中从头到尾都是自动化的，因此我们不仅能提供自动化服务，同时又能简化您支持部门员工的
工作，因而不用再帮助客户完成相关任务。
应用架构
我们对软件即服务理念还没有最终定义，目前暂定的概念如下，即，软件部署为托管服务，通过因特网
存取。根据对软件和存取这两个词定义的方式不同，上述定义可能包含很多含义，或许含义会多得不胜
枚举。对应用架构师师而言，上述定义基本上不会对如何设计出可行的 SaaS 应用发挥什么实际作
用，不能区别如何让 SaaS 应用成功，避免失败。比方说，基本代码有十年历史的企业应用，根据目
前需要现加上 HTML 前端，这种软件也能算作广义的软件即服务，不过这种应用大多数都难以实现有
效扩展，也不够廉价，因此都会遇到问题。因此，为了定义什么才是成熟的 SaaS 应用，我们必须提
出一些额外的标准。
单实例多用户架构的三大特点
从应用架构师的角度来看，设计出色的 SaaS 应用与设计欠佳的应用之间主要有三点不同之处。设计
出色的 SaaS 应用具有可扩展性、多用户高效性，而且可配置。
应用的可扩展性是指能最大限度地提高并行性，以便更高效地利用应用资源，例如，我们要优化锁定时
间、无态性、共享线程和网络连接等汇集资源、高速缓冲参考数据以及对大型数据库进行分区等。
对习惯于设计独立的单用户应用的架构师而言，多用户性要求他们进行重要的思维转型。例如，一家公
司的用户使用 CRM 应用服务存取客户信息时，该用户连接的应用实例同时可能还会为其他几十家，甚
或是数百家公司的用户提供服务，各用户之间彼此互不知情。这就要求应用架构能够最大化不同用户间
的资源共享，不过仍要区分属于不同客户的数据。
当然，如果我们必须用一台服务器上的单个应用实例满足多家不同公司的需求，那么我们就难以针对某
个最终用户的使用体验编写定制代码，因为只要针对某个客户进行了应用定制，就会改变其他用户的使
用。因此，我们不是在传统的意义上进行应用定制，而是让每个客户用元数据配置应用的外观和行为。
SaaS 架构师面临的挑战在于，如何确保客户应用配置的简易性，同时还不必为每项配置支付额外的开
发或运营成本。
软件即服务的成熟模型
我们通过确定成熟 SaaS 应用的三大重要特性进一步改进了 SaaS 的定义。不过，成熟的 SaaS 模式
不一定同时具备这三个特性，有的应用只具备其中的一种或两种，但仍能满足所有必需的商业要求。这
时，如果实现其他的特点难以保持低成本性的话，那么应用架构师就不必实现其余的特性了。
从广义上说，我们可采用四级模型来说明 SaaS 应用的成熟度，每一级都比前一级增加了上述三种成
熟特性中的一种。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
10
第一级：特定的/定制的
成熟度的第一级类似于 20 世纪 90 年代传统的应用服务供应商 (ASP) 提供软件的模式。在这种情况
下，不同的客户拥有各自主机应用的定制版本，在主机服务器上运行自己的应用实例。从架构上说，这
种成熟级别的软件与传统销售的企业系列软件很相似，即公司中的不同客户连接到服务器上运行的相同
实例，但该实例完全独立于主机上其他客户运行的其他实例或进程。
一般说来，传统的客户端—服务器应用无需太多开发工作，也不必从头重新设计整个系统，就能转变为
第一级成熟度的 SaaS 模型。尽管这一级别的成熟性难以提供全面成熟型 SaaS 解决方案的很多优
势，但仍能帮助供应商整合服务器硬件和管理，从而降低成本。
第二级：可配置性
对于第二级成熟度而言，供应商为不同的客户（或用户）分别提供应用实例主机服务。就第一级成熟度
而言，每个实例都是对用户分别定制的，而在第二级成熟度上，所有实例都使用相同的代码实施，供应
商提供详细的配置选择，让客户能改变应用的外观和行为，从而满足客户的需求。尽管不同实例在代码
层面上彼此相同，但彼此之间仍完全隔离。
供应商所有客户都使用相同的代码库，这大幅降低了 SaaS 应用的服务要求，因为代码库的任何更改
都能立刻方便地作用于供应商的所有客户，从而无需逐一更新或优化每个定制实例了。但是，在应用最
初针对独立定制而不是配置元数据进行设计的情况下，将传统的应用转变为第二级成熟度的 SaaS 应
用时，比起第一级成熟度的转型而言，将需要多得多的架构重新设计工作。
与第一级成熟度类似，第二级成熟度也要求供应商提供足够的硬件和存储资源，以支持大量应用实例同
时运行。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
11
第三级：可配置性与多用户效率
对于第三级成熟度，供应商借助单个实例来满足不同客户的需求，并采用可配置的元数据为不同的用户
提供独特的用户使用体验和特性集。授权与安全性策略可确保不同客户的数据彼此区分开来。从最终用
户的角度来看，不会察觉到应用是与多个用户共享的。
这使我们就不再需要为不同客户的不同实例提供大量服务器空间，因此使用计算资源的效率将大大超过
第二级成熟度，从而直接降低了成本。但是，这时的一大弱点在于，应用的可扩展性有限。如果不用分
区来管理数据库性能的话，我们只能通过采用更强大处理器来扩展应用（向上扩展），但是这样做只能
使投入回报逐渐降低，最终导致功能的提高难以适应低成本的要求。
第四级：可扩展性、可配置性与多用户效率
第四级成熟度也是最高级成熟度，这时供应商在负载平衡的服务器群上为不同客户提供主机服务，运行
相同的实例，不同客户的数据彼此分开，可配置的元数据可以提供独特的用户体验与特性集。SaaS 系
统具备可扩展性，可轻松适应大规模客户的需要，可在无需对应用进行额外架构设计的情况下根据需求
灵活地增减后端服务器的数量，不管有多少用户，都能像针对单个用户一样方便地实施应用修改。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
12
高级架构
从架构上看，SaaS 应用与采用服务导向型设计原理开发的其他应用很相似。
选择成熟度级别
您的应用应采取哪种成熟度级别？我们可能认为，所有 SaaS 应用的最终目标都是实现第四级的成
熟度，但事实并非如此。我们可将 SaaS 成熟度视为隔离数据和共享数据两个极端之间的一点。
Per-tenant SLA
Data separation Isolate Share Economy of scale
Simpler management
具体应用应在两端之间的哪一点上，这取决于您的业务、架构及运营需求，也取决于客户的考虑。
我们这里只做简单的说明，不过您仍能看出，所有这些因素在一定程度上都是相互关联的。
. 业务模型。隔离方法是否有利于赢利？如果抛弃了共享方案的经济性和管理优势，这将意味着
您向消费者提供应用的成本将会更高。但在某些情况下，为了满足其他需要，这种做法会是值
得的。此外，即便您向用户解释不存在机密数据遭窃的风险，但有的客户从法律或文化的角度
出发，也会强烈抵制不同用户共用应用的架构模型。当然，说到底，您的商业模型应确保您不
管采取何种成熟度的模型，都能实现盈利。
. 架构模型。您的应用能否运行统一的逻辑实例？如果您希望将基于台式机或传统客户端—服务
器应用转移至基于因特网的交付系统，那么原来的应用可能根本不能与统一实例、以元数据为
中心的模式相兼容，您需要明确为了将原系统转型为完全成熟的 SaaS 应用进行大量投资，到
底从财务上合不合算。如果您从头设计和构建网络原生应用，那么您在采用单个实例模式时才
会拥有更高的自由度。
. 运营模型。您能否确保始终满足服务水平协议 (SLA) 的要求？您应仔细考虑您与客户之间现有
SLA 条款下您应承担的责任，其中包括停机时间、支持选项、灾难恢复等，并确定上述责任在
互不相关的客户共用一个应用实例的应用架构下能否得到保证。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
13
上图描绘的大部分组件对大多数应用架构师而言都是相当熟悉的。进程服务给出了智能客户端和/或网
络供应层可调用的界面，并能启动同步工作流程或长时间运行的事务处理，以调用其他商业服务，与各
处的数据存储进行互动以读写商业数据。安全性服务负责控制最终用户和后台软件服务的存取。
最重要的区别在于增加了元数据服务，其负责管理不同用户的应用配置。服务和智能客户端与元数据服
务发生互动，以检索描述各用户配置和扩展的相关信息。
元数据服务
就成熟的 SaaS 应用而言，元数据服务供应商为客户提供了定制和配置应用、满足其特定需求的主要
手段。通常，客户可在四大领域进行配置更改：
. 用户界面与品牌。客户通常希望具有用户界面的调整功能，以反映各自公司的品牌风格，因此
SaaS 应用通常都提供相关特性，以使客户能够更改诸如图形、色彩、字体等相关内容。
. 工作流程与商务规则。为了能广泛地向各种潜在客户提供服务，任务关键型 SaaS 应用必须能够
满足不同工作流程的需要。例如，对于跟踪发票流转的应用而言，一家客户可能要求所有发票均由
同一名经理批准；另一家客户则要求每张发票都由两名经理先后批准，第三家客户则要求每张发票
得到两名经理批准，而不考虑先后。这时，不同客户应能根据需要自行配置应用的工作流程，以满
足各自的商业进程要求。
. 数据模型的扩展。对于许多数据驱动型 SaaS 应用而言，单个模型显然不能满足所有需要。即便
对于相对简单的任务专用应用而言，如果数据字段和表格一成不变，也会给客户造成麻烦。可扩展
的数据模型使客户能自由地让应用根据自身需要工作，而不必为了满足应用的要求而改变商业进
程。在本文随后部分，您将进一步了解可扩展客户数据模型的架构。
. 存取控制。通常，客户负责创建每个最终用户各自的账户，并确定每个用户能够存取使用的资源和
功能。我们用安全策略跟踪每个用户的使用权限，客户应能对安全策略加以配置。
为了帮助客户灵活地根据需要进行软件配置，我们将上述选项组织成层级的配置单元，即“配置域”，
每个配置域都包括不同的选项，以更针对上述四个领域做出相应更改。每家客户都拥有顶级配置域，使
他们能够在需要时进行配置，并能在顶级配置域下构建任意层级的一个或多个配置域。我们还采用关系
Copyright . Microsoft Corporation 2006. All Rights Reserved.
14
策略来决定子节点 (child node) 能否继承母节点 (parent node) 的配置设置，或忽略母节点的设
置。
举例而言，如果普通客户购买了整个企业的应用使用权，其不同的业务部门有着不同的需要，那么这些
部门都应遵循统一的公司标准，同时还应各自配置自身使用的应用元素。在各业务部门内部，同样也会
存在下级单位，它们都有自己特殊的配置需要。对于上述各组织单元而言，客户可分别建立配置域，登
录不同的单元选择各自的配置选项，设置或更改均可。
与供应商定制的传统业务应用不同，SaaS 应用更多情况下是由客户自身进行配置的。因此，设计配置
界面非常重要。理想情况下，客户应能够通过向导或简易而直观的屏幕指导进行应用配置，屏幕上应提
供所有可用的选项，既避免客户面临一大堆信息无从下手，又能清晰地反映给定配置域下能否针对相关
选项进行更改。
安全性服务
在任何软件环境下，安全性都是至关重要的。SaaS 的性质决定了安全性既是客户的最大关注点，又是
应用架构师需优先考虑的重点。以下给出的一些基本指南，有助于确保用户控制其专用数据。
认证
SaaS 供应商通常将创建和维护用户账户的责任下放给客户，这称作下放管理权。管理权下放造成的
情况是，客户负责创建不同的用户账户，而 SaaS 供应商应认证有关账户。根据管理权下放模式的要
求，SaaS 架构师采用两种通用办法来解决认证问题：一是集中认证系统 (centralized
authentication system)，一是非集中认证系统 (decentralized authentication system)。所选
的认证系统不同，将导致架构的复杂性不同，也会导致最终用户应用体验的不同，因此您在制定决策
时，应根据商业模型的需要来确定应用、客户和最终用户的需要。
对于集中认证系统而言，供应商管理中央用户账户数据库，该数据库为所有应用的用户提供服务。客户
的管理员被授权在用户账户目录下创建、管理和删除用户账户。登录应用的用户向应用提供认证信息，
有关信息根据中央目录下的信息加以确认，如果数据有效，就允许该用户访问。
这种方法所要求的认证基础设施相对简单，便于设计和实施，也不需要改变客户自身的用户基础设施。
不过这种方法的重要缺点之一在于，集中认证系统很难实现单点登录 (single sign-on)，即用户一次
登录，就始终能访问企业网络。没有单点登录功能，用户总会被提示输入应用登录信息，每次都要手动
再次输入。
在非集中认证系统中，客户采用可与其自己的用户目录服务相连接的联合服务 (federation
service)。当最终用户尝试访问应用时，联合服务将对用户进行本地认证，并发布安全令牌， SaaS
供应商的认证系统将接受安全令牌，并允许用户接入应用。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
15
在单点登录相当重要的情况下，这是一种理想的方式，因为认证在后台进行，不要求用户记住并输入一
系列相关信息。不过，非集中认证方案比集中认证方案要复杂得多，而且，如果 SaaS 应用有着几千
家客户的话，就要与众多客户的联合服务分别建立联邦式的信任关系。
在许多情况下，SaaS 供应商都希望采用混合方式，对小型客户采用集中认证系统来认证和管理，而对
要求单点登录并愿为此付费的大型企业提供联合服务。
授权
通常，存取 SaaS 应用中的资源和商务功能都用“角色”的概念来管理。角色与公司中的特定岗位功
能映射。每个角色都被赋予一项或更多“许可”，分配到某个角色的用户就能根据相应的“业务规则”
执行行动。
Purchaser
Approver if(totalCost < 1500)
if((role == ‘Purchaser‘) ||
(role==‘Approver‘ &&
duringOfficeHours==false))
Users &
Groups Roles Permissions Business Rules Action
SaaS 应用内部负责对角色进行管理，角色可包含单个用户的账户以及用户群组。不同用户账户和用
户群组根据需要被分配到不同的角色。
根据用户所分配到的角色，该用户可获得一项或者多项许可，以执行特定的操作或活动。这些活动通常
直接与重要的商务功能或应用管理本身映射。例如，购买应用可能包括创建、提交、批准以及拒绝购买
订单的相关许可；抵押经纪公司的应用会包括检查借款人信用和批准贷款的许可，等等。可根据需要向
一个或多个角色分配一个许可；每个用户可根据所属的角色获得相关角色的所有许可。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
16
应用可根据商务规则对活动和资源的使用实现比许可更精确的控制。商务规则规定了在允许使用前必须
满足的条件。例如，您可使用相关商务规则，只允许用户在正常办公时间内在不同账户间转账，或者规
定转账金额不得超过一定数量。
存取控制由配置域管理。每个配置域根据应用的关系策略继承上级配置域的角色、许可和商务规则，并
可在适当的时候对其进行修改、添加和删除。例如，假设有家客户总部设在美国，并在加拿大多伦多设
有分支机构。根配置域设有最基本的“福利管理员”角色，可针对雇员福利管理提供一系列许可，其中
包括管理公司的 401(k) 退休储蓄计划等。由于 401(k) 计划是美国税收法律的产物，不适用于加拿
大，因此我们可为加拿大办事处构建子配置域，在继承“福利管理员”角色和相关许可的同时，对角色
的许可给出特殊处理，以修改401(k) 计划相关内容。在修改原许可的同时，客户增加了新的许可，
允许该角色修改注册退休储蓄计划 (RRSP) 项目，即加拿大相当于美国 401(k) 的立法。
Root Scope Canada (child scope)
Benefits
Administrator
Benefits
Administrator
从最佳实践角度看，应用应向所有用户提供一系列默认的角色、许可和商务规则，并应允许不同用户通
过直观易用的界面定制这些规则和创建更多规则。
深入探讨：多用户数据模型
到此为止，我们已在相当高级的层面上讨论了应用架构，下面我们不妨来详细讨论一个具体问题，即如
何设计一款客户能在多用户环境下实现扩展的数据模型。我们并不是要全面讨论数据模型扩展，不过这
有助于您在一定程度上了解 SaaS 应用设计相关的各种架构问题。
根据设计，您的应用自然将包括标准的数据库设置，根据解决方案的性质提供默认的表格、字段、查询
和关系等。不过，不同公司有着各自独特的需求，僵化的、不能扩展的数据模型难以满足这种需求。例
如， SaaS 工作跟踪系统的一位客户需要存储外部生成的分类代码串，每项记录都应将系统与其他进
程完全集成。而另一家客户则不需要分类串字段，而要求支持类 ID 号（整数）跟踪。因此，除非在少
数专业领域，您开发和实施的方法通常应让客户能扩展默认的数据模型，以满足其各自的需求，同时又
不会影响其他客户使用的数据模型。我们将讨论可解决上述问题的三种一般性方法：一是专用的用户数
据库；二是共享数据库配合固定扩展集，；三是共享数据库配合定制扩展。
专用用户数据库
第一种方法就是为各客户提供专用的数据库，客户可根据需要扩展数据库。
就这种方法而言，如果有新客户就创建新的标准默认数据库，作为进程部署的一部分，同时元数据服务
跟踪数据库分配给客户的情况。一旦创建了新的数据库，客户可在应用的用户界面和程序逻辑允许的情
况下随意修改，包括创建新字段、新查询，乃至新的表格和关系等。
如果提供服务的成本不是问题的话，那么我们考虑这种方法就行了，因为这是最简单的方法，而且为客
户扩展默认数据模型提供了最大的自由度。此外，银行和医疗记录管理等领域的客户需要极高的数据隔
离，如果不能为不同的客户提供独立的数据库，甚至根本不会考虑有关应用。这种方法的劣势在于，每
Copyright . Microsoft Corporation 2006. All Rights Reserved.
17
部服务器只能支持数量有限的数据库，因此基础设施成本会不断升高，而且比其他方法的成本增速都要
快。
共享数据库，固定扩展集
第二种方法是所有客户共享一个数据库，数据库预设一些定制字段，允许用户根据需要分配使用。
438
345
784
777
345
TenantID
Pat
Ned
Mary
Kay
Ted
FirstName
1952-11-04
1940-03-08
1962-12-21
1956-09-25
1970-07-02
BirthDate
null
null
null
23
null
Custom1 Custom2 Custom3
San Francisco
Paid
null
null
Paid
Yes
null
null
null
null
上图中，不同客户的记录在同一个表格中共存；客户 ID 字段将不同记录与相应的客户相关联。除了标
准字段集外，还提供了一系列定制字段，各客户可选择字段的用途，以及如何收集数据。
定制字段可根据类型区分，因此客户可通过应用和数据库提供的任何内置的类型检查和确认功能来确认
数据。此外，字段也可不分为类型，以便客户用其存储任何类型的数据。（客户也可选择提供自己的确
认逻辑，避免用户无意输入无效数据。）
共享数据库在提供服务方面的成本大大低于隔离的数据库，因为单个数据库引擎在需要分区前可支持大
量客户。这种方法的最大弱点在于，数据模型的可扩展性受限于定制字段的数量。为了明智地决定定制
字段的数量，应认真分析客户潜在的需要。如果定制字段太少，客户就不能有效使用应用；如果定制字
段太多，就会造成数据库浪费，很多字段都得不到利用。
共享数据库，定制扩展
第三种方法是构建统一的共享数据库，并允许客户自行扩展数据模型，在不同的表格中将定制数据存储
为名称值对 (name-value pair)。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
18
438
345
784
777
345
TenantID
Pat
Ned
Mary
Kay
Ted
FirstName
1952-11-04
1940-03-08
1962-12-21
1956-09-25
1970-07-02
BirthDate RecordID
Affiliation
Subscriber
Expire
Status
Subscriber
Name
Acme
No
2008-07-29
Gold
Yes
Value
∞
1
301
117
564
564
893
RecordID
301
117
564
null
893
这时，包含定制数据的每个客户记录都被分配到了一个唯一的记录 ID，在独立的扩展表格中与一行或
多行相匹配。对于表格中的各行而言，都存储了一个名称值对。每个客户都能根据商务需要创建任意数
量的名称值对。当应用检索客户记录时，会在定制数据表格中进行搜索，选择所有对应于记录 ID 的
行，返回后作为普通字段数据处理。显然，定制数据表格中的数据不能分类，因为其中包含的数据对不
同客户而言可能采用多种不同格式。为了解决这一问题，我们可选择再增加一列，保存数据类型标识
符，这样在检索数据时就能将数据与相应的数据类型对应。
这种方法使我们能够随意扩展数据模型，同时还能保持采用共享数据库的成本优势。其主要弱点在于增
加了数据库功能的复杂性，如检索、索引、查询和更新记录都变得更为复杂。如果您估计客户在扩展默
认数据模型时需要高度灵活性而又不需要数据隔离，那么这种方法就是最佳选择。
在开发可扩展性数据模型时，应记住，客户实施的任何扩展都会要求商业逻辑的相应扩展，这样应用才
能使用定制数据，同时也要求配置逻辑的扩展，这样用户才能输入定制数据并获得输出。因此，您向客
户提供的配置界面应针对上述三种方法提供相应的更新机制，并最好以整合的方式提供。（在后续发布
的文章中，我们将讨论如何采取相应机制，帮助客户扩展商务逻辑和用户界面。）
可扩展性
大型企业软件旨在让数千人同时使用。如果您有过开发此类企业应用的经验，您肯定已亲自遇到过创建
可扩展架构的重大挑战。对于 SaaS 应用而言，可扩展性更为重要：您所支持的用户数量，是单个客
户的平均用户群乘以客户总数。对那些习惯于设计内部企业软件的 ISV 来说，支持这样大规模的用户
群就如同从低级别联赛进级参加顶级联赛一样：规则是熟悉的，但赛事本身则是完全不同的级别。这时
您所构建的不是一个广泛部署的业务关键型企业应用，而是一个因特网级的系统，需要积极支持数以百
万计的潜在用户群。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
19
应用扩展
当然，您的解决方案很难成为像 Hotmail 那样拥有庞大的用户群（如果确实拥有这么多用户，真该恭
喜您！）。不过，可扩展性方面的挑战却是相同的。
应用可向上扩展（将应用转移至更强大的较大型服务器上），也可横向扩展（在更多的服务器上运行应
用）。对所有曾用全新计算机取代过旧计算机的人来说，向上扩展并不陌生，该解决方案通常更适用于
那些无需为众多并发用户提供服务的小型应用。不过，就 SaaS 而言，横向扩展通常是扩充容量的最
佳办法，这一点我们在 SaaS 成熟度模型中已经探讨过了。设计出色的 SaaS 应用可横向扩展到众多
服务器上，每台服务器都运行应用的一个或更多实例。设计“横向扩展型”应用的一些设计指南如下：
. 设计应用运行在无状态模式下，所有必需的用户和会话数据都存储在客户端或分布式存储设备上，
任何应用实例都能访问。无状态是指每个事务处理都能由任何实例来完成，用户在一次会话中可用
众多不同的实例进行事务处理，但用户本身并不知情；
. 设计应用进行异步 I/O 操作，这样应用在等待输入输出完成时也能进行有用的工作；
. 将线程、网络连接和数据库连接等资源集中，这有助于使计算资源最大化，并提高您预测资源使用
的能力；
. 采用既可以实现并发最大化，同时还能使排它锁定最小化的方式写入数据库操作。例如，在执行只
读操作时，不要锁定记录。
当然，这只是对这一问题的最简单讨论。关于如何实施可扩展架构，我们可以大书特书，有关材料可谓
汗牛充栋。如欲了解更多指南，请参见《微软模式和实践》中有关性能与可扩展性方面的资料，网址如
下：http://msdn.microsoft.com/practices/Topics/perfscale/default.aspx。
数据扩展
随着数据库向越来越多的用户同时提供服务以及数据库的不断扩大，执行查询和搜索等操作所需的时间
也将大幅延长。 SaaS 应用通常使用相同的数据库同时为数以千计的客户提供服务，因此特别容易受
到该类型性能降低的影响。所以，我们要为未来的发展做好充分计划，这一点相当重要。
扩展数据库的简便方法之一就是进行分区，将数据分入较小的块，以提高查询和更新的效率。我们不妨
考虑建立分区策略，明确数据分区的最佳途径。例如，如果应用的客户来自世界各地，那么我们可采用
地理分区策略，属于欧洲客户的数据位于一个分区，属于亚洲客户的数据位于另一个分区，以此类推。
就大多数情况而言，数据库的大小会不断扩展。因此，我们还应采取一个适当的动态再分区策略，将已
经分区的数据进行再分区，以满足性能和扩展的需要，这一点也相当重要。
操作结构
第三个重大思维转变就是优化应用的操作结构：将应用提供给客户需要做哪些工作？如何保证应用的可
用性以及如何经济有效地确保应用良好运行？对于许多 ISV 而言，他们从未帮助客户运行过数据中
心，这可能也是 SaaS 供应商最不熟悉的环节。 SaaS 供应商不仅应是软件设计和市场营销专家，还
需是操作和管理方面的专家。
微软操作框架 (MOF) 等资源能够针对维护系统可靠性、可用性、可支持性和易管理性等提供大量有益
的相关指导。除 MOF 能解决常见操作问题外， SaaS 模式还具有一些自身特有的难题。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
20
共享服务
如果您曾经亲自创建过企业级万维网，那么您可能会对网络托管和中间件服务的基本情况有所了解。公
司既可独立托管网站，也可与外部供应商达成协议，共同进行设备代管或包括硬件、存储和网络带宽等
项目在内的全业务托管。托管服务主要确保站点的可用性，但通常不负责站点的运营和维护。
在准备托管时，可考虑增加一个 SaaS 附加层。根据您的业务计划，您可能需要一个测量与计费系
统，以便实现如下目标：
. 准确跟踪客户的使用，根据用户使用的时间和资源向他们开出账单。
. 在某些时刻或满足有关标准的情况下限制或阻止访问。
. 监控站点访问和性能，确保符合 SLA 的规定。
. 执行其他功能，确保客户的无缝体验，满足或超过客户的预期目标。
用于执行上述功能的系统整体成为共享服务。
共享服务可进一步分为两小类。
. 运营支持服务 (OSS) 处理账户激活、供应、服务担保、使用和测量等运营问题。
. 业务支持服务 (BSS) 支持计费服务（其中包括发票、定价、税收和收款等）和客户管理（其中包
括订单录入、客户自助服务、客户关怀、故障记录和客户关系管理等）。
与传统的 Web 主机托管一样，您也应确定是自建共享服务层并自己提供应用的主机服务，还是与外部
主机服务公司（即 SaaS 供应商）达成合同，由其来提供相应服务。 SaaS 供应商可提供一系列共享
服务，能够有效解决上述商务与运营问题。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
21
监督
您与客户达成的 SLA 将您应满足的运营标准加以量化。SLA 是具有法律约束力的合同，如果不能满足
协议要求，就意味着将损失大量收入，对您的商誉造成影响。监督应用架构，防范其出问题，这是在问
题导致严重停机或降低性能之前查出并修复故障的重要途径。
可用性监控
确保系统的高度可用性是所有 SaaS 开发商的重中之重。停机不仅影响一台服务器或数据中心，还会
导致大部分客户数据丢失，降低工作效率，甚至影响到所有用户！有些 ISV 从传统的台式机或客户端
—服务器软件开发向 SaaS 模式转型，对他们来说，确保以网络为中心的应用模型的可用性，将是全
新的、从未遇到过的挑战。我们建议您在应用中建立中心监控 (heartbeat monitoring) 与告警机制
等基本方法的支持，并特别关注潜在的薄弱连接，如不在您控制之下的到数据库的远程连接。
当然，告警等技术机制只是确保高度可用性的一部分，如果发出告警却没有任何反应，那么也根本不能
起作用。要确保您的运营中心制定具体到位的行动措施和标准，在系统发生故障时能发挥实效。
如欲了解与高可用性相关问题的概括介绍，请参见微软 TechNet 上的文章“服务管理功能：可用
性”，网址为：
http://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfavamg.mspx。
性能监控
客户希望您提供的应用达到可接受的性能水平。从一定意义上说，SLA 作为您与客户达成合同的一部
分，对这种性能要求提出了明确规定。不过，除了 SLA 的明文规定外，如果客户感觉您的应用速度
慢，反应迟钝，那么他们也很可能终止合同，或拒绝继续作为付费用户。牢骚满腹的用户会在网站上大
发不满或在行业出版物上抱怨连连，从而使您的应用声名狼藉。相反，快速高效的应用不仅能满足用户
需求，还能使他们开心。如果客户从反应较慢的传统软件套件转而采用您的软件的话，您还会使他们更
容易接受整个 SaaS 模式。
为了确保高级性能，只要有可能，就应直接在应用设计中构建相应的性能支持。要对 CPU 占用和应用
响应时间等性能指标设定标准，如果出现管理问题，要马上通知相关人员解决。
确定性能底线通常是最重要的工作。性能底线将便于我们在不正常情况发生时及时察觉问题的症结所
在。
结论
本文讨论的有关问题还有大量的篇幅可谈可写，不过，您读到现在，应该对 SaaS 模式以及如何让您
和您的客户受益于这种模式有了一定的了解，并建立了一个基本的相关概念框架。作为一种软件服务的
新模式，SaaS 是建立在多用户效率、高度可扩展性与元数据可配置性基础上的架构模型，能够以极低
的成本为现有与潜在客户提供出色的软件。采用新的理念与原理将助您更有效地把握长尾部分的商机。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
22
反馈
本文作者欢迎您就本文内容提供反馈意见。请将您的反馈意见发送至以下电子邮件地址：
fredch@microsoft.com 或gianpc@microsoft.com。谢谢！