最近做SaaS應(yīng)用的很多，這種模式是未來的一種趨勢，這種模式的***好處就是云計算的好處--節(jié)約資源。網(wǎng)上有很多人覺得SaaS很簡單，就是一個多用戶租賃模式。這種認(rèn)識也不能說不對，因為SaaS確實一般都采用多用戶租賃模式。但這種說法非常的不全面，是一種盲人摸象。而且很多人認(rèn)為SaaS 模式的架構(gòu)非常簡單，那就只能說他沒有真正做過SaaS模式或者他們做的SaaS應(yīng)用是一種非常低級的模式，根本談不上是云計算的范疇，就是一個把局域網(wǎng)的東西放到了公網(wǎng)而已。

作為一種云計算模型，一個典型的SaaS模式需要以下三種計算模型支撐：

1)分布式計算模型

這是基本的模型，也是后兩種模型的基礎(chǔ);現(xiàn)在非常火的Hadoop其實只是分布式計算模型中一種，而且并不是特別的復(fù)雜;

2)分布式數(shù)據(jù)存儲和訪問模型

這種模型很多，GFS，HFS，TFS都屬于這類，當(dāng)然一些分布式數(shù)據(jù)庫包括阿里的Ocean數(shù)據(jù)庫都屬于這一類;分布式數(shù)據(jù)庫訪問和存取模型是SaaS 企業(yè)應(yīng)用的基礎(chǔ)，對于企業(yè)級的應(yīng)用底層數(shù)據(jù)節(jié)點不采用數(shù)據(jù)庫當(dāng)然是可以的，但如果采用數(shù)據(jù)庫，好處也是非常多的，至少要簡單很多。現(xiàn)有的分布式數(shù)據(jù)庫對于 SaaS應(yīng)用，特別是SaaS企業(yè)應(yīng)用來說采用GreenPlum這類數(shù)據(jù)庫并不是不可以，但需要根據(jù)你的SaaS應(yīng)用的業(yè)務(wù)本身進(jìn)行權(quán)衡(主要是數(shù)據(jù)分離方式和效率的問題)。特別是牽扯到關(guān)聯(lián)查詢的時候，對于一個按用戶分離和隔離的企業(yè)應(yīng)用，如果數(shù)據(jù)節(jié)點采用關(guān)系數(shù)據(jù)庫，那么80%的企業(yè)應(yīng)用的關(guān)聯(lián)查詢都會落到一個節(jié)點中，查詢的效率會比較高。如果采用分布式數(shù)據(jù)庫，一般都很難做到這點，因為分布式數(shù)據(jù)庫處理這類查詢的時候，都需要把數(shù)據(jù)集中到一個節(jié)點進(jìn)行處理，雖然可以采用一些策略來減少無效數(shù)據(jù)的傳輸，但往往效果不大。(分布式數(shù)據(jù)庫中的A表和B表并不一定在一個數(shù)據(jù)節(jié)點的)，這也是我一直以來的觀點：對于分布式計算，通用往往代表著效率更低。我比較認(rèn)同Google的GFS設(shè)計理念：面向應(yīng)用設(shè)計接口。

3)分布式部署與運維模型

作為云計算下的SaaS應(yīng)用，必須是可以支撐橫向擴(kuò)展(Scala out)的,而這些節(jié)點(包括應(yīng)用節(jié)點和數(shù)據(jù)節(jié)點)的增加和管理完全靠人力去完成，基本是不可能的事情，因此只要是云計算模型下的SaaS應(yīng)用，分布式部署與運維支撐模型就是必須的：應(yīng)用程序節(jié)點的實時監(jiān)控，管理和部署，數(shù)據(jù)節(jié)點的實時監(jiān)控和部署，緩存節(jié)點的監(jiān)控，管理和部署，文件服務(wù)器的監(jiān)控，管理和部署等等。

以上三種模型就構(gòu)成了SaaS應(yīng)用的基礎(chǔ)，但SaaS應(yīng)用又有自己的特殊性，因為牽扯到商務(wù)邏輯、事務(wù)處理(高一致性和準(zhǔn)確性)以及數(shù)據(jù)的整理和分離等，SaaS應(yīng)用的分布式數(shù)據(jù)存儲和訪問往往不能簡單的采用已有的一些開源分布式系統(tǒng)，或者一些開源的分布式數(shù)據(jù)庫系統(tǒng)，因為在大型的 SaaS應(yīng)用中，數(shù)據(jù)的分割(分布的基礎(chǔ))往往也不能做到單一，而數(shù)據(jù)的分割又會影響數(shù)據(jù)訪問的路由策略。這就導(dǎo)致通用型的做法不太適合具體的需求。

SaaS 的這種基礎(chǔ)實際上就已經(jīng)非常具有技術(shù)含量了，而SaaS業(yè)務(wù)應(yīng)用本身，在邏輯上就更難了，并不是訪問數(shù)據(jù)庫加上一個隔離字段那么簡單。一般SaaS系統(tǒng)除了基本的多用戶租賃(注意，設(shè)計SaaS的時候一定要以軟隔離為基礎(chǔ)，這樣可以做到***化的自由，而且不會影響數(shù)據(jù)庫隔離和數(shù)據(jù)庫實例隔離的需求 )還會牽扯到在線許可，多時區(qū)，多語言，以及功能、頁面、流程的可配置。特別是更深層次的應(yīng)用更會涉及到在線跨企業(yè)資源共享和流程協(xié)作的問題，處理這類問題會非常棘手。特別是SaaS在線企業(yè)級應(yīng)用，你需要面對的問題會更加復(fù)雜(業(yè)務(wù)規(guī)則的分與合)。如果在做架構(gòu)的時候，如果沒有考慮到這些問題，后面的噩夢會很多。甚至你可能玩不轉(zhuǎn)。

SaaS應(yīng)用其實并不簡單，哪怕就是一個CRM在線應(yīng)用，也是非常具有業(yè)務(wù)和技術(shù)含量的。根據(jù)我的分析，紛享銷客和銷售易雖然融了不少的資，但他們的系統(tǒng)架構(gòu)還算不上真正意義下的云計算模式下的SaaS。金蝶，用友，速達(dá)的在線應(yīng)用雖然沒有深入研究，但通過他們用戶的一些反饋，我感覺60%的可能性是偽云計算SaaS應(yīng)用。當(dāng)然，如果知道內(nèi)幕的，可以告訴我。

SaaS企業(yè)應(yīng)用涉及的點非常多，而且很多點之間是有關(guān)聯(lián)的，因此你必須在這些問題點的處理中不斷地進(jìn)行平衡，進(jìn)行取舍。比如，采用面向服務(wù)(SOA)的架構(gòu)，在一定程度上是可以減少一些復(fù)雜性，但這樣一來也降低了應(yīng)用系統(tǒng)的整體性，SOA的粒度和邊界的劃分就是非常重要的權(quán)衡點。

在進(jìn)行企業(yè)SaaS應(yīng)用架構(gòu)的時候，***先弄清以下幾個點：

1) 數(shù)據(jù)隔離和數(shù)據(jù)分布的路由策略;

2) 需要做哪些業(yè)務(wù)，是否需要做用戶間進(jìn)行資源共享和流程協(xié)作;

3) 如果需要資源共享和協(xié)作，那么這個過程中的用戶數(shù)據(jù)歸屬問題;

4) 企業(yè)數(shù)據(jù)的規(guī)范性和統(tǒng)一性問題(這會涉及到參照，統(tǒng)計等后續(xù)一系列問題點);

......

很多企業(yè)喜歡利用面試的方式來偷師，用處其實并不是很大，SaaS應(yīng)用的單個問題點都并不是很復(fù)雜，關(guān)鍵在于這些點放到一起的時候，你如何根據(jù)你自己的業(yè)務(wù)進(jìn)行取舍才是關(guān)鍵，而這種東西，靠拉再多的人來面試都是解決不了問題的，原因非常簡單：不懂的人跟你講，你會被誤導(dǎo)，而真正懂的人給你講的也未必適合于你的應(yīng)用，如果你結(jié)合你的問題去問別人，別人也未必是hellokitty。

博文出處：http://blog.csdn.net/hawksoft/article/details/47305821