. Microsoft Corporation 2006 年保留所有版權(quán)。
抓住長尾市場的架構(gòu)戰(zhàn)略
2006 年 4 月
Frederick Chong 與 Gianpaolo Carraro
微軟公司
Copyright . Microsoft Corporation 2006. All Rights Reserved.
2
致謝
非常感謝 Paul Henry 在撰寫技術(shù)內(nèi)容方面給予的幫助。
說明
本文檔所包含的信息代表了在發(fā)布之日，Microsoft Corporation 對所討論問題的當前看法。因
為微軟必須順應(yīng)不斷變化的市場情況，因而該文檔不應(yīng)理解為 Microsoft 單方面的承諾，
Microsoft 不保證所給信息在發(fā)布這日以后的準確性。
本文檔僅供參考。對于本文檔中的信息，Microsoft 不做任何明示、默示或法定的擔保。
遵守所有適用的版權(quán)法律是用戶的責任。在不對版權(quán)法所規(guī)定的權(quán)利加以限制的情況下，如未
得到 Microsoft Corporation 明確的書面許可，不得為任何目的、以任何形式或手段（電子的、
機械的、影印、錄制等等）復(fù)制或傳播本文的任何部分，也不得將其存儲或引入到檢索系統(tǒng)
中。
Microsoft 可能擁有本檔主題涉及到的專利、專利申請、商標、版權(quán)或其他知識產(chǎn)權(quán)。除非在
Microsoft 的任何書面許可協(xié)議中明確表述，否則獲得本文檔不代表您將同時獲得這些專利、商
標、版權(quán)或其他知識產(chǎn)權(quán)的任何許可證。
除非另外注明，否則此處作為例子提到的公司、組織、產(chǎn)品、域名、電子郵件地址、徽標、人
員、地點以及事件純屬虛構(gòu)，決不意指，也不應(yīng)由此臆測任何真實的公司、組織、產(chǎn)品、域
名、電子郵件地址、徽標、人員、地點和事件。
. 2005 Microsoft Corporation，保留所有權(quán)利。
Microsoft、Visual Studio 以及 .NET 徽標是 Microsoft Corporation 在美國和／或其他國家的注
冊商標或商標。
所有其他商標均是其各自所有者的財產(chǎn)。
Copyright . Microsoft Corporation 2006. All Rights Reserved. 3
引言
軟件即服務(wù)這一話題已是眾口相傳。軟件業(yè)有關(guān)文獻中關(guān)于“軟件即服務(wù)” (SaaS) 的文章不勝枚
舉，其中很多都用到了“革命性”和“產(chǎn)業(yè)格局”等措辭詞。大家都知道（或以為自己知道）什么是軟
件即服務(wù)，都認為這一理念意義重大。不過，很少有人能真正定義這一理念，了解如何實踐這一理念的
人就更是寥寥無幾了。
因此，既然 SaaS 對應(yīng)用實施的未來發(fā)展如此重要，為什么人們在實踐這一理念時很難獲得有用的指
導(dǎo)呢？
我們認為，SaaS 確實將對軟件產(chǎn)業(yè)發(fā)揮重大影響，因為軟件即服務(wù)將改變?nèi)藗儤?gòu)建、銷售、購買以及
使用軟件的方式。不過，為了將此變?yōu)楝F(xiàn)實，軟件開發(fā)商需要高效開發(fā) SaaS 應(yīng)用的資源和信息。
本文是微軟 (Microsoft) 介紹 SaaS 理念系列文章中的第一篇，后續(xù)系列文章將為讀者解開 SaaS 的
神秘面紗，并為設(shè)計 SaaS 應(yīng)用提供實際的、現(xiàn)實的指導(dǎo)。本文將概括介紹 SaaS 理念、其面臨的挑
戰(zhàn)，及其如何為有興趣提供 SaaS 應(yīng)用的公司帶來好處。本系列隨后的幾篇文章將詳細討論有關(guān)問
題。
本文首先提出什么是軟件即服務(wù)，并介紹 SaaS 供應(yīng)商必須經(jīng)歷的概念轉(zhuǎn)型，以了解新理念與傳統(tǒng)的
內(nèi)部部署軟件的不同之處。隨后，我們將討論 SaaS 商務(wù)模型，了解軟件即服務(wù)如何能在現(xiàn)實商務(wù)中
盈利。
本文將重點討論架構(gòu)問題，因此最大篇幅將集中在 SaaS 應(yīng)用的架構(gòu)上。我們給出四級成熟模型，介
紹 SaaS 的部分主要特性：可配置性、多用戶效率以及可擴展性。我們將研究高級 SaaS 架構(gòu)的組
件，并側(cè)重探討 SaaS 架構(gòu)師通常面臨的難題，即，如何為擴展多用戶應(yīng)用的數(shù)據(jù)模型提供適當機
制。
最后，我們將簡要討論 SaaS 應(yīng)用投入部署后與開展支持工作相關(guān)的運營問題。
什么是軟件即服務(wù)？
時至今日，如何準確定義“軟件即服務(wù)”(SaaS) 仍然沒有定論，問五個人可能就會有五種不同的答
案。不過，大多數(shù)專家可能會在 SaaS 區(qū)別于傳統(tǒng)套裝軟件和簡單 Web 站點的一些基本特點上達成
一致。簡言之，軟件即服務(wù)具備以下特點：
“軟件部署為托管服務(wù)，通過因特網(wǎng)存取?！?br>我們不妨花些時間來思考一下這一定義的含意。這種定義既未限定具體的應(yīng)用架構(gòu)，也未指定特定的技
術(shù)或協(xié)議；沒有在企業(yè)與個人消費者之間的服務(wù)進行區(qū)分，也沒有要求具體的商業(yè)模型。根據(jù)上述定
義，軟件即服務(wù)的主要特點在于應(yīng)用代碼所處的位置以及部署和存取應(yīng)用代碼的方式。1
根據(jù)這一定義，SaaS 將包括許多您意想不到的服務(wù)和應(yīng)用。例如，我們不妨考慮一下基于 Web 的電
子郵件服務(wù)，如 Microsoft. Hotmail. 等。盡管您在考慮 SaaS 時很難率先想到 Hotmail 也屬于
SaaS 的范疇，但 Hotmail 確實滿足了所有 SaaS 的基本標準：供應(yīng)商提供所有程序邏輯和數(shù)據(jù)的主
機服務(wù)，使最終用戶能夠通過基于 Web 的用戶界面在公共因特網(wǎng)上存取數(shù)據(jù)。
從一般到具體，我們認為軟件即服務(wù)有兩大類別：
1 這種定義是不是過于簡化了？簡而言之，確實有一些簡單化。隨后我們將集中討論一些能夠定義和區(qū)
別擁有良好設(shè)計的成熟 SaaS 應(yīng)用的重要屬性。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
4
. 面向企業(yè)的服務(wù) (Line-of-business service)，向各種規(guī)模的企業(yè)和組織提供的服務(wù)。面向企
業(yè)的服務(wù)通常是可定制的大型商務(wù)解決方案，旨在協(xié)助開展財務(wù)、供應(yīng)鏈管理以及客戶關(guān)系等商務(wù)
工作。這種服務(wù)通常采用用戶預(yù)訂的銷售方式。
. 面向個人消費者的服務(wù) (Consumer-oriented service)，向公眾提供的一類服務(wù)。面向個人
消費者的服務(wù)有時以用戶購買的方式銷售，不過通常免費提供給用戶，從廣告中賺取收入。
本文將側(cè)重討論與開發(fā)面向企業(yè)的服務(wù)應(yīng)用相關(guān)的架構(gòu)及商業(yè)問題，文中給出的概念與范例都與企業(yè)應(yīng)
用相關(guān)。不過，多用戶定制和可擴展性、數(shù)據(jù)擴展以及隔離等問題也會出現(xiàn)在個人消費者領(lǐng)域（事實上
更便于解決），因而個人消費型 SaaS 服務(wù)的開發(fā)商閱讀本文也將有所裨益。
將軟件作為服務(wù)來考慮
為了實現(xiàn)從提供內(nèi)部部署軟件向軟件即服務(wù)的轉(zhuǎn)變，軟件廠商應(yīng)在三個相互關(guān)聯(lián)的領(lǐng)域中轉(zhuǎn)變思路：一
是商業(yè)模型；二是應(yīng)用架構(gòu)；三是運營結(jié)構(gòu)。
Software
Services
Business
Model
Operational
Structure
Application
Architecture
在以下三部分中，我們將以 SaaS 的應(yīng)用架構(gòu)為側(cè)重點更深入地討論上述轉(zhuǎn)變。
轉(zhuǎn)變商業(yè)模式
轉(zhuǎn)變商業(yè)模式將涉及以下一種乃至更多種情況：
. 將軟件的“所有權(quán)”從客戶轉(zhuǎn)移至外部供應(yīng)商；
. 將技術(shù)基礎(chǔ)設(shè)施和管理等方面（如硬件與專業(yè)服務(wù)）的責任從客戶重新分配給供應(yīng)商；
. 通過專業(yè)化和規(guī)模經(jīng)濟降低提供軟件服務(wù)的成本；
. 降低軟件銷售的最低成本，針對小型企業(yè)的長尾市場做工作。
為了實現(xiàn) SaaS 理念的優(yōu)勢，供應(yīng)商與客戶都應(yīng)進行思維轉(zhuǎn)型，并且供應(yīng)商還應(yīng)幫助客戶實現(xiàn)這種轉(zhuǎn)
變。
Copyright . Microsoft Corporation 2006. All Rights Reserved. 5
誰“擁有”軟件？
大多數(shù)軟件的銷售方式幾十年以來一直一成不變?？蛻魹槭褂密浖徺I許可證，并在屬于客戶或歸客
戶控制的硬件上安裝軟件，而供應(yīng)商則根據(jù)許可證協(xié)議或技術(shù)支持協(xié)議提供支持。在誠實公開的軟件交
易中，“許可證”的技術(shù)性含義如下：從法律上說，客戶購買的只是使用軟件拷貝的權(quán)利，但從實際目
的而言，客戶似乎是“擁有”軟件的，并能根據(jù)需要隨時使用軟件，使用多長時間都可以。
軟件作為產(chǎn)品的商業(yè)模式是軟件市場的整體情況，在此環(huán)境下，軟件即服務(wù)理念會讓人感到相當陌生：
我們告訴客戶，他們不是直接“擁有”重要的軟件，而是要為運行在別人服務(wù)器上的軟件支付使用費，
如果停止用戶付費，就不能再獲得軟件使用權(quán)。因此，潛在的客戶應(yīng)了解 SaaS 為什么能比傳統(tǒng)的模
式提供更直接、更可量化的經(jīng)濟收益，這一點特別重要。
轉(zhuǎn)移 IT 工作責任
在一般的公司中，信息技術(shù) (IT) 預(yù)算用于以下三大領(lǐng)域：
. 軟件 —— 企業(yè)用于計算與信息處理的實際程序和數(shù)據(jù)；
. 硬件 —— 可為用戶提供軟件存取的臺式計算機、服務(wù)器、網(wǎng)絡(luò)組件以及移動設(shè)備 等；
. 專業(yè)服務(wù) —— 確保系統(tǒng)能夠不間斷運行和可用的人員和機構(gòu)，包括技術(shù)支持人員、咨詢?nèi)藛T以及
廠商代表等。
在上述三大領(lǐng)域中，軟件是最直接參與信息管理的部分，這也是所有 IT 公司要實現(xiàn)的最終目標。硬件
與專業(yè)服務(wù)盡管是 IT 環(huán)境的重要組成部分，但我們通常將其視為實現(xiàn)目的的手段，而不是目的本身，
因為這兩者能確保軟件實現(xiàn)高效信息管理的最終目標。（換言之，只要能有效地增加軟件功能，又不必
添置額外的硬件，那么任何公司都愿意這么做。但是，如果沒有增加軟件功能的需要，任何公司都不會
無緣無故地添置硬件。）
在圍繞內(nèi)部部署軟件構(gòu)建起來的 IT 環(huán)境中，大部分預(yù)算通?；ㄙM在硬件和專業(yè)服務(wù)上，使得可用的軟
件預(yù)算只占少數(shù)。
Hardware Professional
Services
Software
在這種模式下，軟件預(yù)算主要用于購買商業(yè)軟件套件的許可證以及定制的業(yè)務(wù)軟件。硬件預(yù)算主要用于
最終用戶使用的臺式機和便攜式計算機、存儲數(shù)據(jù)和應(yīng)用的服務(wù)器，以及可實現(xiàn)網(wǎng)絡(luò)化連接的組件。專
Copyright . Microsoft Corporation 2006. All Rights Reserved.
6
業(yè)服務(wù)預(yù)算用于支付技術(shù)支持人員的薪水，他們負責部署并為軟硬件提供支持，此外還要為咨詢?nèi)藛T和
開發(fā)資源付費，這是設(shè)計并構(gòu)建定制系統(tǒng)所需的。2
在主要采用 SaaS 模式的公司中，IT 預(yù)算的分配大為不同。
Hardware Services
Software
在這種模式下，SaaS 廠商在其公司內(nèi)部的中央服務(wù)器上存儲重要的應(yīng)用和相關(guān)數(shù)據(jù)，并擁有專業(yè)的支
持人員來維護軟硬件。這就使公司客戶不用再為主機上運行的軟件提供支持，也不必再為此而購買和維
護服務(wù)器硬件。此外，通過 Web 或智能客戶端提供的應(yīng)用對臺式計算機的性能要求要顯著低于本地安
裝應(yīng)用，這就使客戶能大幅延長臺式計算機的使用壽命。最終，絕大部分 IT 預(yù)算能用于軟件，通常以
向 SaaS 供應(yīng)商交納的使用費的形式支付。
充分利用規(guī)模經(jīng)濟
上述情況是否僅是一種難以實現(xiàn)的空想呢？說到底，為了獲得“軟件”而支付給 SaaS 供應(yīng)商的使用
費中的一部分，必定要用于 SaaS 供應(yīng)商的硬件和專業(yè)服務(wù)成本。這時，就要考慮規(guī)模經(jīng)濟效應(yīng)的問
題。假定 SaaS 供應(yīng)商中央主機上運行的單套軟件擁有 x 家客戶，那么該供應(yīng)商就能統(tǒng)一為所有客戶
提供服務(wù)。例如，企業(yè) SaaS 應(yīng)用安裝在五個服務(wù)器組成的負載平衡群集上，可支持 50 家中等規(guī)模
的客戶，也就是說，每家客戶只需負擔一臺服務(wù)器成本的十分之一。如果相同的應(yīng)用由各家客戶進行本
地安裝，就要求每家客戶專門為該應(yīng)用提供服務(wù)器，有時如果負載平衡和可用性要求高的話，還需要甚
至不止一臺服務(wù)器。因此，SaaS 模式比傳統(tǒng)模式更節(jié)約成本，對于可擴展性較強的 SaaS 應(yīng)用而
言，隨著客戶的增多，每家客戶的運營成本會不斷降低。同時，隨著客戶的增多，供應(yīng)商將加強多用戶
這一重要特性，以更低的成本提供更高質(zhì)量的服務(wù)。因此，即便考慮到 SaaS 供應(yīng)商的硬件和專業(yè)服
務(wù)成本，客戶仍能用相同的 IT 預(yù)算實現(xiàn)高得多的純軟件功能。
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 等網(wǎng)絡(luò)零售商為什么處于有利地位，為什么能針對傳統(tǒng)零售商難以以低成本提供服務(wù)的
領(lǐng)域填補需求空白，從而使“長尾”這一新概念通俗易懂。
The Long Tail
Demand
Popularity Rank
書籍、光盤等各種商品門類的需求往往符合“冪次定律分布”。在這種情況下，每年發(fā)布的書籍、CD
以及 DVD 數(shù)不勝數(shù)，但只有少數(shù)能長期成為暢銷品，其他的往往屬于反響平平的長尾類出版物：大量
出版物只讓少部分有專門愛好的人感興趣，出版量很小，甚至連幾千份的拷貝都沒有。
傳統(tǒng)的實體型零售商致力于銷售最流行的出版物，因為他們不可能把數(shù)以百萬計的書籍、CD 以及
DVD 等出版物都拿來當存貨。不過，網(wǎng)絡(luò)零售商則不用擔心存貨問題，他們能直接從全球各大倉庫直
接向客戶發(fā)貨，即便銷售的出版物受歡迎程度很低，其廣告和銷售成本也毫不受影響，同樣像暢銷出版
物一樣大作宣傳。因而長尾類低銷量出版物也能贏得大量收入。
3 http://www./wired/archive/12.10/tail.htm
Copyright . Microsoft Corporation 2006. All Rights Reserved.
8
大型的實體書店能在其書架上存放 13 萬種不同的出版物。而 Anderson 指出，Amazon.com 書籍
銷量的大部分都來自 13 萬種流行出版物之外，換言之，Amazon.com 賣出的書中，大部分都是在傳
統(tǒng)的實體書店中買不到的。
復(fù)雜的企業(yè)軟件解決方案供應(yīng)商面臨著相似的市場境況。
與簡單的套裝軟件不同，企業(yè)軟件需要針對不同客戶的需求進行定制，可能包括現(xiàn)場安裝、廠商服務(wù)隊
伍上門服務(wù)等，通常還需要專門的服務(wù)器硬件和支持人員加以管理。提供上述專門服務(wù)的成本會一定程
度上增加供應(yīng)商銷售軟件的最低成本。因此，這種軟件通常面向大型企業(yè)，只有大型企業(yè)才有實力來支
付專門服務(wù)。不過，相對于購買企業(yè)解決方案的大型企業(yè)數(shù)量而言，有著同樣需求的中小型企業(yè)的數(shù)量
要多得多，但他們卻難以承擔高昂的成本。
Copyright . Microsoft Corporation 2006. All Rights Reserved. 9
SaaS 供應(yīng)商可消除維護成本，利用規(guī)模經(jīng)濟效益將客戶的硬件和服務(wù)需求加以整合，這樣就能提供比
傳統(tǒng)廠商價格低得多的解決方案，這不僅減輕了財務(wù)成本，而且大幅減少了客戶增加 IT 基礎(chǔ)設(shè)施建設(shè)
的需要。因此，SaaS 供應(yīng)商能面向全新的客戶群開展市場工作，而這部分客戶是傳統(tǒng)解決方案供應(yīng)商
所無力顧及的，因為他們根本就沒辦法為這部分客戶提供低價格的服務(wù)。
有效面向小型客戶開展市場工作，這就要求習(xí)慣于通過人際交往以及傳統(tǒng)廠家和客戶關(guān)系搞營銷的供應(yīng)
商們進行思維轉(zhuǎn)型；大多數(shù)供應(yīng)商難以用大規(guī)模市場上的較低價格向更大的客戶群體提供個性化服務(wù)。
搞 SaaS 營銷就像銷售手機彩鈴或音樂下載服務(wù)一樣，應(yīng)該讓客戶能訪問您的 Web 站點，成為您所
提供服務(wù)的付費用戶，通過信用卡付費就能開始享受服務(wù)，整個過程無須供應(yīng)商方面的人為介入。這不
是說您就不用對需求范圍廣的大規(guī)?？蛻羧鹤鋈穗H聯(lián)系工作。不過，在銷售工作的設(shè)計、營銷、供應(yīng)和
定制過程中從頭到尾都是自動化的，因此我們不僅能提供自動化服務(wù)，同時又能簡化您支持部門員工的
工作，因而不用再幫助客戶完成相關(guān)任務(wù)。
應(yīng)用架構(gòu)
我們對軟件即服務(wù)理念還沒有最終定義，目前暫定的概念如下，即，軟件部署為托管服務(wù)，通過因特網(wǎng)
存取。根據(jù)對軟件和存取這兩個詞定義的方式不同，上述定義可能包含很多含義，或許含義會多得不勝
枚舉。對應(yīng)用架構(gòu)師師而言，上述定義基本上不會對如何設(shè)計出可行的 SaaS 應(yīng)用發(fā)揮什么實際作
用，不能區(qū)別如何讓 SaaS 應(yīng)用成功，避免失敗。比方說，基本代碼有十年歷史的企業(yè)應(yīng)用，根據(jù)目
前需要現(xiàn)加上 HTML 前端，這種軟件也能算作廣義的軟件即服務(wù)，不過這種應(yīng)用大多數(shù)都難以實現(xiàn)有
效擴展，也不夠廉價，因此都會遇到問題。因此，為了定義什么才是成熟的 SaaS 應(yīng)用，我們必須提
出一些額外的標準。
單實例多用戶架構(gòu)的三大特點
從應(yīng)用架構(gòu)師的角度來看，設(shè)計出色的 SaaS 應(yīng)用與設(shè)計欠佳的應(yīng)用之間主要有三點不同之處。設(shè)計
出色的 SaaS 應(yīng)用具有可擴展性、多用戶高效性，而且可配置。
應(yīng)用的可擴展性是指能最大限度地提高并行性，以便更高效地利用應(yīng)用資源，例如，我們要優(yōu)化鎖定時
間、無態(tài)性、共享線程和網(wǎng)絡(luò)連接等匯集資源、高速緩沖參考數(shù)據(jù)以及對大型數(shù)據(jù)庫進行分區(qū)等。
對習(xí)慣于設(shè)計獨立的單用戶應(yīng)用的架構(gòu)師而言，多用戶性要求他們進行重要的思維轉(zhuǎn)型。例如，一家公
司的用戶使用 CRM 應(yīng)用服務(wù)存取客戶信息時，該用戶連接的應(yīng)用實例同時可能還會為其他幾十家，甚
或是數(shù)百家公司的用戶提供服務(wù)，各用戶之間彼此互不知情。這就要求應(yīng)用架構(gòu)能夠最大化不同用戶間
的資源共享，不過仍要區(qū)分屬于不同客戶的數(shù)據(jù)。
當然，如果我們必須用一臺服務(wù)器上的單個應(yīng)用實例滿足多家不同公司的需求，那么我們就難以針對某
個最終用戶的使用體驗編寫定制代碼，因為只要針對某個客戶進行了應(yīng)用定制，就會改變其他用戶的使
用。因此，我們不是在傳統(tǒng)的意義上進行應(yīng)用定制，而是讓每個客戶用元數(shù)據(jù)配置應(yīng)用的外觀和行為。
SaaS 架構(gòu)師面臨的挑戰(zhàn)在于，如何確?？蛻魬?yīng)用配置的簡易性，同時還不必為每項配置支付額外的開
發(fā)或運營成本。
軟件即服務(wù)的成熟模型
我們通過確定成熟 SaaS 應(yīng)用的三大重要特性進一步改進了 SaaS 的定義。不過，成熟的 SaaS 模式
不一定同時具備這三個特性，有的應(yīng)用只具備其中的一種或兩種，但仍能滿足所有必需的商業(yè)要求。這
時，如果實現(xiàn)其他的特點難以保持低成本性的話，那么應(yīng)用架構(gòu)師就不必實現(xiàn)其余的特性了。
從廣義上說，我們可采用四級模型來說明 SaaS 應(yīng)用的成熟度，每一級都比前一級增加了上述三種成
熟特性中的一種。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
10
第一級：特定的/定制的
成熟度的第一級類似于 20 世紀 90 年代傳統(tǒng)的應(yīng)用服務(wù)供應(yīng)商 (ASP) 提供軟件的模式。在這種情況
下，不同的客戶擁有各自主機應(yīng)用的定制版本，在主機服務(wù)器上運行自己的應(yīng)用實例。從架構(gòu)上說，這
種成熟級別的軟件與傳統(tǒng)銷售的企業(yè)系列軟件很相似，即公司中的不同客戶連接到服務(wù)器上運行的相同
實例，但該實例完全獨立于主機上其他客戶運行的其他實例或進程。
一般說來，傳統(tǒng)的客戶端—服務(wù)器應(yīng)用無需太多開發(fā)工作，也不必從頭重新設(shè)計整個系統(tǒng)，就能轉(zhuǎn)變?yōu)?br>第一級成熟度的 SaaS 模型。盡管這一級別的成熟性難以提供全面成熟型 SaaS 解決方案的很多優(yōu)
勢，但仍能幫助供應(yīng)商整合服務(wù)器硬件和管理，從而降低成本。
第二級：可配置性
對于第二級成熟度而言，供應(yīng)商為不同的客戶（或用戶）分別提供應(yīng)用實例主機服務(wù)。就第一級成熟度
而言，每個實例都是對用戶分別定制的，而在第二級成熟度上，所有實例都使用相同的代碼實施，供應(yīng)
商提供詳細的配置選擇，讓客戶能改變應(yīng)用的外觀和行為，從而滿足客戶的需求。盡管不同實例在代碼
層面上彼此相同，但彼此之間仍完全隔離。
供應(yīng)商所有客戶都使用相同的代碼庫，這大幅降低了 SaaS 應(yīng)用的服務(wù)要求，因為代碼庫的任何更改
都能立刻方便地作用于供應(yīng)商的所有客戶，從而無需逐一更新或優(yōu)化每個定制實例了。但是，在應(yīng)用最
初針對獨立定制而不是配置元數(shù)據(jù)進行設(shè)計的情況下，將傳統(tǒng)的應(yīng)用轉(zhuǎn)變?yōu)榈诙壋墒於鹊?SaaS 應(yīng)
用時，比起第一級成熟度的轉(zhuǎn)型而言，將需要多得多的架構(gòu)重新設(shè)計工作。
與第一級成熟度類似，第二級成熟度也要求供應(yīng)商提供足夠的硬件和存儲資源，以支持大量應(yīng)用實例同
時運行。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
11
第三級：可配置性與多用戶效率
對于第三級成熟度，供應(yīng)商借助單個實例來滿足不同客戶的需求，并采用可配置的元數(shù)據(jù)為不同的用戶
提供獨特的用戶使用體驗和特性集。授權(quán)與安全性策略可確保不同客戶的數(shù)據(jù)彼此區(qū)分開來。從最終用
戶的角度來看，不會察覺到應(yīng)用是與多個用戶共享的。
這使我們就不再需要為不同客戶的不同實例提供大量服務(wù)器空間，因此使用計算資源的效率將大大超過
第二級成熟度，從而直接降低了成本。但是，這時的一大弱點在于，應(yīng)用的可擴展性有限。如果不用分
區(qū)來管理數(shù)據(jù)庫性能的話，我們只能通過采用更強大處理器來擴展應(yīng)用（向上擴展），但是這樣做只能
使投入回報逐漸降低，最終導(dǎo)致功能的提高難以適應(yīng)低成本的要求。
第四級：可擴展性、可配置性與多用戶效率
第四級成熟度也是最高級成熟度，這時供應(yīng)商在負載平衡的服務(wù)器群上為不同客戶提供主機服務(wù)，運行
相同的實例，不同客戶的數(shù)據(jù)彼此分開，可配置的元數(shù)據(jù)可以提供獨特的用戶體驗與特性集。SaaS 系
統(tǒng)具備可擴展性，可輕松適應(yīng)大規(guī)模客戶的需要，可在無需對應(yīng)用進行額外架構(gòu)設(shè)計的情況下根據(jù)需求
靈活地增減后端服務(wù)器的數(shù)量，不管有多少用戶，都能像針對單個用戶一樣方便地實施應(yīng)用修改。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
12
高級架構(gòu)
從架構(gòu)上看，SaaS 應(yīng)用與采用服務(wù)導(dǎo)向型設(shè)計原理開發(fā)的其他應(yīng)用很相似。
選擇成熟度級別
您的應(yīng)用應(yīng)采取哪種成熟度級別？我們可能認為，所有 SaaS 應(yīng)用的最終目標都是實現(xiàn)第四級的成
熟度，但事實并非如此。我們可將 SaaS 成熟度視為隔離數(shù)據(jù)和共享數(shù)據(jù)兩個極端之間的一點。
Per-tenant SLA
Data separation Isolate Share Economy of scale
Simpler management
具體應(yīng)用應(yīng)在兩端之間的哪一點上，這取決于您的業(yè)務(wù)、架構(gòu)及運營需求，也取決于客戶的考慮。
我們這里只做簡單的說明，不過您仍能看出，所有這些因素在一定程度上都是相互關(guān)聯(lián)的。
. 業(yè)務(wù)模型。隔離方法是否有利于贏利？如果拋棄了共享方案的經(jīng)濟性和管理優(yōu)勢，這將意味著
您向消費者提供應(yīng)用的成本將會更高。但在某些情況下，為了滿足其他需要，這種做法會是值
得的。此外，即便您向用戶解釋不存在機密數(shù)據(jù)遭竊的風(fēng)險，但有的客戶從法律或文化的角度
出發(fā)，也會強烈抵制不同用戶共用應(yīng)用的架構(gòu)模型。當然，說到底，您的商業(yè)模型應(yīng)確保您不
管采取何種成熟度的模型，都能實現(xiàn)盈利。
. 架構(gòu)模型。您的應(yīng)用能否運行統(tǒng)一的邏輯實例？如果您希望將基于臺式機或傳統(tǒng)客戶端—服務(wù)
器應(yīng)用轉(zhuǎn)移至基于因特網(wǎng)的交付系統(tǒng)，那么原來的應(yīng)用可能根本不能與統(tǒng)一實例、以元數(shù)據(jù)為
中心的模式相兼容，您需要明確為了將原系統(tǒng)轉(zhuǎn)型為完全成熟的 SaaS 應(yīng)用進行大量投資，到
底從財務(wù)上合不合算。如果您從頭設(shè)計和構(gòu)建網(wǎng)絡(luò)原生應(yīng)用，那么您在采用單個實例模式時才
會擁有更高的自由度。
. 運營模型。您能否確保始終滿足服務(wù)水平協(xié)議 (SLA) 的要求？您應(yīng)仔細考慮您與客戶之間現(xiàn)有
SLA 條款下您應(yīng)承擔的責任，其中包括停機時間、支持選項、災(zāi)難恢復(fù)等，并確定上述責任在
互不相關(guān)的客戶共用一個應(yīng)用實例的應(yīng)用架構(gòu)下能否得到保證。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
13
上圖描繪的大部分組件對大多數(shù)應(yīng)用架構(gòu)師而言都是相當熟悉的。進程服務(wù)給出了智能客戶端和/或網(wǎng)
絡(luò)供應(yīng)層可調(diào)用的界面，并能啟動同步工作流程或長時間運行的事務(wù)處理，以調(diào)用其他商業(yè)服務(wù)，與各
處的數(shù)據(jù)存儲進行互動以讀寫商業(yè)數(shù)據(jù)。安全性服務(wù)負責控制最終用戶和后臺軟件服務(wù)的存取。
最重要的區(qū)別在于增加了元數(shù)據(jù)服務(wù)，其負責管理不同用戶的應(yīng)用配置。服務(wù)和智能客戶端與元數(shù)據(jù)服
務(wù)發(fā)生互動，以檢索描述各用戶配置和擴展的相關(guān)信息。
元數(shù)據(jù)服務(wù)
就成熟的 SaaS 應(yīng)用而言，元數(shù)據(jù)服務(wù)供應(yīng)商為客戶提供了定制和配置應(yīng)用、滿足其特定需求的主要
手段。通常，客戶可在四大領(lǐng)域進行配置更改：
. 用戶界面與品牌?？蛻敉ǔＯＭ哂杏脩艚缑娴恼{(diào)整功能，以反映各自公司的品牌風(fēng)格，因此
SaaS 應(yīng)用通常都提供相關(guān)特性，以使客戶能夠更改諸如圖形、色彩、字體等相關(guān)內(nèi)容。
. 工作流程與商務(wù)規(guī)則。為了能廣泛地向各種潛在客戶提供服務(wù)，任務(wù)關(guān)鍵型 SaaS 應(yīng)用必須能夠
滿足不同工作流程的需要。例如，對于跟蹤發(fā)票流轉(zhuǎn)的應(yīng)用而言，一家客戶可能要求所有發(fā)票均由
同一名經(jīng)理批準；另一家客戶則要求每張發(fā)票都由兩名經(jīng)理先后批準，第三家客戶則要求每張發(fā)票
得到兩名經(jīng)理批準，而不考慮先后。這時，不同客戶應(yīng)能根據(jù)需要自行配置應(yīng)用的工作流程，以滿
足各自的商業(yè)進程要求。
. 數(shù)據(jù)模型的擴展。對于許多數(shù)據(jù)驅(qū)動型 SaaS 應(yīng)用而言，單個模型顯然不能滿足所有需要。即便
對于相對簡單的任務(wù)專用應(yīng)用而言，如果數(shù)據(jù)字段和表格一成不變，也會給客戶造成麻煩。可擴展
的數(shù)據(jù)模型使客戶能自由地讓應(yīng)用根據(jù)自身需要工作，而不必為了滿足應(yīng)用的要求而改變商業(yè)進
程。在本文隨后部分，您將進一步了解可擴展客戶數(shù)據(jù)模型的架構(gòu)。
. 存取控制。通常，客戶負責創(chuàng)建每個最終用戶各自的賬戶，并確定每個用戶能夠存取使用的資源和
功能。我們用安全策略跟蹤每個用戶的使用權(quán)限，客戶應(yīng)能對安全策略加以配置。
為了幫助客戶靈活地根據(jù)需要進行軟件配置，我們將上述選項組織成層級的配置單元，即“配置域”，
每個配置域都包括不同的選項，以更針對上述四個領(lǐng)域做出相應(yīng)更改。每家客戶都擁有頂級配置域，使
他們能夠在需要時進行配置，并能在頂級配置域下構(gòu)建任意層級的一個或多個配置域。我們還采用關(guān)系
Copyright . Microsoft Corporation 2006. All Rights Reserved.
14
策略來決定子節(jié)點 (child node) 能否繼承母節(jié)點 (parent node) 的配置設(shè)置，或忽略母節(jié)點的設(shè)
置。
舉例而言，如果普通客戶購買了整個企業(yè)的應(yīng)用使用權(quán)，其不同的業(yè)務(wù)部門有著不同的需要，那么這些
部門都應(yīng)遵循統(tǒng)一的公司標準，同時還應(yīng)各自配置自身使用的應(yīng)用元素。在各業(yè)務(wù)部門內(nèi)部，同樣也會
存在下級單位，它們都有自己特殊的配置需要。對于上述各組織單元而言，客戶可分別建立配置域，登
錄不同的單元選擇各自的配置選項，設(shè)置或更改均可。
與供應(yīng)商定制的傳統(tǒng)業(yè)務(wù)應(yīng)用不同，SaaS 應(yīng)用更多情況下是由客戶自身進行配置的。因此，設(shè)計配置
界面非常重要。理想情況下，客戶應(yīng)能夠通過向?qū)Щ蚝喴锥庇^的屏幕指導(dǎo)進行應(yīng)用配置，屏幕上應(yīng)提
供所有可用的選項，既避免客戶面臨一大堆信息無從下手，又能清晰地反映給定配置域下能否針對相關(guān)
選項進行更改。
安全性服務(wù)
在任何軟件環(huán)境下，安全性都是至關(guān)重要的。SaaS 的性質(zhì)決定了安全性既是客戶的最大關(guān)注點，又是
應(yīng)用架構(gòu)師需優(yōu)先考慮的重點。以下給出的一些基本指南，有助于確保用戶控制其專用數(shù)據(jù)。
認證
SaaS 供應(yīng)商通常將創(chuàng)建和維護用戶賬戶的責任下放給客戶，這稱作下放管理權(quán)。管理權(quán)下放造成的
情況是，客戶負責創(chuàng)建不同的用戶賬戶，而 SaaS 供應(yīng)商應(yīng)認證有關(guān)賬戶。根據(jù)管理權(quán)下放模式的要
求，SaaS 架構(gòu)師采用兩種通用辦法來解決認證問題：一是集中認證系統(tǒng) (centralized
authentication system)，一是非集中認證系統(tǒng) (decentralized authentication system)。所選
的認證系統(tǒng)不同，將導(dǎo)致架構(gòu)的復(fù)雜性不同，也會導(dǎo)致最終用戶應(yīng)用體驗的不同，因此您在制定決策
時，應(yīng)根據(jù)商業(yè)模型的需要來確定應(yīng)用、客戶和最終用戶的需要。
對于集中認證系統(tǒng)而言，供應(yīng)商管理中央用戶賬戶數(shù)據(jù)庫，該數(shù)據(jù)庫為所有應(yīng)用的用戶提供服務(wù)。客戶
的管理員被授權(quán)在用戶賬戶目錄下創(chuàng)建、管理和刪除用戶賬戶。登錄應(yīng)用的用戶向應(yīng)用提供認證信息，
有關(guān)信息根據(jù)中央目錄下的信息加以確認，如果數(shù)據(jù)有效，就允許該用戶訪問。
這種方法所要求的認證基礎(chǔ)設(shè)施相對簡單，便于設(shè)計和實施，也不需要改變客戶自身的用戶基礎(chǔ)設(shè)施。
不過這種方法的重要缺點之一在于，集中認證系統(tǒng)很難實現(xiàn)單點登錄 (single sign-on)，即用戶一次
登錄，就始終能訪問企業(yè)網(wǎng)絡(luò)。沒有單點登錄功能，用戶總會被提示輸入應(yīng)用登錄信息，每次都要手動
再次輸入。
在非集中認證系統(tǒng)中，客戶采用可與其自己的用戶目錄服務(wù)相連接的聯(lián)合服務(wù) (federation
service)。當最終用戶嘗試訪問應(yīng)用時，聯(lián)合服務(wù)將對用戶進行本地認證，并發(fā)布安全令牌， SaaS
供應(yīng)商的認證系統(tǒng)將接受安全令牌，并允許用戶接入應(yīng)用。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
15
在單點登錄相當重要的情況下，這是一種理想的方式，因為認證在后臺進行，不要求用戶記住并輸入一
系列相關(guān)信息。不過，非集中認證方案比集中認證方案要復(fù)雜得多，而且，如果 SaaS 應(yīng)用有著幾千
家客戶的話，就要與眾多客戶的聯(lián)合服務(wù)分別建立聯(lián)邦式的信任關(guān)系。
在許多情況下，SaaS 供應(yīng)商都希望采用混合方式，對小型客戶采用集中認證系統(tǒng)來認證和管理，而對
要求單點登錄并愿為此付費的大型企業(yè)提供聯(lián)合服務(wù)。
授權(quán)
通常，存取 SaaS 應(yīng)用中的資源和商務(wù)功能都用“角色”的概念來管理。角色與公司中的特定崗位功
能映射。每個角色都被賦予一項或更多“許可”，分配到某個角色的用戶就能根據(jù)相應(yīng)的“業(yè)務(wù)規(guī)則”
執(zhí)行行動。
Purchaser
Approver if(totalCost < 1500)
if((role == ‘Purchaser‘) ||
(role==‘Approver‘ &&
duringOfficeHours==false))
Users &
Groups Roles Permissions Business Rules Action
SaaS 應(yīng)用內(nèi)部負責對角色進行管理，角色可包含單個用戶的賬戶以及用戶群組。不同用戶賬戶和用
戶群組根據(jù)需要被分配到不同的角色。
根據(jù)用戶所分配到的角色，該用戶可獲得一項或者多項許可，以執(zhí)行特定的操作或活動。這些活動通常
直接與重要的商務(wù)功能或應(yīng)用管理本身映射。例如，購買應(yīng)用可能包括創(chuàng)建、提交、批準以及拒絕購買
訂單的相關(guān)許可；抵押經(jīng)紀公司的應(yīng)用會包括檢查借款人信用和批準貸款的許可，等等?？筛鶕?jù)需要向
一個或多個角色分配一個許可；每個用戶可根據(jù)所屬的角色獲得相關(guān)角色的所有許可。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
16
應(yīng)用可根據(jù)商務(wù)規(guī)則對活動和資源的使用實現(xiàn)比許可更精確的控制。商務(wù)規(guī)則規(guī)定了在允許使用前必須
滿足的條件。例如，您可使用相關(guān)商務(wù)規(guī)則，只允許用戶在正常辦公時間內(nèi)在不同賬戶間轉(zhuǎn)賬，或者規(guī)
定轉(zhuǎn)賬金額不得超過一定數(shù)量。
存取控制由配置域管理。每個配置域根據(jù)應(yīng)用的關(guān)系策略繼承上級配置域的角色、許可和商務(wù)規(guī)則，并
可在適當?shù)臅r候?qū)ζ溥M行修改、添加和刪除。例如，假設(shè)有家客戶總部設(shè)在美國，并在加拿大多倫多設(shè)
有分支機構(gòu)。根配置域設(shè)有最基本的“福利管理員”角色，可針對雇員福利管理提供一系列許可，其中
包括管理公司的 401(k) 退休儲蓄計劃等。由于 401(k) 計劃是美國稅收法律的產(chǎn)物，不適用于加拿
大，因此我們可為加拿大辦事處構(gòu)建子配置域，在繼承“福利管理員”角色和相關(guān)許可的同時，對角色
的許可給出特殊處理，以修改401(k) 計劃相關(guān)內(nèi)容。在修改原許可的同時，客戶增加了新的許可，
允許該角色修改注冊退休儲蓄計劃 (RRSP) 項目，即加拿大相當于美國 401(k) 的立法。
Root Scope Canada (child scope)
Benefits
Administrator
Benefits
Administrator
從最佳實踐角度看，應(yīng)用應(yīng)向所有用戶提供一系列默認的角色、許可和商務(wù)規(guī)則，并應(yīng)允許不同用戶通
過直觀易用的界面定制這些規(guī)則和創(chuàng)建更多規(guī)則。
深入探討：多用戶數(shù)據(jù)模型
到此為止，我們已在相當高級的層面上討論了應(yīng)用架構(gòu)，下面我們不妨來詳細討論一個具體問題，即如
何設(shè)計一款客戶能在多用戶環(huán)境下實現(xiàn)擴展的數(shù)據(jù)模型。我們并不是要全面討論數(shù)據(jù)模型擴展，不過這
有助于您在一定程度上了解 SaaS 應(yīng)用設(shè)計相關(guān)的各種架構(gòu)問題。
根據(jù)設(shè)計，您的應(yīng)用自然將包括標準的數(shù)據(jù)庫設(shè)置，根據(jù)解決方案的性質(zhì)提供默認的表格、字段、查詢
和關(guān)系等。不過，不同公司有著各自獨特的需求，僵化的、不能擴展的數(shù)據(jù)模型難以滿足這種需求。例
如， SaaS 工作跟蹤系統(tǒng)的一位客戶需要存儲外部生成的分類代碼串，每項記錄都應(yīng)將系統(tǒng)與其他進
程完全集成。而另一家客戶則不需要分類串字段，而要求支持類 ID 號（整數(shù)）跟蹤。因此，除非在少
數(shù)專業(yè)領(lǐng)域，您開發(fā)和實施的方法通常應(yīng)讓客戶能擴展默認的數(shù)據(jù)模型，以滿足其各自的需求，同時又
不會影響其他客戶使用的數(shù)據(jù)模型。我們將討論可解決上述問題的三種一般性方法：一是專用的用戶數(shù)
據(jù)庫；二是共享數(shù)據(jù)庫配合固定擴展集，；三是共享數(shù)據(jù)庫配合定制擴展。
專用用戶數(shù)據(jù)庫
第一種方法就是為各客戶提供專用的數(shù)據(jù)庫，客戶可根據(jù)需要擴展數(shù)據(jù)庫。
就這種方法而言，如果有新客戶就創(chuàng)建新的標準默認數(shù)據(jù)庫，作為進程部署的一部分，同時元數(shù)據(jù)服務(wù)
跟蹤數(shù)據(jù)庫分配給客戶的情況。一旦創(chuàng)建了新的數(shù)據(jù)庫，客戶可在應(yīng)用的用戶界面和程序邏輯允許的情
況下隨意修改，包括創(chuàng)建新字段、新查詢，乃至新的表格和關(guān)系等。
如果提供服務(wù)的成本不是問題的話，那么我們考慮這種方法就行了，因為這是最簡單的方法，而且為客
戶擴展默認數(shù)據(jù)模型提供了最大的自由度。此外，銀行和醫(yī)療記錄管理等領(lǐng)域的客戶需要極高的數(shù)據(jù)隔
離，如果不能為不同的客戶提供獨立的數(shù)據(jù)庫，甚至根本不會考慮有關(guān)應(yīng)用。這種方法的劣勢在于，每
Copyright . Microsoft Corporation 2006. All Rights Reserved.
17
部服務(wù)器只能支持數(shù)量有限的數(shù)據(jù)庫，因此基礎(chǔ)設(shè)施成本會不斷升高，而且比其他方法的成本增速都要
快。
共享數(shù)據(jù)庫，固定擴展集
第二種方法是所有客戶共享一個數(shù)據(jù)庫，數(shù)據(jù)庫預(yù)設(shè)一些定制字段，允許用戶根據(jù)需要分配使用。
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 字段將不同記錄與相應(yīng)的客戶相關(guān)聯(lián)。除了標
準字段集外，還提供了一系列定制字段，各客戶可選擇字段的用途，以及如何收集數(shù)據(jù)。
定制字段可根據(jù)類型區(qū)分，因此客戶可通過應(yīng)用和數(shù)據(jù)庫提供的任何內(nèi)置的類型檢查和確認功能來確認
數(shù)據(jù)。此外，字段也可不分為類型，以便客戶用其存儲任何類型的數(shù)據(jù)。（客戶也可選擇提供自己的確
認邏輯，避免用戶無意輸入無效數(shù)據(jù)。）
共享數(shù)據(jù)庫在提供服務(wù)方面的成本大大低于隔離的數(shù)據(jù)庫，因為單個數(shù)據(jù)庫引擎在需要分區(qū)前可支持大
量客戶。這種方法的最大弱點在于，數(shù)據(jù)模型的可擴展性受限于定制字段的數(shù)量。為了明智地決定定制
字段的數(shù)量，應(yīng)認真分析客戶潛在的需要。如果定制字段太少，客戶就不能有效使用應(yīng)用；如果定制字
段太多，就會造成數(shù)據(jù)庫浪費，很多字段都得不到利用。
共享數(shù)據(jù)庫，定制擴展
第三種方法是構(gòu)建統(tǒng)一的共享數(shù)據(jù)庫，并允許客戶自行擴展數(shù)據(jù)模型，在不同的表格中將定制數(shù)據(jù)存儲
為名稱值對 (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
這時，包含定制數(shù)據(jù)的每個客戶記錄都被分配到了一個唯一的記錄 ID，在獨立的擴展表格中與一行或
多行相匹配。對于表格中的各行而言，都存儲了一個名稱值對。每個客戶都能根據(jù)商務(wù)需要創(chuàng)建任意數(shù)
量的名稱值對。當應(yīng)用檢索客戶記錄時，會在定制數(shù)據(jù)表格中進行搜索，選擇所有對應(yīng)于記錄 ID 的
行，返回后作為普通字段數(shù)據(jù)處理。顯然，定制數(shù)據(jù)表格中的數(shù)據(jù)不能分類，因為其中包含的數(shù)據(jù)對不
同客戶而言可能采用多種不同格式。為了解決這一問題，我們可選擇再增加一列，保存數(shù)據(jù)類型標識
符，這樣在檢索數(shù)據(jù)時就能將數(shù)據(jù)與相應(yīng)的數(shù)據(jù)類型對應(yīng)。
這種方法使我們能夠隨意擴展數(shù)據(jù)模型，同時還能保持采用共享數(shù)據(jù)庫的成本優(yōu)勢。其主要弱點在于增
加了數(shù)據(jù)庫功能的復(fù)雜性，如檢索、索引、查詢和更新記錄都變得更為復(fù)雜。如果您估計客戶在擴展默
認數(shù)據(jù)模型時需要高度靈活性而又不需要數(shù)據(jù)隔離，那么這種方法就是最佳選擇。
在開發(fā)可擴展性數(shù)據(jù)模型時，應(yīng)記住，客戶實施的任何擴展都會要求商業(yè)邏輯的相應(yīng)擴展，這樣應(yīng)用才
能使用定制數(shù)據(jù)，同時也要求配置邏輯的擴展，這樣用戶才能輸入定制數(shù)據(jù)并獲得輸出。因此，您向客
戶提供的配置界面應(yīng)針對上述三種方法提供相應(yīng)的更新機制，并最好以整合的方式提供。（在后續(xù)發(fā)布
的文章中，我們將討論如何采取相應(yīng)機制，幫助客戶擴展商務(wù)邏輯和用戶界面。）
可擴展性
大型企業(yè)軟件旨在讓數(shù)千人同時使用。如果您有過開發(fā)此類企業(yè)應(yīng)用的經(jīng)驗，您肯定已親自遇到過創(chuàng)建
可擴展架構(gòu)的重大挑戰(zhàn)。對于 SaaS 應(yīng)用而言，可擴展性更為重要：您所支持的用戶數(shù)量，是單個客
戶的平均用戶群乘以客戶總數(shù)。對那些習(xí)慣于設(shè)計內(nèi)部企業(yè)軟件的 ISV 來說，支持這樣大規(guī)模的用戶
群就如同從低級別聯(lián)賽進級參加頂級聯(lián)賽一樣：規(guī)則是熟悉的，但賽事本身則是完全不同的級別。這時
您所構(gòu)建的不是一個廣泛部署的業(yè)務(wù)關(guān)鍵型企業(yè)應(yīng)用，而是一個因特網(wǎng)級的系統(tǒng)，需要積極支持數(shù)以百
萬計的潛在用戶群。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
19
應(yīng)用擴展
當然，您的解決方案很難成為像 Hotmail 那樣擁有龐大的用戶群（如果確實擁有這么多用戶，真該恭
喜您?。?。不過，可擴展性方面的挑戰(zhàn)卻是相同的。
應(yīng)用可向上擴展（將應(yīng)用轉(zhuǎn)移至更強大的較大型服務(wù)器上），也可橫向擴展（在更多的服務(wù)器上運行應(yīng)
用）。對所有曾用全新計算機取代過舊計算機的人來說，向上擴展并不陌生，該解決方案通常更適用于
那些無需為眾多并發(fā)用戶提供服務(wù)的小型應(yīng)用。不過，就 SaaS 而言，橫向擴展通常是擴充容量的最
佳辦法，這一點我們在 SaaS 成熟度模型中已經(jīng)探討過了。設(shè)計出色的 SaaS 應(yīng)用可橫向擴展到眾多
服務(wù)器上，每臺服務(wù)器都運行應(yīng)用的一個或更多實例。設(shè)計“橫向擴展型”應(yīng)用的一些設(shè)計指南如下：
. 設(shè)計應(yīng)用運行在無狀態(tài)模式下，所有必需的用戶和會話數(shù)據(jù)都存儲在客戶端或分布式存儲設(shè)備上，
任何應(yīng)用實例都能訪問。無狀態(tài)是指每個事務(wù)處理都能由任何實例來完成，用戶在一次會話中可用
眾多不同的實例進行事務(wù)處理，但用戶本身并不知情；
. 設(shè)計應(yīng)用進行異步 I/O 操作，這樣應(yīng)用在等待輸入輸出完成時也能進行有用的工作；
. 將線程、網(wǎng)絡(luò)連接和數(shù)據(jù)庫連接等資源集中，這有助于使計算資源最大化，并提高您預(yù)測資源使用
的能力；
. 采用既可以實現(xiàn)并發(fā)最大化，同時還能使排它鎖定最小化的方式寫入數(shù)據(jù)庫操作。例如，在執(zhí)行只
讀操作時，不要鎖定記錄。
當然，這只是對這一問題的最簡單討論。關(guān)于如何實施可擴展架構(gòu)，我們可以大書特書，有關(guān)材料可謂
汗牛充棟。如欲了解更多指南，請參見《微軟模式和實踐》中有關(guān)性能與可擴展性方面的資料，網(wǎng)址如
下：http://msdn.microsoft.com/practices/Topics/perfscale/default.aspx。
數(shù)據(jù)擴展
隨著數(shù)據(jù)庫向越來越多的用戶同時提供服務(wù)以及數(shù)據(jù)庫的不斷擴大，執(zhí)行查詢和搜索等操作所需的時間
也將大幅延長。 SaaS 應(yīng)用通常使用相同的數(shù)據(jù)庫同時為數(shù)以千計的客戶提供服務(wù)，因此特別容易受
到該類型性能降低的影響。所以，我們要為未來的發(fā)展做好充分計劃，這一點相當重要。
擴展數(shù)據(jù)庫的簡便方法之一就是進行分區(qū)，將數(shù)據(jù)分入較小的塊，以提高查詢和更新的效率。我們不妨
考慮建立分區(qū)策略，明確數(shù)據(jù)分區(qū)的最佳途徑。例如，如果應(yīng)用的客戶來自世界各地，那么我們可采用
地理分區(qū)策略，屬于歐洲客戶的數(shù)據(jù)位于一個分區(qū)，屬于亞洲客戶的數(shù)據(jù)位于另一個分區(qū)，以此類推。
就大多數(shù)情況而言，數(shù)據(jù)庫的大小會不斷擴展。因此，我們還應(yīng)采取一個適當?shù)膭討B(tài)再分區(qū)策略，將已
經(jīng)分區(qū)的數(shù)據(jù)進行再分區(qū)，以滿足性能和擴展的需要，這一點也相當重要。
操作結(jié)構(gòu)
第三個重大思維轉(zhuǎn)變就是優(yōu)化應(yīng)用的操作結(jié)構(gòu)：將應(yīng)用提供給客戶需要做哪些工作？如何保證應(yīng)用的可
用性以及如何經(jīng)濟有效地確保應(yīng)用良好運行？對于許多 ISV 而言，他們從未幫助客戶運行過數(shù)據(jù)中
心，這可能也是 SaaS 供應(yīng)商最不熟悉的環(huán)節(jié)。 SaaS 供應(yīng)商不僅應(yīng)是軟件設(shè)計和市場營銷專家，還
需是操作和管理方面的專家。
微軟操作框架 (MOF) 等資源能夠針對維護系統(tǒng)可靠性、可用性、可支持性和易管理性等提供大量有益
的相關(guān)指導(dǎo)。除 MOF 能解決常見操作問題外， SaaS 模式還具有一些自身特有的難題。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
20
共享服務(wù)
如果您曾經(jīng)親自創(chuàng)建過企業(yè)級萬維網(wǎng)，那么您可能會對網(wǎng)絡(luò)托管和中間件服務(wù)的基本情況有所了解。公
司既可獨立托管網(wǎng)站，也可與外部供應(yīng)商達成協(xié)議，共同進行設(shè)備代管或包括硬件、存儲和網(wǎng)絡(luò)帶寬等
項目在內(nèi)的全業(yè)務(wù)托管。托管服務(wù)主要確保站點的可用性，但通常不負責站點的運營和維護。
在準備托管時，可考慮增加一個 SaaS 附加層。根據(jù)您的業(yè)務(wù)計劃，您可能需要一個測量與計費系
統(tǒng)，以便實現(xiàn)如下目標：
. 準確跟蹤客戶的使用，根據(jù)用戶使用的時間和資源向他們開出賬單。
. 在某些時刻或滿足有關(guān)標準的情況下限制或阻止訪問。
. 監(jiān)控站點訪問和性能，確保符合 SLA 的規(guī)定。
. 執(zhí)行其他功能，確?？蛻舻臒o縫體驗，滿足或超過客戶的預(yù)期目標。
用于執(zhí)行上述功能的系統(tǒng)整體成為共享服務(wù)。
共享服務(wù)可進一步分為兩小類。
. 運營支持服務(wù) (OSS) 處理賬戶激活、供應(yīng)、服務(wù)擔保、使用和測量等運營問題。
. 業(yè)務(wù)支持服務(wù) (BSS) 支持計費服務(wù)（其中包括發(fā)票、定價、稅收和收款等）和客戶管理（其中包
括訂單錄入、客戶自助服務(wù)、客戶關(guān)懷、故障記錄和客戶關(guān)系管理等）。
與傳統(tǒng)的 Web 主機托管一樣，您也應(yīng)確定是自建共享服務(wù)層并自己提供應(yīng)用的主機服務(wù)，還是與外部
主機服務(wù)公司（即 SaaS 供應(yīng)商）達成合同，由其來提供相應(yīng)服務(wù)。 SaaS 供應(yīng)商可提供一系列共享
服務(wù)，能夠有效解決上述商務(wù)與運營問題。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
21
監(jiān)督
您與客戶達成的 SLA 將您應(yīng)滿足的運營標準加以量化。SLA 是具有法律約束力的合同，如果不能滿足
協(xié)議要求，就意味著將損失大量收入，對您的商譽造成影響。監(jiān)督應(yīng)用架構(gòu)，防范其出問題，這是在問
題導(dǎo)致嚴重停機或降低性能之前查出并修復(fù)故障的重要途徑。
可用性監(jiān)控
確保系統(tǒng)的高度可用性是所有 SaaS 開發(fā)商的重中之重。停機不僅影響一臺服務(wù)器或數(shù)據(jù)中心，還會
導(dǎo)致大部分客戶數(shù)據(jù)丟失，降低工作效率，甚至影響到所有用戶！有些 ISV 從傳統(tǒng)的臺式機或客戶端
—服務(wù)器軟件開發(fā)向 SaaS 模式轉(zhuǎn)型，對他們來說，確保以網(wǎng)絡(luò)為中心的應(yīng)用模型的可用性，將是全
新的、從未遇到過的挑戰(zhàn)。我們建議您在應(yīng)用中建立中心監(jiān)控 (heartbeat monitoring) 與告警機制
等基本方法的支持，并特別關(guān)注潛在的薄弱連接，如不在您控制之下的到數(shù)據(jù)庫的遠程連接。
當然，告警等技術(shù)機制只是確保高度可用性的一部分，如果發(fā)出告警卻沒有任何反應(yīng)，那么也根本不能
起作用。要確保您的運營中心制定具體到位的行動措施和標準，在系統(tǒng)發(fā)生故障時能發(fā)揮實效。
如欲了解與高可用性相關(guān)問題的概括介紹，請參見微軟 TechNet 上的文章“服務(wù)管理功能：可用
性”，網(wǎng)址為：
http://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfavamg.mspx。
性能監(jiān)控
客戶希望您提供的應(yīng)用達到可接受的性能水平。從一定意義上說，SLA 作為您與客戶達成合同的一部
分，對這種性能要求提出了明確規(guī)定。不過，除了 SLA 的明文規(guī)定外，如果客戶感覺您的應(yīng)用速度
慢，反應(yīng)遲鈍，那么他們也很可能終止合同，或拒絕繼續(xù)作為付費用戶。牢騷滿腹的用戶會在網(wǎng)站上大
發(fā)不滿或在行業(yè)出版物上抱怨連連，從而使您的應(yīng)用聲名狼藉。相反，快速高效的應(yīng)用不僅能滿足用戶
需求，還能使他們開心。如果客戶從反應(yīng)較慢的傳統(tǒng)軟件套件轉(zhuǎn)而采用您的軟件的話，您還會使他們更
容易接受整個 SaaS 模式。
為了確保高級性能，只要有可能，就應(yīng)直接在應(yīng)用設(shè)計中構(gòu)建相應(yīng)的性能支持。要對 CPU 占用和應(yīng)用
響應(yīng)時間等性能指標設(shè)定標準，如果出現(xiàn)管理問題，要馬上通知相關(guān)人員解決。
確定性能底線通常是最重要的工作。性能底線將便于我們在不正常情況發(fā)生時及時察覺問題的癥結(jié)所
在。
結(jié)論
本文討論的有關(guān)問題還有大量的篇幅可談可寫，不過，您讀到現(xiàn)在，應(yīng)該對 SaaS 模式以及如何讓您
和您的客戶受益于這種模式有了一定的了解，并建立了一個基本的相關(guān)概念框架。作為一種軟件服務(wù)的
新模式，SaaS 是建立在多用戶效率、高度可擴展性與元數(shù)據(jù)可配置性基礎(chǔ)上的架構(gòu)模型，能夠以極低
的成本為現(xiàn)有與潛在客戶提供出色的軟件。采用新的理念與原理將助您更有效地把握長尾部分的商機。
Copyright . Microsoft Corporation 2006. All Rights Reserved.
22
反饋
本文作者歡迎您就本文內(nèi)容提供反饋意見。請將您的反饋意見發(fā)送至以下電子郵件地址：
fredch@microsoft.com 或 gianpc@microsoft.com。謝謝！