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