SAAS相關技術要點

標籤：

這篇文章本來是我們開發組內部用的一個小文檔。因為我們公司以前沒有做SAAS的經驗，就成立了一個小組做一做這方面的技術前探，我是成員之一。這篇文檔想從宏觀的層面把開發一個SAAS應用所要用到的技術點稍微梳理一下，便於指導後面的技術前探工作。之所以發在這裡，是因為自己相關的研發經驗太缺乏，可能有些技術盲點是自己根本沒能考慮到的，希望園子裡的各位大牛多多指導。

一.聚焦“三頭怪”

  在MS的官方文檔中，把構建一個足夠成熟的SAAS（MS簡單列出了SAAS應用的4級成熟度等級）所面臨的3個主要挑戰：可配置性，可擴充性，多使用者儲存結構設計稱為“three headed monster”。在MS給出的兩個SAAS的demo(分別為LitwareHR和Crab)中，著重解決的也是這三個問題。所以，我們在進行技術前探的時候，也要扣准這三條主線。

1.概念
  SAAS是一個典型的“單一實例多處應用”的軟體類型，這就要求執行個體本身在不同的應用環境下有很強的配置能力。具體說來，需要對以下4個方面提供配置能力：
  （1）程式的外觀。
  （2）工作流程與商務規則。
  （3）資料模型。
  （4）使用者及終端使用者的存取許可權。
  這種自訂的能力應該在易配置性和配置能力兩個方面做好權衡，最優的結果當然是通過最方便的配置手段來實現最複雜的自訂功能，但這並不容易做到，所以有可能我們會需要為一些比較進階的使用者提供基於已有系統的二次開發能力（使用指令碼等）。下面我們就具體來談一下關於可配置性的各個方面。

2.配置的實現基礎：中繼資料（MetaData）
  系統通過配置資料展現不同的外觀和行為，那麼對整個系統來說，配置資料就是系統中的中繼資料。筆者自己也沒有特別研究過中繼資料，僅僅是開發中用過一些xml檔案或者資料庫中的特定表來儲存一些配置資訊，但對於一個成熟的SAAS應用，這種簡單的配置方式可能是不夠的。如何設計出結構靈活、功能強大、相容性好的中繼資料結構，如何在代碼中提供最有效率的中繼資料服務（Metadata Service），如何定義中繼資料的中繼資料（Metadata of metadata），如何保證在中繼資料結構發生變化的時候不影響程式的運行，這一切都需要我們在對中繼資料本身的語義特性和可能的支援人員手段進行過調研之後才能得出。另外，筆者在寫這篇文章的時候，很偶然在網上找到了幾幅關於中繼資料服務層設計的圖片，很有意思：

上面這幅圖的上半部分給出了SAAS參考體繫結構的一個概念性模型，下半部分則給出了對應於體繫結構的每一部分，現有的可能採取的技術手段。我們注意到，中繼資料服務和中繼資料資料結構定義是裡面唯一的盲區。
   下面這個圖是Matias Woloski給出的對各主要配置模組（介面、商務規則、多使用者資料結構、存取控制）提供的中繼資料服務的可能解決方案，也許可以做為我們進一步深入的一個線索。

3.配置的需求基礎：業務共性提取與業務個性分析
  為什麼是所有tenant共用一套代碼？因為所有這些使用者在軟體需求上有共同的需要，在商務程序上有很多共通的地方，他們所有的應用都是在一個比較確定的業務領域（Business Domain）內展開的。我們需要把這個業務領域內的業務需求梳理清楚，然後提供我們的軟體為這個業務領網域服務。既然他們都屬於一個業務領域，那麼我們提供一套可以啟動並執行軟體就行了，為什麼還要提供那麼強的配置能力呢？因為同屬於一個業務領域內的客戶，他們在商務規則的細節上其實有很多不同，業務流完全相同的兩個企業其實是不存在的。另外，每一個企業都在不停的發展變化，業務結構也都在不斷的調整、重整、升級過程中，我們的軟體應該可以在一定的彈性範圍內，支援企業的這種升級。
  所以，研究我們的SAAS軟體所要解決的業務領域特點，找出這個領域目前在橫向範圍內的企業業務間的差異性，以及在可以預見的將來的業務升級要求，其實是實現SAAS軟體最開始的、也是最難的一步。但這一步驟本身和技術的關係可能並沒有那麼大，所涉及的最多也能也就是包含UML在內的眾多領域建模技術。這一部分應該屬於SAAS研究中業務和技術結合、同時業務佔據的比重更大的一部分內容。

4.配置主要內容1：程式外觀的配置
  外觀的配置其實包括的內容很多，但比較核心內容筆者認為是介面元素的多粒度模組化，只有實現了這一點，才有可能讓使用者在多個粒度層級上去定義自己想顯示什麼、以什麼樣的介面風格去顯示。這一點上也一直是筆者認為.Net比較有優勢的地方，因為MS的產品一直在構件化上面表現不俗。僅就Asp.net2.0中，已經有Custom Control,User Control,Web Parts,Theme, Skin, MasterPage等成熟介面技術可以使用；在.Net3.0的WPF(現已更名為SilverLight)中，相信更有很多優秀的模組化介面技術的出現，筆者尚未研究過。這些都需要我們去學習和發現。
  另外，如果我們繼續採用基於瀏覽器的軟體系統，Web程式的“體驗本地化”是必不可少的工作，在這方面AJAX技術已經越來越成熟，MS的AJAX 1.0正式版已經發布。
  我們在學習這些介面技術的時候，不僅要學習它們的使用方式，還要明白它們底層的編譯模型和運行模型，這樣我們才能對每個顯示模組對象執行個體如何以最小的運行成本來完成儘可能多的介面顯示和互動響應功能有充分的把握。

5.配置主要內容2：商務程序的配置 
  所謂商務程序，不知筆者的理解是否正確，其實應該屬於經典的工作流程（workflow）問題。所以這一方面儘管非常重要與複雜，但研究起來重點卻最為突出，無非就是兩個：
  （1）對工作流程方法論的研究。筆者沒作過關於工作流程的開發項目，在這方面暫時沒有發言權，但筆者認為在利用工作流程相關的工具和類庫進行開發之前，應當在方法論上對工作流程有一個比較有度的把握。
  （2）對各種現存的工作流程工具的研究。工作流程是企業開發的重點，相關的產品應該不少，筆者知道的主要工具如下：
      a.WF(Microsoft Workflow Foundation), 這是.Net3.0新增的三大類庫之一，專門用於對工作流程技術的支援。
      b.BPEL(Business Process Execution Language),這是由IBM牽頭搞的一個利用XML來描述業務過程行為的標準，目前在業界也得到了廣泛的支援和應用。當然，BPEL並不完全等同於工作流程，它對人、角色、工作項目等並沒有明確定義，重在刻畫一個基於Web服務的商務程序。
  
6.配置手段的易用性
  一個被廣泛接受的觀點是，易用性可能成為一個SAAS軟體成敗的關鍵。作為SAAS應用的使用者，肯定會關心是不是他的每一個員工都能很容易的使用這個系統，這其實是企業部署SAAS應用的主要成本之一。而在整個系統的操作中，對外觀和業務流的自訂配置很有可能成為最複雜的部分，這部分操作的易用性也將直接影響整個軟體的易用性。
  想增強配置手段的易用性，需要我們多向salesforce這樣的成熟SAAS應用學習取經。  

三.可擴充性及相關技術

1.概念
  應用的可擴充性包含兩個方面的要求：（1）高效地利用應用資源，從而最大限度地提高並行性。（2）當原先的伺服器資源確實無法滿足不斷增加的使用者數量時候，可以很方面的通過向上擴充（提升硬體效能）或橫向擴充（增加硬體數量）來提高整個系統的並發處理能力。可擴充性並不僅僅是SAAS面對的難題，所有基於Internate的大型網路應用隊會面對這樣的挑站，所以網路上相關的資料很多，大多談及大規模公司專屬應用程式的體繫結構設計的主題，都會涉及到對可擴充性問題的討論。筆者自己沒有開發過大型的應用系統，更詳細的知識點需要進一步的學習和瞭解之後才能給出，下面暫時只能簡單列出一些筆者以前接觸過的內容作為可能的技術研究點如下。

2.可擴充性支援技術1：應用的無狀態模式
  我們需要研究如何設計應用，使之運行在無狀態模式下。也就是說，所有必需的使用者和會話資料都儲存在用戶端或分布式存放裝置上，任何應用執行個體都能訪問。無狀態是指每個交易處理都能由任何執行個體來完成，使用者在一次會話中可用眾多不同的執行個體進行交易處理，但使用者本身並不知情。比如我們在做Asp.net開發的時候，如果用Session變數來儲存狀態資訊，因為它需要佔用伺服器資源，當你想增加機器以擴充性能的時候，它們會起阻礙作用，因為Session是與特定機器相關連的。在這方面，也許我們可以參考EJB中的關於無狀態會話Bean，以及其管理器無狀態管理器的實現。其實，internet能發展到今天的規模，跟http這個無狀態的協議應該有很大的關係，而internet的擴充性已經在現實世界中被印證了，所以如果我們能嘗試著去理解整個網際網路的結構特點，也許我們對如何建構一個高可擴充性的大型系統會有更深的瞭解。另外，從SOA的角度來講，提倡的Service一般是Stateless的，給定什麼樣的輸入，就會有對應的確定的輸出。一旦服務有了狀態，就無法方便的使用對象池來減少對象的數量，從而提高了負載。

3.可擴充性支援技術2：大型資料庫的分解、重構技術
  MySpace是一個過億註冊使用者的超大型網站，在三年的發展過程中，它完成了從一個單伺服器到及具擴充性的架構的變化，我想種變化其實對於我們研究如何建立一個可擴充的系統其實有很強的借鑒意義：
（1）最早。兩台Web伺服器，一台資料庫伺服器，和我們目前的結構是完全一樣的。在初期的發展中，MySpace就是通過添加新的web伺服器來提高效能的，直到其資料庫伺服器過載。
（2）50萬使用者。要增加資料庫，這時候面臨著保證資料一致性的問題。在第二代架構中，他們啟用了3個SQL Server資料庫伺服器，一個為主，接受所有的資料提交，並將內容複寫給另外兩個，由它們全力向使用者提供資料。在這個架構中，通過增加輔資料庫伺服器的方法，可以有效應對系統訪問量的增加。
（3）100-200萬使用者。資料庫伺服器開始受制於I/O容量。這時候，把所有業務放到一個DB上看來已經不行了，於是他們對資料庫的架構進行了垂直分割，不同的資料庫伺服器服務於不同類的功能，有的負責登入，有的負責部落格等。另外，但使用者達到200萬的時候，他們啟用了存放區域網路（SAN:Storage Area Network）。按MySpaces的說法，此舉極大提升了系統的效能、正常已耗用時間和可靠性。
（4）300萬。垂直分割不夠用了，畢竟有些資訊（如使用者表）需要在所有DB中共用，維護資料一致性的開銷很大。另外，有一些應用增長太快，其專用DB壓力太大。這時候，需要進行向上擴充(Scale Up:升級伺服器)和向外擴充(Scale Out:加強分布式能力，用大量便宜的伺服器來分擔壓力)的抉擇。為了盡量少改動以前的代碼，他們先考慮了向上擴充，研究了如何使用32CPU的伺服器的問題。但最終，他們還是走上了向外擴充的道路，開始提煉分散式運算架構（這是向外擴充架構必須面臨的問題，大廠商如Google甚至開發了自己的Distributed File System）。這時候，前面被拆分的應用在邏輯上又被整合了起來。並且，使用者以百萬為一組，被分別儲存不同的DB。當然會有一個特殊的DB來控制所有的帳號和密碼，但其功能單一，也就比較容易控制負荷。
（5）1000萬。採用了新型的SAN,更改了SAN和資料庫的綁定方式。在Web伺服器和資料庫伺服器之間加上資料緩衝層---他們說這是一開始就應該做的事情，但他們成長太快，以至於一直沒有實現。
（6）2600萬。採用SQl Server2005，因為支援64位的資料庫可以使用更多記憶體。  
  從MySpace的變化可以看出，隨著使用者量的增加和使用者資料量的積累，資料庫伺服器將日益成為瓶頸。在它成為瓶頸之前，充分做好各種相關的技術準備工作是必須的。

4.可擴充性支援技術3：線程和網路連接等彙集資源的共用（負載平衡）
  將線程、網路連接和資料庫連接等資源集中，這有助於使計算資源極大化，並提高我們預測資源使用的能力。當然，在這些方面，其實IIS和ADO.NET等基礎的資源服務系統已經作了很多相關的考慮，我們做的資源調度應該是基於這些伺服器之上的。我們可以參考.Net對線程池的管理，也可以參考ADO.NET對串連池的管理。另外在進行資源調度和管理的時候，要充分考慮整個網路的拓樸結構，並充分借鑒分布式系統在實現方式特別是資源調度演算法上的一些考慮和特點。
  所以，這裡總的來說強調的是一種負載平衡的概念，而負載平衡除了上面提到的這些軟體方面的手段，可能還包括對一些硬體裝置的認識和選購，特別是對各種負載平衡伺服器的效能和功能的掌握。

5.可擴充性支援技術4：其他
  （1）多級緩衝技術。緩衝，說白了就是用空間換時間。越是並發的系統，越需要仔細考慮緩衝的問題，我們每發現一處可以在多使用者間反覆重用的資料並將其加入緩衝，都有可能使這部分資料的產生效率提高上千倍（如果這個資料可以在上千個使用者間共用的話）。另外，如何提高緩衝的命中率，也是當我們的網站逐漸層大之後，越來越重要的問題。還有，對於memcache這類的比較牛的緩衝解決方案，也許我們也需要深入研究它與我們項目的結合點。
  （2）仔細研究資料庫的鎖定方式，在對資料庫操作的時候，儘可能鎖定小範圍的資料集合。採用既可以實現並發最大化，同時還能使排它鎖定最小化的方式寫入資料庫操作。例如，在執行唯讀操作時，不要鎖定記錄。這些環節看似雖小，其實對整個系統的並發性都有顯著的影響。  

四.多使用者儲存結構設計及相關技術
  一家公司的使用者使用我們的SAAS應用服務存取客戶資訊時，該使用者連線應用程式執行個體同時可能還會為其他幾十家，甚或是數百家公司的使用者提供服務，各使用者之間彼此互不知情。這就要求應用架構能夠最大化不同使用者間的資源共用，不過仍要區分屬於不同客戶的資料。所以，我們在設計儲存結構的時候，一方面要考慮結構本身的可擴充性，一方面還要考慮資料訪問的安全性。

1.資料存取控制
  資料是不是安全，會不會被沒有許可權的人竊取或篡改，這是使用者最關心的，因此也是我們最關心的。安全問題涉及的內容也確實是非常多，筆者這裡試著從幾個方面簡單進行闡述：
（1）過濾：在使用者和資料來源之間加入中介層，給使用者的感覺是資料庫裡只存了自己的資料。
 在這方面，典型的手段是採用視圖。
（2）許可權：採用ACL來限制誰能訪問什麼資料，以及可以對資料作什麼操作。
   在這方面，有一個很關鍵的問題是如何建立一個受信任的串連。比較常見的方式有伺服器類比用戶端使用者的身份（impersonation）去訪問資料；或者伺服器始終以自己的進程身份來訪問資料（受信任的子系統方式），額外的安全都放在應用的內部。前一種方式配置上比較複雜，但安全性較高；後一種方式不需要太多配置，但安全性較低，並且有些資源單靠伺服器處理序本身的存取層級是訪問不到的。我們在開發的時候可能需要混合使用這兩種串連方式。
   另外，有些時候可能需要伺服器以代理的方式來訪問一些其他資源。
（3）認證（Authentication）
  前面幾點說的都是對於某個特定的使用者，系統如何控制他的存取權限（也就是說，都屬於授權/Authorization方面的問題），那麼系統如何知道某個用戶端請求確實是來自某個使用者呢？這就是Authentication要做的工作。單就這一部分，包含的知識也相當多，以Asp.net2.0為例，就有Windows驗證、基於表單的驗證等；單就Windows驗證，又有Kerberos，NTLM等不同的驗證協議，這些驗證協議在對Proxy 伺服器的支援、運行效率上都是有差別的，需要我們學習和掌握。另外，在.Net3.0中，MS在這一塊兒好像又提出了一個新的概念和實現技術，CardSpace。這個技術裡應該是凝結了MS對網路安全的最新思考，筆者覺得應當重點關注（此技術和Active Directory, WCF, Windows Live ID等技術都有很強的相關性）。
  還有，從宏觀上來看，認證的方式分為集中式認證（centralized authentication system）和非集中式認證（decentralized authentication system）兩種，我們需要研究它們之間區別和聯絡，結合起來利用。
（4）加密
  對使用者的敏感性資料進行加密，未授權方及時獲得了這些資料也派不上用場。可以採用對稱或非對稱的密碼編譯演算法。非對稱演算法的保密性好，但處理開銷也大得多。實際操作中，一般是兩種方式混用，即資料採用對稱式加密法，但用非對稱式加密法來加密對稱金鑰。

其實，和安全相關的問題還有很多，比如sql注入，代碼安全等等，這裡就不一一詳述了。

2.可擴充的資料結構
  關於這一部分，MS在其白皮書中的第二章《多使用者資料體繫結構》中已經有了比較詳細的交待，本文中就不再重點介紹。可能採取的資料結構有：（1）獨立資料庫；（2）共用資料庫，不同使用者有不同架構；（3）共用資料庫，共用架構。一共是三種方式，這三種方式的資源使用率越來越高，但在設計上也越來越複雜。所以，也並不是共用的程度越高越好，下面這幅圖說明了如何在資料庫的獨立和共用性上面做以取捨：

對於三種模式中最複雜的“共用資料庫，共用架構”，MS給了兩種建議性的方案：預定義擴充欄位以及名值表。一方面，我們可以參考這些方案實現，另一方面我們也可以思考自己的方案出來。另外，不管資料存放區到底採用哪種方案，都要為資料表以後可能的橫向或縱向切分留下餘地。從資料庫的橫向擴充來看，主要的手段是複製和分組，具體如何去做都需要進一步的研究。

五.SAAS與SOA
  SAAS指的是一種軟體商業模式（特別是營銷模式），而SOA指的是系統的實現（包括已有系統的整合）方式，兩者本不在一個概念層上，但筆者在這裡還是想強調一下兩者之間的關係，特別是SOA的相關技術對SAAS的重要性。因為在SOA身上體現了業務整合、業務敏捷等眾多特性，正是SAAS所需要的。特別是業務敏捷，雖然它強調的是一個企業業務在縱向時間軸上的變化和軟體的應對，而SAAS更強調在同一時間點上同步廠商之間的業務區別，但兩者在技術要求上並無本質區別。
  另外，SOA已經漸漸成為公司專屬應用程式開發的標準，我們的使用者除了採用我們的SAAS軟體，很可能還使用了很多其他的應用系統。為了能讓我們的系統更開放，和其他的周邊系統有更好的互動，一種SOA的思想和技術手段將在我們的開發中必不可少。
  SOA本身也是一個技術集，涵蓋的面非常廣，本文在此就不展開了。

六.其他技術

1.單點登入
  對現代網路應用易用性的基本要求之一，至少在我們系統內部，我們要做到使用者一次登入，即可訪問所有他有權訪問的所有子系統。

2.對SAAS樹狀體繫結構的進一步認識
  SAAS本身是一個從服務提供者到各個企業，從企業到各個部門，從部門到每個終端使用者的樹狀管理結構，這樣的一個結構包含一些可以利用的技術特點：
  （1）安全許可權的繼承性
  系統的授權（Ahthorization）一般都是根據使用者組/角色/Role來進行的，在對授權的管理上，MS提出了一個“佈建網域”的概念。存取控制由佈建網域管理。每個佈建網域根據應用的關係策略繼承上級佈建網域的角色、許可和商務規則，並可在適當的時候對其進行修改、添加和刪除。從概念上來說這是非常合理的，比如一個企業內的部門是一個佈建網域，它的上級佈建網域就是企業，而下級佈建網域可能會具體到每個終端使用者（也可能是部門內的小組）。但具體實現的時候如何去做，還需要我們進一步研究並給出方案。  
  （2）使用者的不同等級
  按MS的文檔，將使用者區分為“使用者”和“終端使用者”。其實這裡的“使用者”指的就是一個單位或組織，不同“使用者”之間的資料至少在邏輯上是互相隔離的。而“使用者”可以為自己企業內部的多個“終端使用者”授權，終端使用者最終能在使用者的控制之下訪問到使用者資料的一個子集。
  這種把使用者分成等級來處理的方式是很有意義的，比如在建立受信任連接的時候，就可以採用使用者類比和非使用者類比兩種方式的結合。對使用者採用類比方式，對終端使用者採用非類比方式。比如在儲存結構設計的時候，可以給使用者單獨建立資料庫。

3.活動目錄
  如果我們所有的資料都取自關聯式資料庫伺服器，那麼可能永遠不需要活動目錄。但有些資源是儲存在檔案系統中的，這就需要活動目錄為我們提供存取服務了。我們需要研究原有的Active Directory技術，以及剛提出的ADAM(Active Directory Application Mode)等技術。

SAAS相關技術要點