|
. 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 等出版物都拿來當存貨。不過，網絡零售商則不用擔心存貨問題，他們能直接從全球各大倉庫直 接向客戶發貨，即便銷售的出版物受歡迎程度很低，其廣告和銷售成本也毫不受影響，同樣像暢銷出版 物一樣大作宣傳。因而長尾類低銷量出版物也能贏得大量收入。 3 http://www./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。謝謝！ |
|
|
來自： ShangShujie > 《document》
