最近跟幾位產品總監和技術的朋友們聊天，很多認爲SaaS很簡單，無非就是一個按量收費的多用戶租賃模式。
其實真的是這樣嗎？
（no，答案太過於片面~）
why？
SaaS確實是雲計算的一種，確實是按量收費，一般也是採用多用戶租賃模式，這些都是沒毛病。但是說SaaS模式的架構非常簡單，那就只能說大家對SaaS的理解仍然存在於一個表象的層面。要麼就是認爲把一個局域網的東西搬到公網這就是SaaS，要麼就是沒有做過真正SaaS或者所做的SaaS應用只是一種非常低級的模式，甚至根本談不上是雲計算的範疇。
作爲一種雲計算模型，一個典型的SaaS模式首先需要以下三種計算模型支撐：
1）分佈式計算模型
這是最基本的模型，也是後兩種模型的基礎；現在非常火的Hadoop就是分佈式計算模型中一種。
2）分佈式數據存儲和訪問模型
分佈式數據庫訪問和存取模型是SaaS企業應用的基礎。
這種模型也很多，GFS，HFS，TFS都屬於這類，當然一些分佈式數據庫包括阿里的Ocean數據庫也都屬於這一類；對於企業級的應用底層數據節點不採用數據庫當然是可以的，但如果採用數據庫，好處也是非常多的，至少要簡單很多。
用什麼類型的數據庫，這個需要從你SaaS平臺本身的業務進行考慮衡量，主要是從數據分離方式和效率兩個方面。比如對SaaS企業應用來說，採用GreenPlum這類數據庫並不是不可以。特別是牽扯到關聯查詢的時候，對於一個按用戶分離和隔離的企業應用，如果數據節點採用關係數據庫，那麼80%的企業應用的關聯查詢都會落到一個節點中，那麼查詢的效率自然會比較高。如採用分佈式數據庫，一般都很難做到這點——分佈式數據庫處理這類查詢的時候，都需要把數據集中到一個節點進行處理（分佈式數據庫中的A表和B表並不一定在一個數據節點的），雖然可以採用一些策略來減少無效數據的傳輸，但往往效果不大。
觀點：
對於分佈式計算，通用往往代表着效率更低。
Google的GFS設計理念：面向應用設計接口，較受認同。
3）分佈式部署與運維模型
作爲雲計算下的SaaS應用，必須是可以支撐橫向擴展（Scala out)的,而這些節點（包括應用節點和數據節點）的增加和管理完全靠人力去完成，基本是不可能的事情。
因此只要是雲計算模型下的SaaS應用，分佈式部署與運維支撐模型就是必須的：應用程序節點的實時監控，管理和部署，數據節點的實時監控和部署，緩存節點的監控，管理和部署，文件服務器的監控，管理和部署等等。
以上三種模型就構成了SaaS應用的基礎，但SaaS應用又有自己的特殊性，因爲牽扯到商務邏輯、事務處理（高一致性和準確性）以及數據的整理和分離等。
比如，SaaS應用的分佈式數據存儲和訪問往往不能簡單的採用已有的一些開源分佈式系統，或者一些開源的分佈式數據庫系統，因爲在大型的SaaS應用中，數據的分割（分佈的基礎）往往也不能做到單一，而數據的分割又會影響數據訪問的路由策略。這就導致通用型的做法不太適合具體的需求。
是不是光從計算模型上已經感覺到了技術的光環了~~~