這篇文章本來是我們開發(fā)組內部用的一個小文檔。因為我們公司以前沒有做SAAS的經驗，就成立了一個小組做一做這方面的技術前探，我是成員之一。這篇文檔想從宏觀的層面把開發(fā)一個SAAS應用所要用到的技術點稍微梳理一下，便于指導后面的技術前探工作。之所以發(fā)在這里，是因為自己相關的研發(fā)經驗太缺乏，可能有些技術盲點是自己根本沒能考慮到的，希望園子里的各位大牛多多指導。
一.聚焦“三頭怪”
在MS的官方文檔中，把構建一個足夠成熟的SAAS(MS簡單列出了SAAS應用的4級成熟度)所面臨的3個主要挑戰(zhàn)：可配置性，可擴展性，多用戶存儲結構設計稱為“three headed monster”。在MS給出的兩個SAAS的demo(分別為LitwareHR和Crab)中，著重解決的也是這三個問題。所以，我們在進行技術前探的時候，也要扣準這三條主線。
1.概念
SAAS是一個典型的“單實例多處應用”的軟件類型，這就要求實例本身在不同的應用環(huán)境下有很強的配置能力。具體說來，需要對以下4個方面提供配置能力：
(1)程序的外觀。
(2)工作流程與業(yè)務規(guī)則。
(3)數(shù)據(jù)模型。
(4)用戶及最終用戶的存取權限。
這種自定義的能力應該在易配置性和配置能力兩個方面做好權衡，最優(yōu)的結果當然是通過最方便的配置手段來實現(xiàn)最復雜的自定義功能，但這并不容易做到，所以有可能我們會需要為一些比較高級的用戶提供基于已有系統(tǒng)的二次開發(fā)能力(使用腳本等)。下面我們就具體來談一下關于可配置性的各個方面。
2.配置的實現(xiàn)基礎：元數(shù)據(jù)(MetaData)
系統(tǒng)通過配置數(shù)據(jù)展現(xiàn)不同的外觀和行為，那么對整個系統(tǒng)來說，配置數(shù)據(jù)就是系統(tǒng)中的元數(shù)據(jù)。筆者自己也沒有特別研究過元數(shù)據(jù)，僅僅是開發(fā)中用過一些xml文件或者數(shù)據(jù)庫中的特定表來保存一些配置信息，但對于一個成熟的SAAS應用，這種簡單的配置方式可能是不夠的。如何設計出結構靈活、功能強大、兼容性好的元數(shù)據(jù)結構，如何在代碼中提供最有效率的元數(shù)據(jù)服務(Metadata Service)，如何定義元數(shù)據(jù)的元數(shù)據(jù)(Metadata of metadata)，如何保證在元數(shù)據(jù)結構發(fā)生變化的時候不影響程序的運行，這一切都需要我們在對元數(shù)據(jù)本身的語義特性和可能的技術支持手段進行過調研之后才能得出。另外，筆者在寫這篇文章的時候，很偶然在網(wǎng)上找到了幾幅關于元數(shù)據(jù)服務層設計的圖片，很有意思：
上面這幅圖的上半部分給出了SAAS參考體系結構的一個概念模型，下半部分則給出了對應于體系結構的每一部分，現(xiàn)有的可能采取的技術手段。我們注意到，元數(shù)據(jù)服務和元數(shù)據(jù)數(shù)據(jù)結構定義是里面唯一的盲區(qū)。
下面這個圖是Matias Woloski給出的對各主要配置模塊(界面、業(yè)務規(guī)則、多用戶數(shù)據(jù)結構、訪問控制)提供的元數(shù)據(jù)服務的可能解決方案，也許可以做為我們進一步深入的一個線索。
3.配置的需求基礎：業(yè)務共性提取與業(yè)務個性分析
為什么是所有tenant共享一套代碼？因為所有這些用戶在軟件需求上有共同的需要，在業(yè)務流程上有很多共通的地方，他們所有的應用都是在一個比較確定的業(yè)務領域(Business Domain)內展開的。我們需要把這個業(yè)務領域內的業(yè)務需求梳理清楚，然后提供我們的軟件為這個業(yè)務領域服務。既然他們都屬于一個業(yè)務領域，那么我們提供一套可以運行的軟件就行了，為什么還要提供那么強的配置能力呢？因為同屬于一個業(yè)務領域內的客戶，他們在業(yè)務規(guī)則的細節(jié)上其實有很多不同，業(yè)務流完全相同的兩個企業(yè)其實是不存在的。另外，每一個企業(yè)都在不停的發(fā)展變化，業(yè)務結構也都在不斷的調整、重整、升級過程中，我們的軟件應該可以在一定的彈性范圍內，支持企業(yè)的這種升級。
所以，研究我們的SAAS軟件所要解決的業(yè)務領域特點，找出這個領域目前在橫向范圍內的企業(yè)業(yè)務間的差異性，以及在可以預見的將來的業(yè)務升級要求，其實是實現(xiàn)SAAS軟件最開始的、也是最難的一步。但這一步驟本身和技術的關系可能并沒有那么大，所涉及的最多也能也就是包含UML在內的眾多領域建模技術。這一部分應該屬于SAAS研究中業(yè)務和技術結合、同時業(yè)務占據(jù)的比重更大的一部分內容。
4.配置主要內容1：程序外觀的配置
外觀的配置其實包括的內容很多，但比較核心內容筆者認為是界面元素的多粒度模塊化，只有實現(xiàn)了這一點，才有可能讓用戶在多個粒度級別上去定義自己想顯示什么、以什么樣的界面風格去顯示。這一點上也一直是筆者認為.Net比較有優(yōu)勢的地方，因為MS的產品一直在構件化上面表現(xiàn)不俗。僅就Asp.net2.0中，已經有Custom Control,User Control,Web Parts,Theme, Skin, MasterPage等成熟界面技術可以使用;在.Net3.0的WPF(現(xiàn)已更名為SilverLight)中，相信更有很多優(yōu)秀的模塊化界面技術的出現(xiàn)，筆者尚未研究過。這些都需要我們去學習和發(fā)現(xiàn)。
另外，如果我們繼續(xù)采用基于瀏覽器的軟件系統(tǒng)，Web程序的“體驗本地化”是必不可少的工作，在這方面AJAX技術已經越來越成熟，MS的AJAX 1.0正式版已經發(fā)布。
我們在學習這些界面技術的時候，不僅要學習它們的使用方式，還要明白它們底層的編譯模型和運行模型，這樣我們才能對每個顯示模塊對象實例如何以最小的運行成本來完成盡可能多的界面顯示和交互響應功能有充分的把握。
5.配置主要內容2：業(yè)務流程的配置
所謂業(yè)務流程，不知筆者的理解是否正確，其實應該屬于經典的工作流(workflow)問題。所以這一方面盡管非常重要與復雜，但研究起來重點卻最為突出，無非就是兩個：
(1)對工作流方法論的研究。筆者沒作過關于工作流的開發(fā)項目，在這方面暫時沒有發(fā)言權，但筆者認為在利用工作流相關的工具和類庫進行開發(fā)之前，應當在方法論上對工作流有一個比較有度的把握。
(2)對各種現(xiàn)存的工作流工具的研究。工作流是企業(yè)開發(fā)的重點，相關的產品應該不少，筆者知道的主要工具如下：
a.WF(Microsoft Workflow Foundation), 這是.Net3.0新增的三大類庫之一，專門用于對工作流技術的支持。
b.BPEL(Business Process Execution Language),這是由IBM牽頭搞的一個利用XML來描述業(yè)務過程行為的標準，目前在業(yè)界也得到了廣泛的支持和應用。當然，BPEL并不完全等同于工作流，它對人、角色、工作項目等并沒有明確定義，重在刻畫一個基于Web服務的業(yè)務流程。
6.配置手段的易用性
一個被廣泛接受的觀點是，易用性可能成為一個SAAS軟件成敗的關鍵。作為SAAS應用的使用者，肯定會關心是不是他的每一個員工都能很容易的使用這個系統(tǒng)，這其實是企業(yè)部署SAAS應用的主要成本之一。而在整個系統(tǒng)的操作中，對外觀和業(yè)務流的自定義配置很有可能成為最復雜的部分，這部分操作的易用性也將直接影響整個軟件的易用性。
想增強配置手段的易用性，需要我們多向salesforce這樣的成熟SAAS應用學習取經。
三.可擴展性及相關技術
1.概念
應用的可擴展性包含兩個方面的要求：(1)高效地利用應用資源，從而最大限度地提高并行性。(2)當原先的服務器資源確實無法滿足不斷增加的用戶數(shù)量時候，可以很方面的通過向上擴展(提升硬件性能)或橫向擴展(增加硬件數(shù)量)來提高整個系統(tǒng)的并發(fā)處理能力?？蓴U展性并不僅僅是SAAS面對的難題，所有基于Internate的大型網(wǎng)絡應用隊會面對這樣的挑站，所以網(wǎng)絡上相關的資料很多，大多談及大規(guī)模企業(yè)應用的體系結構設計的主題，都會涉及到對可擴展性問題的討論。筆者自己沒有開發(fā)過大型的應用系統(tǒng)，更詳細的知識點需要進一步的學習和了解之后才能給出，下面暫時只能簡單列出一些筆者以前接觸過的內容作為可能的技術研究點如下。
2.可擴展性支持技術1：應用的無狀態(tài)模式
我們需要研究如何設計應用，使之運行在無狀態(tài)模式下。也就是說，所有必需的用戶和會話數(shù)據(jù)都存儲在客戶端或分布式存儲設備上，任何應用實例都能訪問。無狀態(tài)是指每個事務處理都能由任何實例來完成，用戶在一次會話中可用眾多不同的實例進行事務處理，但用戶本身并不知情。比如我們在做Asp.net開發(fā)的時候，如果用Session變量來存儲狀態(tài)信息，因為它需要占用服務器資源，當你想增加機器以擴展性能的時候，它們會起阻礙作用，因為Session是與特定機器相關連的。在這方面，也許我們可以參考EJB中的關于無狀態(tài)會話Bean，以及其管理器無狀態(tài)管理器的實現(xiàn)。其實，internet能發(fā)展到今天的規(guī)模，跟http這個無狀態(tài)的協(xié)議應該有很大的關系，而internet的擴展性已經在現(xiàn)實世界中被印證了，所以如果我們能嘗試著去理解整個因特網(wǎng)的結構特點，也許我們對如何建構一個高可擴展性的大型系統(tǒng)會有更深的了解。另外，從SOA的角度來講，提倡的Service一般是Stateless的，給定什么樣的輸入，就會有對應的確定的輸出。一旦服務有了狀態(tài)，就無法方便的使用對象池來減少對象的數(shù)量，從而提高了負載。
3.可擴展性支持技術2：大型數(shù)據(jù)庫的分解、重構技術
MySpace是一個過億注冊用戶的超大型網(wǎng)站，在三年的發(fā)展過程中，它完成了從一個單服務器到及具擴展性的架構的變化，我想種變化其實對于我們研究如何建立一個可擴展的系統(tǒng)其實有很強的借鑒意義：
(1)最早。兩臺Web服務器，一臺數(shù)據(jù)庫服務器，和我們目前的結構是完全一樣的。在初期的發(fā)展中，MySpace就是通過添加新的web服務器來提高性能的，直到其數(shù)據(jù)庫服務器過載。
(2)50萬用戶。要增加數(shù)據(jù)庫，這時候面臨著保證數(shù)據(jù)一致性的問題。在第二代架構中，他們啟用了3個SQL Server數(shù)據(jù)庫服務器，一個為主，接受所有的數(shù)據(jù)提交，并將內容復制給另外兩個，由它們全力向用戶提供數(shù)據(jù)。在這個架構中，通過增加輔數(shù)據(jù)庫服務器的方法，可以有效應對系統(tǒng)訪問量的增加。
(3)100-200萬用戶。數(shù)據(jù)庫服務器開始受制于I/O容量。這時候，把所有業(yè)務放到一個DB上看來已經不行了，于是他們對數(shù)據(jù)庫的架構進行了垂直分割，不同的數(shù)據(jù)庫服務器服務于不同類的功能，有的負責登錄，有的負責博客等。另外，但用戶達到200萬的時候，他們啟用了存儲區(qū)域網(wǎng)絡(SAN:Storage Area Network)。按MySpaces的說法，此舉極大提升了系統(tǒng)的性能、正常運行時間和可靠性。
(4)300萬。垂直分割不夠用了，畢竟有些信息(如用戶表)需要在所有DB中共享，維護數(shù)據(jù)一致性的開銷很大。另外，有一些應用增長太快，其專用DB壓力太大。這時候，需要進行向上擴展(Scale Up:升級服務器)和向外擴展(Scale Out:加強分布式能力，用大量便宜的服務器來分擔壓力)的抉擇。為了盡量少改動以前的代碼，他們先考慮了向上擴展，研究了如何使用32CPU的服務器的問題。但最終，他們還是走上了向外擴展的道路，開始提煉分布式計算架構(這是向外擴展架構必須面臨的問題，大廠商如Google甚至開發(fā)了自己的分布式文件系統(tǒng))。這時候，前面被拆分的應用在邏輯上又被整合了起來。并且，用戶以百萬為一組，被分別存儲不同的DB。當然會有一個特殊的DB來控制所有的帳號和密碼，但其功能單一，也就比較容易控制負荷。
(5)1000萬。采用了新型的SAN,更改了SAN和數(shù)據(jù)庫的綁定方式。在Web服務器和數(shù)據(jù)庫服務器之間加上數(shù)據(jù)緩存層---他們說這是一開始就應該做的事情，但他們成長太快，以至于一直沒有實現(xiàn)。
(6)2600萬。采用SQl Server2005，因為支持64位的數(shù)據(jù)庫可以使用更多內存。
從MySpace的變化可以看出，隨著用戶量的增加和用戶數(shù)據(jù)量的積累，數(shù)據(jù)庫服務器將日益成為瓶頸。在它成為瓶頸之前，充分做好各種相關的技術準備工作是必須的。
4.可擴展性支持技術3：線程和網(wǎng)絡連接等匯集資源的共享(負載均衡)
將線程、網(wǎng)絡連接和數(shù)據(jù)庫連接等資源集中，這有助于使計算資源最大化，并提高我們預測資源使用的能力。當然，在這些方面，其實IIS和ADO.NET等基礎的資源服務系統(tǒng)已經作了很多相關的考慮，我們做的資源調度應該是基于這些服務器之上的。我們可以參考.Net對線程池的管理，也可以參考ADO.NET對連接池的管理。另外在進行資源調度和管理的時候，要充分考慮整個網(wǎng)絡的拓樸結構，并充分借鑒分布式系統(tǒng)在實現(xiàn)方式特別是資源調度算法上的一些考慮和特點。
所以，這里總的來說強調的是一種負載均衡的概念，而負載均衡除了上面提到的這些軟件方面的手段，可能還包括對一些硬件設備的認識和選購，特別是對各種負載均衡服務器的性能和功能的掌握。
5.可擴展性支持技術4：其他
(1)多級緩存技術。緩存，說白了就是用空間換時間。越是并發(fā)的系統(tǒng)，越需要仔細考慮緩存的問題，我們每發(fā)現(xiàn)一處可以在多用戶間反復重用的數(shù)據(jù)并將其加入緩存，都有可能使這部分數(shù)據(jù)的生成效率提高上千倍(如果這個數(shù)據(jù)可以在上千個用戶間共享的話)。另外，如何提高緩存的命中率，也是當我們的網(wǎng)站逐漸變大之后，越來越重要的問題。還有，對于memcache這類的比較牛的緩存解決方案，也許我們也需要深入研究它與我們項目的結合點。
(2)仔細研究數(shù)據(jù)庫的鎖定方式，在對數(shù)據(jù)庫操作的時候，盡可能鎖定小范圍的數(shù)據(jù)集合。采用既可以實現(xiàn)并發(fā)最大化，同時還能使排它鎖定最小化的方式寫入數(shù)據(jù)庫操作。例如，在執(zhí)行只讀操作時，不要鎖定記錄。這些環(huán)節(jié)看似雖小，其實對整個系統(tǒng)的并發(fā)性都有顯著的影響。
四.多用戶存儲結構設計及相關技術
一家公司的用戶使用我們的SAAS應用服務存取客戶信息時，該用戶連接的應用實例同時可能還會為其他幾十家，甚或是數(shù)百家公司的用戶提供服務，各用戶之間彼此互不知情。這就要求應用架構能夠最大化不同用戶間的資源共享，不過仍要區(qū)分屬于不同客戶的數(shù)據(jù)。所以，我們在設計存儲結構的時候，一方面要考慮結構本身的可擴展性，一方面還要考慮數(shù)據(jù)訪問的安全性。
1.數(shù)據(jù)訪問控制
數(shù)據(jù)是不是安全，會不會被沒有權限的人竊取或篡改，這是用戶最關心的，因此也是我們最關心的。安全問題涉及的內容也確實是非常多，筆者這里試著從幾個方面簡單進行闡述：
(1)過濾：在用戶和數(shù)據(jù)源之間加入中間層，給用戶的感覺是數(shù)據(jù)庫里只存了自己的數(shù)據(jù)。
在這方面，典型的手段是采用視圖。
(2)權限：采用ACL來限制誰能訪問什么數(shù)據(jù)，以及可以對數(shù)據(jù)作什么操作。
在這方面，有一個很關鍵的問題是如何建立一個受信任的連接。比較常見的方式有服務器模擬客戶端用戶的身份(impersonation)去訪問數(shù)據(jù);或者服務器始終以自己的進程身份來訪問數(shù)據(jù)(受信任的子系統(tǒng)方式)，額外的安全都放在應用的內部。前一種方式配置上比較復雜，但安全性較高;后一種方式不需要太多配置，但安全性較低，并且有些資源單靠服務器進程本身的訪問級別是訪問不到的。我們在開發(fā)的時候可能需要混合使用這兩種連接方式。
另外，有些時候可能需要服務器以代理的方式來訪問一些其他資源。
(3)認證(Authentication)
前面幾點說的都是對于某個特定的用戶，系統(tǒng)如何控制他的訪問權限(也就是說，都屬于授權/Authorization方面的問題)，那么系統(tǒng)如何知道某個客戶端請求確實是來自某個用戶呢？這就是Authentication要做的工作。單就這一部分，包含的知識也相當多，以Asp.net2.0為例，就有Windows驗證、基于表單的驗證等;單就Windows驗證，又有Kerberos，NTLM等不同的驗證協(xié)議，這些驗證協(xié)議在對代理服務器的支持、運行效率上都是有差別的，需要我們學習和掌握。另外，在.Net3.0中，MS在這一塊兒好像又提出了一個新的概念和實現(xiàn)技術，CardSpace。這個技術里應該是凝結了MS對網(wǎng)絡安全的最新思考，筆者覺得應當重點關注(此技術和Active Directory, WCF, Windows Live ID等技術都有很強的相關性)。
還有，從宏觀上來看，認證的方式分為集中式認證(centralized authentication system)和非集中式認證(decentralized authentication system)兩種，我們需要研究它們之間區(qū)別和聯(lián)系，結合起來利用。
(4)加密
對用戶的敏感數(shù)據(jù)進行加密，未授權方及時獲得了這些數(shù)據(jù)也派不上用場。可以采用對稱或非對稱的加密算法。非對稱算法的保密性好，但處理開銷也大得多。實際操作中，一般是兩種方式混用，即數(shù)據(jù)采用對稱加密法，但用非對稱加密法來加密對稱密鑰。
其實，和安全相關的問題還有很多，比如sql注入，代碼安全等等，這里就不一一詳述了。
2.可擴展的數(shù)據(jù)結構
關于這一部分，MS在其白皮書中的第二章《多用戶數(shù)據(jù)體系結構》中已經有了比較詳細的交待，本文中就不再重點介紹?？赡懿扇〉臄?shù)據(jù)結構有：(1)獨立數(shù)據(jù)庫;(2)共享數(shù)據(jù)庫，不同用戶有不同架構;(3)共享數(shù)據(jù)庫，共享架構。一共是三種方式，這三種方式的資源利用率越來越高，但在設計上也越來越復雜。所以，也并不是共享的程度越高越好，下面這幅圖說明了如何在數(shù)據(jù)庫的獨立和共享性上面做以取舍：
對于三種模式中最復雜的“共享數(shù)據(jù)庫，共享架構”，MS給了兩種建議性的方案：預定義擴展字段以及名值表。一方面，我們可以參考這些方案實現(xiàn)，另一方面我們也可以思考自己的方案出來。另外，不管數(shù)據(jù)存儲到底采用哪種方案，都要為數(shù)據(jù)表以后可能的橫向或縱向切分留下余地。從數(shù)據(jù)庫的橫向擴展來看，主要的手段是復制和分組，具體如何去做都需要進一步的研究。
五.SAAS與SOA
SAAS指的是一種軟件商業(yè)模式(特別是營銷模式)，而SOA指的是系統(tǒng)的實現(xiàn)(包括已有系統(tǒng)的整合)方式，兩者本不在一個概念層上，但筆者在這里還是想強調一下兩者之間的關系，特別是SOA的相關技術對SAAS的重要性。因為在SOA身上體現(xiàn)了業(yè)務整合、業(yè)務敏捷等眾多特性，正是SAAS所需要的。特別是業(yè)務敏捷，雖然它強調的是一個企業(yè)業(yè)務在縱向時間軸上的變化和軟件的應對，而SAAS更強調在同一時間點上同步廠商之間的業(yè)務區(qū)別，但兩者在技術要求上并無本質區(qū)別。
另外，SOA已經漸漸成為企業(yè)應用開發(fā)的標準，我們的用戶除了采用我們的SAAS軟件，很可能還使用了很多其他的應用系統(tǒng)。為了能讓我們的系統(tǒng)更開放，和其他的周邊系統(tǒng)有更好的交互，一種SOA的思想和技術手段將在我們的開發(fā)中必不可少。
SOA本身也是一個技術集，涵蓋的面非常廣，本文在此就不展開了。
六.其他技術
1.單點登錄
對現(xiàn)代網(wǎng)絡應用易用性的基本要求之一，至少在我們系統(tǒng)內部，我們要做到用戶一次登錄，即可訪問所有他有權訪問的所有子系統(tǒng)。
2.對SAAS樹狀體系結構的進一步認識
SAAS本身是一個從服務提供商到各個企業(yè)，從企業(yè)到各個部門，從部門到每個最終用戶的樹狀管理結構，這樣的一個結構包含一些可以利用的技術特點：
(1)安全權限的繼承性
系統(tǒng)的授權(Ahthorization)一般都是根據(jù)用戶組/角色/Role來進行的，在對授權的管理上，MS提出了一個“配置域”的概念。存取控制由配置域管理。每個配置域根據(jù)應用的關系策略繼承上級配置域的角色、許可和商務規(guī)則，并可在適當?shù)臅r候對其進行修改、添加和刪除。從概念上來說這是非常合理的，比如一個企業(yè)內的部門是一個配置域，它的上級配置域就是企業(yè)，而下級配置域可能會具體到每個最終用戶(也可能是部門內的小組)。但具體實現(xiàn)的時候如何去做，還需要我們進一步研究并給出方案。
(2)用戶的不同等級
按MS的文檔，將用戶區(qū)分為“用戶”和“最終用戶”。其實這里的“用戶”指的就是一個單位或組織，不同“用戶”之間的數(shù)據(jù)至少在邏輯上是互相隔離的。而“用戶”可以為自己企業(yè)內部的多個“最終用戶”授權，最終用戶最終能在用戶的控制之下訪問到用戶數(shù)據(jù)的一個子集。
這種把用戶分成等級來處理的方式是很有意義的，比如在建立受信任連接的時候，就可以采用用戶模擬和非用戶模擬兩種方式的結合。對用戶采用模擬方式，對最終用戶采用非模擬方式。比如在存儲結構設計的時候，可以給用戶單獨建立數(shù)據(jù)庫。
3.活動目錄
如果我們所有的數(shù)據(jù)都取自關系數(shù)據(jù)庫服務器，那么可能永遠不需要活動目錄。但有些資源是存儲在文件系統(tǒng)中的，這就需要活動目錄為我們提供存取服務了。我們需要研究原有的Active Directory技術，以及剛提出的ADAM(Active Directory Application Mode)等技術。
