SaaS系列介紹之六: SaaS模式分析(上)

標籤：blog   http   使用   os   strong   資料   

1 引言

　　如果我們想要更多的玫瑰花，就必須種植更多的玫瑰樹。

　　                           ________姚群《成功激勵格言精選》

　　SaaS模式是個新興的話題，有許多慨念還定義不清楚，其研究的內容又很複雜。我們從SaaS模式的軟體平台成熟度等級上入手，分析SaaS模式中有代表並關鍵的模式。重點放在品質管理上。從品質管理上分析如何提高SaaS應用的品質。

　　2 SaaS模式研究的主要內容

　　SaaS模式所要研究與實現的內容非常多，我們分情況分重點可歸納如下：

　　l SaaS的運營模式

　　分析SaaS服務的營銷方式、服務成本及收費手段、SaaS模式的人群關係。

　　研究實施SaaS服務的過程管理，結合軟體工程原理、ISO2000規範、CMMI規範、IPD(整合產品開發)以及IT企業專案實施的經驗，形成一整套滿足SaaS模式的實施過程管理規範。做到諮詢正常化、培訓標準化、控制科學化、使用制度化。

　　結合我國中小企業，特別是個人消費者對SaaS平台與軟體的典型應用中的整合需求，對網路化製造與SaaS的服務功能、服務標準和規範技術進行研究，設計與編製中小商業網路化製造系統與SaaS服務的標準化體繫結構、整合介面方案和相關規範。開發標準化整合介面軟體工具。

　　l SaaS的商業模式

　　企業門戶的誕生、搜尋引擎的崛起、SOA的熱門、Web2.0的浪潮……這一路互連網走得跌跌撞撞卻賺得盆滿缽溢。而在軟體行業，互連網化和服務化已是大勢所趨。

　　面對已在美國形成風暴的線上服務，2008年被定位為中國的SaaS年。我們在這一曆史時機決戰的大戰役中是觀望不前，還是積極投入?

　　SaaS的商業模式主要分析SaaS在管理軟體應用的切入點、勘探群、盈利模式、市場容量、發展周期、收費模式、周期每階段預期的收入、競爭環境。

　　l SaaS的開發模式

　　SaaS的開發需要打造一個開發鏈。我們需要有一個統一的SaaS平台，有自訂工作流程、自訂表格單、自訂資料模型、自訂介面、自訂報表、統一組織機構及許可權控制。還需要有依賴平台的如CRM類的業務系統。這些軟體首先要考慮到如何架構、如何設計、如何開發、如何測試、如何部署、如何版本控制、如何培訓教育、如何支援服務大家，這些方面都必須規範統一。

　　團隊配合方面，需要有group、wiki、blog、mail、IM、office online來協作，並且必要的時候還需要配合程式碼搜尋。這也就是為什麼google大力發展Gmail、Gtalk、Project Hosting、code search、office online、blog、group forum、SVN。其實Google要搭建的就是SaaS平台和SaaS生態鏈。您看Google不僅給我們提供了分布式全球儲存基礎設施(商業稱“雲端儲存、雲端運算”)、各種應用，而且提供了應用API，而且最近還提供了App Engine，而且還提供了代碼社區。

　　l SaaS平台實現模式、應用模式和商務模式的研究與實現

　　通過深入分析我國中小企業特別是園區企業對網路化製造系統的需求，建立符合地區製造業和園區經濟發展特色的、可操作的SaaS平台實現模式、應用模式和商務模式。確保SaaS服務平台商務模式的實用性和可推廣性。

　　l 中小企業核心商務程序的研究與實現

　　選擇工業園區、軟體園區、生產力促進中心，通過多視圖整合化建模，對中小企業現狀從靜態布局、動態運行和企業管理等三方面進行描述，分析其組織機構、崗位設定、商務程序、商業模式、資訊流、知識流、資產流、總體或局部功能結構，從而形成面向特定產業的多視圖的知識管理、供應鏈管理、專案管理和資訊管理模型。

　　l 基於SaaS模式的中小企業管理軟體的體繫結構設計

　　研究基於國際互連網或園區網路的SaaS模式的企業管理軟體的體繫結構，以中小企業SaaS服務平台為重點，分析剖析SaaS平台的架構設計及業務應用軟體的體系架構及相關組合關係。

　　l 基於SaaS模式的應用軟體構件的配置與管理

　　運用應用伺服器(Application Server)對開發的應用系統構件和構件包進行管理，方便靈活的實現系統可配置、可裁剪、可定製、可修改，保證軟體系統適應不同的管理員模式，支援商務程序重組和軟體系統功能的配置與調整。

　　l 安全性原則及加密技術的實現

　　面向中小企業管理的SaaS系統平台是用同一套平台供大量企業使用者使用，除了考慮基礎平台要具有可擴充性以外，還要解決應用軟體系統一對多的適應性和資料存取權限的安全性原則及加密技術。

　　l SaaS服務平台資源的整合

　　SaaS服務平台提供給使用者的服務是多功能、全方位的。要解決資源的整合，包括多系統整合、多目標控制、多使用者協同、多級許可權控制技術和開發、維護、遞送多個客戶共用的軟體服務技術，以及基於多層架構，C/S模式、B/S模式，系統集中運行、資料分開存放的軟體技術。

　　l 採用軟體構件化技術，開發適合我國中小企業管理員模式的構件庫和構架庫

　　以物件導向的設計思想，組件化開發方式，利用介面技術開發如工作流程引擎、自訂報表、基於標準協議的資料交換模組、動態表單、統一許可權控制及認證等中介軟體，提供特定服務的構件庫及構架庫，把應用邏輯封裝成套件，通過系統配置功能將構件組裝成面向具體企業的服務模組，設計出高內聚低耦合的可高度複用的構件模組。建立基於J2EE、.net平台的軟體構件包。

　　這種軟體包應該在軟體開發過程充分體現構件化的優越性並可進行軟體再工程。

　　l 建立工業園區企業、科技園區企業等中小企業SaaS服務平台

　　研究與建設為工業園區企業、科技園區企業、生產力促進中心提供專業化的網路化製造服務，並包括政策與法律、軟體與資訊共用、培訓與諮詢等基礎與共性的服務於中小企業的SaaS服務平台。

　　l SaaS的運行技術基礎

　　SaaS僅僅只是片面理解的一套可以儲存多個客戶單位元據的B/S軟體。如果您要應對上億次的訪問，幾億使用者的並發和資料存放區，您的運行基礎設施一定是一個可信平台。

　　3 SaaS模式的推動力

　　研究SaaS模式是個很複雜的工程，如何推動SaaS模式，我們應該做到以下幾點：

　　l 需要專門的SaaS專家

　　SaaS是一種很專業的模式，要正確實現它往往需要一個有實踐經驗的SaaS專家作為夥伴來給予協助。對於任何規模的公司來說，和一名SaaS專家來貫徹始終地評估和最佳化業務將會有助於避免代價高昂的錯誤、減少未來的和現在的成本以及獲得加速業務增長的回報。

　　l 財務的重新評估

　　對於軟體公司來說，進入SaaS市場所面臨的最大的內部挑戰就是為一種完全不同的收入模式來配置人員和其他資源。在傳統的、持久的許可模式下，收入以一種大型的、迴圈的模式來達到平衡。

　　但在SaaS模式中，客戶以月為基礎來為使用軟體付費。剛開始的時候可能比傳統許可的收入要低得多。但是，一兩年或這更長的時期，SaaS的收入可能遠遠超出許可模式，並且它會提供更多的可預見的現金流。在一個理想的SaaS模式中，持續的投入需要軟體公司對自己的預算和收益做出計劃。

　　l 客戶持續租用決定SaaS的成功

　　使客戶持續租用至關重要，因此，軟體公司需要一組新的規範，如100%的正常已耗用時間、高水平的安全和效能保證，面向服務的運作方法必須負責確保服務的品質、優質的發布，並且最重要的是要保證客戶的滿意度。這種滿意度包括：產品的易用性、訪問資料的快速、服務的持續和穩定、資料的安全和備份等。

　　這樣的需求在SaaS基礎設施上提出了新的要求，以滿足必須的效能、可用性和安全需求，持續的應用監控是必需的。

　　l 持續保持新的面孔

　　當然，客戶的需要和期望總是隨著時間而改變的。這意味著，軟體公司也必須對他們的開發過程保持一種新鮮的面孔。SaaS業務的成功很大程度上依賴於產品的製造和發布。客戶總是對產品提出各種新的思想，共性被客戶提出並得到廠商的回應，新鮮感讓客戶覺得廠商一直為客戶著想和努力。

　　l 軟體廠商的技術能力

　　在SaaS環境中，應用程式代碼本身往往必須經過最佳化，以確保可靠性和高效能。另外，產品擴充和新產品開發必須要對市場動態作出響應。所有這些都需要一個針對SaaS環境調整的流水化開發過程。

　　不斷最佳化產品，軟體廠商需要快速提高他們的開發能力，不再只是簡單地進入市場，而是基於預先的前端產品規劃和部門管理的運作。軟體廠商應該獲得工具和洞察力，從而以一種更加順利和可操控的方式帶來更多備受關注和頻繁的軟體功能的發布，以滿足日益變化的顧客需求。

　　l 銷售如何推進

　　既然SaaS為終端使用者消除了先期許可和基礎設施成本，購買決策往往從公司層級轉移到部門層級。因此，SaaS銷售人員必須拜訪相應的部門經理，而不是IT執行官。

　　另一個重要的考慮是市場營銷。對SaaS產品有效市場營銷技術和對許可軟體有效那些市場營銷技術是不同的，如何影響勘探關注SaaS產品仍然是一個值得研究的課題。

　　1)通訊頻寬的限制

　　SaaS商業模式需要有充足的頻寬資源支援，目前我國的通訊基礎設施有了很大的發展，但是頻寬資源還沒到富餘的程度，因此，頻寬資源可能會成為制約SaaS發展的一個重要因素。

　　2)網路安全性

　　網路的安全性包括了兩層含義：一是技術上能夠抵禦駭客的非法侵入，另一層更重要的含義是SaaS商本身的職業操守達到一定的層次，顧客的商業秘密不會因SaaS自身的原因而泄露。

　　3)社會信用體系

　　我們看到美國的SaaS業發展迅速，應該看到他們多年積累的信用體系其實是SaaS發展的關鍵動力。然而，反觀國內的企業，普遍缺乏信用觀念，這極大地增加了SaaS使用者的交易成本和投資風險。

　　4)品牌因素

　　由於SaaS這一商業模式本身需要很高的技術要求、安全要求和信用要求，SaaS商的品牌因素也特別重要。

　　雖然技術是SaaS成功的原動力之一，但是SaaS的成功關鍵不僅在於先進技術和人力資源的掌握，也依賴於對相關商務程序和資訊管理的行業經驗，因此目前的少數SaaS所提供的功能遠不能滿足企業使用者的需要，無法達到真正的SaaS所提供的功能。

　　4 SaaS模式的軟體平台成熟度等級

　　SaaS模式的軟體平台是個很複雜的東西，如何檢驗平台的成熟度等級標準至今並沒有統一的結論，我們嘗試通過對國內外基於SaaS模式的軟體平台設計中若干關鍵要素及常見架構的研究，結合目前市場趨勢，對SaaS軟體平台進行初步的探討和分析。

　　4.1 SaaS軟體平台的三大特點

　　從應用架構師的角度來看，設計出色的SaaS應用與設計欠佳的應用之間主要有三點不同之處。設計出色的SaaS應用具有可擴充性、多使用者高效性，而且可配置。

　　l 可擴充性

　　應用的可擴充性是指能最大限度地提高並行性，以便更高效地利用應用資源，例如，我們要最佳化鎖定時間、無態性、共用線程和網路連接等彙集資源、高速緩衝參考資料以及對大型資料庫進行分區等。

　　l 多使用者高效性

　　對習慣於設計獨立的單使用者應用的架構師而言，多使用者性要求他們進行重要的思維轉型。例如，一家公司的使用者使用CRM應用服務存取客戶資訊時，該使用者連線應用程式執行個體同時可能還會為其他幾十家，甚或是數百家公司的使用者提供服務，各使用者之間彼此互不知情。這就要求應用架構能夠最大化不同使用者間的資源共用，不過仍要區分屬於不同客戶的資料。

　　l 可配置性

　　當然，如果我們必須用一台伺服器上的單個應用執行個體滿足多家不同公司的需求，那麼我們就難以針對某個終端使用者的使用體驗編寫定製代碼，因為只要針對某個客戶進行了應用定製，就會改變其他使用者的使用。因此，我們不是在傳統的意義上進行應用定製，而是讓每個客戶用中繼資料配置應用的外觀和行為。

　　SaaS架構師面臨的挑戰在於，如何確保客戶應用配置的簡易性，同時還不必為每項配置支付額外的開發或運營成本。

　　4.2 SaaS軟體平台的四級模型

　　一般來說按照目前業界通行標準，基於SaaS模式的系統可以按照其設計成熟度等級分成以下四種程度，其中每一級與前一級的區別則在於是否引入了前述三大要素中的部分或全部。

　　從廣義上說，我們可採用四級模型來說明SaaS應用的成熟度等級，每一級都比前一級增加了上述三種成熟特性中的一種。

　　

　　圖1 SaaS軟體四級成熟度等級模型

　　1. 第一級 定製

　　第一級成熟度等級類似於上世紀90年代初的ASP(Application Service Provider)所採用的軟體交付模式。這種模式下，軟體服務提供者為每個客戶定製一套應用軟體，並為其部署。每個客戶使用一個獨立的資料庫執行個體和應用伺服器執行個體。資料庫的資料結構和應用代碼可能都根據客戶需求做過定製化修改。這種模式相對傳統軟體，差別僅僅在於商業模式，在應用架構上沒有任何差別。

　　符合這一級成熟度等級的系統，每個客戶擁有一個為其定製的應用執行個體，這一單獨的執行個體運行在SaaS服務提供者的硬體之上。從系統架構而言，這一層級的SaaS系統和傳統的本地安裝軟體非常相似，同一客戶的不同終端使用者使用用戶端軟體串連同一個應用執行個體，但這一客戶執行個體和服務提供者同時啟動並執行其它客戶的應用執行個體相比是完全獨立的。

　　因此，傳統的伺服器-用戶端的應用可以在花費少量開發資源和無需重新設計整個架構的前提被改造成符合這一層級的SaaS模式的系統。雖然相比起其它更為成熟的SaaS模式的系統，這一類型的系統所能給SaaS服務提供者帶來的收益有限，但它確實可以讓SaaS服務提供者通過整合伺服器硬體和管理來降低成本，因此目前有不少國內的軟體廠商就嘗試應用這種手段將其已有的傳統系統改造為相應的SaaS系統。

　　實際上傳統的C/S、B/S軟體在商業模式上做出相應的改變，就符合該模型。這種模式下，對於每個客戶需要為其定製發、單獨部署等等，因此很難達到規模效應。

　　2. 第二級 可配置

　　第二級成熟度等級模型是在第一級的基礎上的改進，也就是針對每個客戶的定製化可以通過配置的方式實現，而不需要通過定製代碼、資料庫結構來實現。這種模式要求軟體開發商在設計應用的時候已經考慮了擴充性，所以針對不同需求的客戶，可以採用靈活的配置來響應。這種模式下每個客戶依然有獨立資料庫執行個體和應用伺服器執行個體，但是每個客戶的執行個體都是相同的版本，通過不同的配置來滿足客戶不同的需求。符合第二級成熟度等級的系統，每個客戶各自擁有一個單獨的應用執行個體，但不同之處在於第一級中的使用者執行個體是根據每個客戶的需求單獨定製的，而在這裡，每個客戶使用相同的代碼。SaaS服務提供者通過詳細的具體配置選項來允許客戶改變自身應用的外觀和系統行為。儘管如此，不同的應用執行個體之間還是保持完全獨立運行。

　　將所有客戶的應用執行個體集中於同一程式碼程式庫之下極大的減少了對於SaaS服務提供者的服務需求，因為此時對系統代碼任何微小的改變都會立刻影響所有的當前客戶，這下也就可以節省為每個客戶的應用執行個體單獨升級或修改的成本。但是相比起第一級的成熟度等級模型，如果試圖將一個傳統的伺服器-用戶端的應用改造成符合第二級成熟度等級的SaaS系統，將需要花費更多的重新架構和開發的成本。

　　最後，同第一級模型有一處類似的是，符合第二級成熟度等級模型的系統一樣需要SaaS服務提供者準備足夠的硬體和儲存空間來支援潛在的大量的同時啟動並執行應用執行個體。

　　這種模式相對第一級成熟度等級模型可以降低定製開發的成本，但是由於其部署、維護還都是獨立的，還是很難達成規模效應。

　　3. 第三級 可配置，高效的多使用者支援

　　第三級的成熟度等級模型就是符合multi-tenancy架構的，multi-tenancy完整的名稱應該是Single Instance Multi Tenancy，也是單一實例多租戶。這級模型下軟體供應商部署一個應用的執行個體即可滿足多個客戶的要求。

　　在第三級的成熟度等級模型中，服務提供者通過運行一個應用執行個體來為所有的客戶服務，同時通過可配置的中繼資料來給每一個客戶提供不同的使用者體驗和功能。可配置的許可權控制和安全性原則則確保了每一個客戶的資料被單獨存放且與其它客戶的資料相隔離。因此，從終端使用者的角度出發，他們將感受不到所使用的應用執行個體也在同一時間為其他客戶所共用。

　　這種方式解決了這樣一個問題，那就是隨著SaaS服務供應商業務的發展和客戶的增多，只能通過提供更多的伺服器資源來運行更多應用執行個體，現在SaaS服務供應商可以用同樣數量的伺服器資源為更多的客戶服務，從而比起前兩級成熟度等級模型的系統，更有效利用了硬體資源，降低了運營成本。

　　但這一架構的不利之處在於無法靈活的提升系統效能，除非使用資料分區技術來提高資料庫的效能，一般來說SaaS服務供應商將只能通過把系統轉移到更為強大的伺服器上來提升效能。

　　在客戶的需求差別不大，客戶數量不是特別大的情況下，將第一級/第二級熟度模型的應用改造成符合multi-tenancy架構的應用並不會太複雜，最常見的改造方案有：

　　1) 增加一個Tenant表(或者類似作用的表，例如企業表、個人表)。

　　2) 在大部分的業務資料表中都要增加TenantID欄位，來唯一標識多租戶。

　　3) 改造登入介面，在登入介面增加一個企業號輸入框，並修改其邏輯代碼，在會話中記錄登入使用者所屬的TenantID，2：

　　

　　圖2 SaaS模式登入介面

　　4) 在業務資料查詢過濾時，都增加上TenantID=?過濾條件。例如初始資料模型如下：

　　

　　圖3 傳統軟體資料模型

　　改造後的資料模型4：

　　

　　圖4 SaaS軟體資料模式

　　經過以上簡單的改造，系統基本上就可以實現multi-tenancy架構。但是要真正較好的達成第三級成熟度等級模型，顯然沒有這麼簡單，這樣簡單的改造將面臨可配置性和效能的雙重挑戰。

　　在multi-tenancy架構下，要實現可配置性，相對第二級成熟度等級模型下實現可配置性，會面臨更大的挑戰，尤其是資料模型的擴充。在單租戶的模型下，一般我們都會通過直接擴充表、擴充欄位來實現資料模型的擴充，而在多租戶的模型下，不同租戶可能有不同的資料模型的擴充需求，採用直接擴充表、擴充欄位的方法變得不太可行。因此在多租戶模型下，更多地通過預留欄位和name-value對的模式實現資料模型的擴充。

　　l 可延伸性模式

　　根據設計，應用自然會包括標準的資料庫設定，帶有與您解決方案屬性相對應的預設表、欄位、查詢以及關係等。但是，不同的企業會有著各自獨特的需求，而僵化的、沒有延伸性的預設資料模型是無法解決這些具體問題的。舉例來說，SaaS職位跟蹤系統(SaaSjob-tracking system)的一個客戶可能需要配合每個記錄儲存外部產生的分類代碼串，以將系統與其他進程全面整合。另一位客戶可能不需要分類字串欄位，但卻要求支援跟蹤整數類型的ID號。因此，在許多情況下，您所開發和實施的方法都應使客戶能延伸預設的資料模型以滿足需要，同時又不會影響其他客戶對資料模型的使用。

　　l 預分配欄位

　　實現資料模型可延伸性的方法很簡單，即在希望實現使用者可延伸性的每個表格中建立一定預設數量的定製欄位。

　　表4-1.帶有一組定製欄位、標記為C1～C3的表格。

　　表4-1 定製欄位

　　

　　在上表中，同一表格中混有不同客戶的記錄;使用者ID欄位將每個記錄與相應的使用者

　　相關聯。除了標準的一組欄位外，我們還提供一系列定製欄位，每個客戶可決定如何使用這些定製欄位，以及如何針對這些定製欄位收集資料。

　　資料類型的問題怎麼解決呢?這也很簡單，您只需為所建立的每個定製欄位選擇一般的資料類型即可，不過客戶可能會覺得這種方法限制性過強。有的客戶可能需要三個額外的字串欄位，而我們可能只提供了一個字串欄位、一個整數欄位以及一個布爾欄位(boolean field)。那怎麼才能實現靈活性呢?

　　一種方法是針對每個定製欄位採用字串資料型別，並使用中繼資料來跟蹤使用者希望使用的“真實”資料類型。圖5.Web頁面上的定製欄位由中繼資料表中的項目定義。

　　

　　圖5 Web頁面上的定製欄位與中繼資料表的關係

　　在上例中，使用者使用了應用的可延伸特性向資料輸入螢幕添加了稱為“寄件人郵遞區號”的文字框，並將該文字框映射至稱為C1的定製欄位。建立文字框時，使用者使用了確認邏輯(此處未顯示)以要求文字框包含的是整數。實施後，這一定製欄位由中繼資料表中的一條記錄來定義，該表包括了使用者唯一的ID號(1017)、使用者為該欄位所選的標記(“寄件人郵遞區號”)，以及使用者希望該欄位使用的資料類型(“整數”)。

　　您可在統一的中繼資料表中跟蹤所有應用的定製欄位的欄位定義，或為每個定製欄位使用不同的表格;例如，“C1”表會定義每個使用C1定製欄位的使用者，“C2”表執行的操作與此相同，如此類推。

　　表4-2 執行關係表

　　

　　表4-3 定義定製欄位表

　　

　　表4-4 執行動作表

　　

　　表4-2在統一的中繼資料表格中儲存欄位定義與在獨立表格中儲存不同的定製欄位。

　　採用獨立表格的主要優勢在於，每個特定欄位表格僅包含使用該欄位的使用者的行，這節約了資料庫的空間。(如果採用統一表格方案，那麼每個至少採用一個定製欄位的使用者都會在統一表中獲得行，儘管使用者實際並未使用空欄位，但其卻會表現為可用的定製欄位。)採用單獨表格的方法也有其弱點，因為它會增加定製欄位操作的複雜性，要求必須採用SQL的JOIN語句來調查單個使用者的所有定製欄位定義。

　　當終端使用者在欄位中輸入數量並儲存記錄時，應用在資料庫中建立或更新記錄前，會將寄件人郵遞區號的值轉換為字串。只要應用檢索記錄，就會檢查中繼資料表中要使用的資料類型，並將定製欄位中的值轉換回原類型。

　　l 名稱值對

　　前面部分介紹的預分配欄位模式是使用者擴充並定製應用資料模型的一種簡單方式。不過，這種方案存在一定的局限性。在給定表格中決定提供多少定製欄位需要進行綜合權衡。如果定製欄位太少，使用者就會感到應用有局限性;如果太多，資料庫又會變得太大，造成浪費，並且很多欄位都得不到利用。在這極端情況下，兩種情況都會發生，有的使用者定製欄位過多，有的使用者則不夠用。

　　避免發生上述局限性的一種方法是使客戶自己能夠對資料模型進行延伸，在獨立的表格中儲存定製資料，並使用中繼資料來定義每個使用者定製欄位的標記和資料類型。

　　

　　圖 4-6. 表格延伸的定製欄位。

　　這時，中繼資料Table Store關於每個使用者定義的各個定製欄位的重要訊息，其中包括欄位名稱(標記)和資料類型。當終端使用者採用定製欄位儲存記錄時，會發生兩件事。第一，記錄本身在主要資料表中被建立或更新;儲存所有預定義欄位的相關值，但不會儲存定製欄位。這時，應用為記錄建立唯一的標識符，在記錄ID欄位中儲存它。第二，在延伸表中建立一個包含下列資訊的新的行：

　　•主要資料表格中與記錄關聯的ID;

　　•與正確定製欄位定義關聯的延伸ID;

　　•將正在被儲存記錄中定製欄位的值轉換成字串。

　　上述方案使每個使用者都能根據需要建立儘可能多的定製欄位，以滿足業務需求。當應用檢索客戶記錄時，會在延伸表中進行尋找，選擇與記錄ID相對應的所有行，並為所用的每個定製欄位返回一個值。

　　為了將這些值與正確的定製欄位相關聯並將其轉換為正確的資料類型，應用會使用延伸表中與每個值關聯的延伸ID在中繼資料中尋找定製欄位資訊。

　　上述方案使使用者能自行決定資料模型的可延伸性，並同時保持了採用共用資料庫的成本優勢。這種方案的主要弱點在於，其會增加諸如索引、查詢以及更新記錄等資料庫功能的複雜程度。如果您希望使用共用資料庫，同時估計客戶在延伸預設的資料模型時要求相當大的靈活性，那麼這種方法通常是最可取的。

　　l 定製列

　　可延伸資料模型的最簡單類型是直接向使用者的表格中添加列的情況。

　　

　　圖7. 專用表格添加定製行。

　　這種模式適合獨立資料庫或獨立架構應用，因為每個使用者都擁有可獨立修改、不影響其他用戶端的表集。從資料模型的角度看，這是三種可延伸模式中最簡單的一種，因為這不需要您分別跟蹤資料延伸。

　　不過，從應用的體繫結構角度看，這種方法可能更難實施，因為其會允許使用者更改表格中列的數量。即便您能使用定製列模式，您也應當考慮能不能採取預分配欄位或名稱值對等其他模式，以減小開發難度，從而使您編寫的應用代碼能夠假定每個表格中的已知欄位數量且固定不變。

　　在multi-tenancy架構下有許多最實踐：

　　l 資料庫很容易成為multi-tenancy架構應用的效能瓶頸，因此可能導致較大資料庫壓力的行為應該盡量避免;如大資料量表關聯，複雜SQL語句，即時的資料統計，Like、or等可能導致資料庫索引不能有效利用的SQL。

　　l 為了保證應用伺服器層能水平擴充，一般要求應用伺服器層做到無狀態(不要使用Session等)，以便有效利用Load Balance裝置進行負載平衡。

　　l 對於頻繁讀取讀取的內容，採用合適的Cache策略提升其效能。

　　l 採用合適的資料庫垂直分割，以分擔資料庫伺服器的壓力。

　　l 採用搜尋引擎來滿足一些大資料量的模糊查詢的需求

　　l 採用定時統計+增量資料的方式，來滿足一些資料統計的需求。

　　第三級成熟度等級模型具備一定的延展性(應用伺服器只要實現無狀態，一般可水平擴充，資料庫伺服器通過資料表的一定程度的垂直分割也能實現一定程度上的擴充)，但是由於其中只有Sing Instance，在使用者數量達到一定規模之後(例如百萬級甚至千萬級)，其集中式的資料庫伺服器、儲存等很容易成為系統效能的瓶頸，這時候依賴於單純的向上擴充(伺服器硬體設定的升級)系統效能提升有限，而且成本很高，這就是第四級成熟度等級模型產生的背景。

　　4. 第四級 可配置，高效的多使用者支援可擴充

　　第四級成熟度等級模型相續第三級成熟度等級模型，系統擴充為multi-tenancy multi- instance，終端使用者首先通過接入Tenant Load Balance層被分配到不同的Instance上，通過多個Instance我們可以實現應用的近似無限水平擴充。要實現第四級成熟度等級模型，最複雜的就是針對原有單個Instance的資料庫伺服器，實現其資料的水平分割。對於multi-tenancy應用而言，最適合的資料水平分割方案即按照Tenant進行拆分，實現按照Tenant進行資料水平分割的方案大致如下：

　　l Tenant獨立放到一個集中式的DB中。

　　l Tenant表增加欄位Data_DB(或者類似名稱)，表明該Tenant的業務資料位元於哪個業務資料庫中(Instance中)。

　　使用者登入時，根據其Tenant將其定位到相應的業務資料庫，後續其業務操作和資料查詢都針對其對應的業務資料庫。

　　在這一級也就是最後一級的成熟度等級模型中，SaaS服務供應商將通過運行一個負載平衡的具備許可權驗證功能的平台來為眾多的客戶同時服務，每個客戶的業務資料將被單獨存放，同時提供使用可配置的中繼資料來為每一個客戶提供其自身需要的獨一無二的使用者體驗。符合這樣一個成熟度等級的SaaS系統將可以輕易支援一個相當大的客戶數目，這是因為在其後台啟動並執行服務和業務執行個體可以在不修改系統架構的基礎上隨著需求動態增加和減少，任何的系統變動和修複可以輕而易舉同時作用於數以千計的客戶環境中，就如同只為單一客戶服務時同樣簡便。

　　應該說將符合第三級成熟度等級模型的軟體切換成符合第四級成熟度等級模型，架構複雜度並不會太大，不過要應用直接去做這件事情，還是有很大的開發工作量。另一方面，也要有開發人員從一開始就得面對這種資料的水平分割，增加了系統的複雜度。另一種更合適的方式，是將這種資料的水平分割方案作為一個橫切面剝離出來，在系統部署的時候在通過配置的方式橫切入系統，這樣就可保證資料水平分割方案對於應用的開發人員完全透明。對於第三級成熟度等級模型的SaaS軟體，可以很容易地通過這樣一個架構實現其向第四級成熟度等級模型的轉變。

　　4.3選擇適合的成熟度等級

　　綜上所述，符合最高的第四級的成熟度等級模型的SaaS系統似乎永遠是SaaS系統設計的終極目標，但實踐證明這並非永遠正確。一般來說，將SaaS系統的成熟度等級看成一個兩頭具同等重要性的槓桿也許更為恰當，槓桿的一頭是獨立(Isolated)的資料和代碼，而另一頭則是共用(Shared)的資料和代碼。

　　

　　圖8 資料分離與隔離的槓桿模型

　　選擇何種程度的成熟度等級模型取決於SaaS服務供應商所支援的商業模式、系統模型和運營需求，以及其它基於客戶業務需求的一些考慮，而且以上各種因素之間往往還會有微妙的聯絡：

　　1. 商業模式

　　獨立的資料模式是否符合財務考量。為了獲得經濟和管理上的好處而採取資料共用往往意味著SaaS服務供應商可以因此節約相當一部分的管理成本。但在有些情況下，客戶可能會對此有不同的需求，比如說，儘管SaaS服務供應商可以保證客戶的機密資料即使與其它客戶的資料存放在一個資料庫內但絕對不會外泄，客戶仍然可能受強有力的法律或文化上的限制，從而抵制或乾脆拒絕使用任何基於多個客戶使用共用服務來訪問同一個應用結構的SaaS軟體服務。當然從商業模式的角度來看更重要的是，一旦計劃運營基於這一商業模式的SaaS系統，SaaS服務供應商必須證明該應用如何能在當前採用的成熟度等級模型基礎上保證業務順利發展且實現盈利。

　　2. 系統模型

　　應用是否能在單一邏輯執行個體下運行，是否能將以前基於案頭或傳統的伺服器-用戶端的應用改造成為基於互連網的SaaS系統，這些需求往往從根本上就與要求單一執行個體和中繼資料為主的SaaS模式開發不相適應。因此基於財務考量，投入相當的人力物力來將當前系統轉換到一個完全符合SaaS成熟度等級模型的系統往往是一個得不償失的選擇。而當您選擇一切重新開始，設計和建造一個基於網路的SaaS應用時，往往會感到擁有更多的自由的開發空間。

　　3. 運營模式

　　SaaS服務提供者如何保證客戶服務條款(SLA：Service Level Agreement)得到執行，如何謹慎的評估包含在已經與客戶簽署的SLA中的諸如系統當機時間、服務選項以及災難恢複等條款，以及如何在當前這樣一個多個獨立客戶共用訪問單一執行個體的SaaS架構下實現這些服務條款永遠SaaS系統運營維護中的一大挑戰。

　　5 小結

　　SaaS模式是個全面與複雜的課題，本章主要從SaaS模式研究的主要內容入手，重點介紹了SaaS模式的軟體平台成熟度等級及其品質管理。

　　通過SaaS模式的軟體平台成熟度等級的研究讓大家瞭解到如何評估SaaS模式下的軟體的品質標準，如何選擇適合的成熟度等級;通過SaaS模式的品質管理的分析，把我們的品質管理浸透到開發與服務的每個環節，讓品質管理無所不在，只有這樣才能開發出客戶最大滿意度的產品，企業才能真正擷取最大的利益。