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甚至開發了本身的分佈式文件系統）。這時候，前面被拆分的應用在邏輯上又被整合了起來。而且，用戶以百萬爲一組，被分別存儲不一樣的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等不一樣的驗證協議，這些驗證協議在對代理服務器的支持、運行效率上都是有差異的，須要咱們學習和掌握。另外，在.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)等技術。