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

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. 表格延伸的定製字段。

　　這時，元數據表格存儲關於每一個用戶定義的各個定製字段的重要信息，其中包括字段名稱(標記)和數據類型。當最終用戶採用定製字段保存記錄時，會發生兩件事。第一，記錄自己在主要數據表中被建立或更新;保存全部預約義字段的相關值，但不會保存定製字段。這時，應用爲記錄建立惟一的標識符，在記錄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模式的質量管理的分析，把咱們的質量管理浸透到開發與服務的每一個環節，讓質量管理無所不在，只有這樣才能開發出客戶最大滿意度的產品，企業才能真正獲取最大的利益。