最近做SaaS應用的很多,這種模式是未來的一種趨勢,這種模式的最大好處就是云計算的好處--節(jié)約資源。網上有很多人覺得SaaS很簡單,就是一個多用戶租賃模式。這種認識也不能說不對,因為SaaS確實一般都采用多用戶租賃模式。但這種說法非常的不全面,是一種盲人摸象。而且很多人認為SaaS 模式的架構非常簡單,那就只能說他沒有真正做過SaaS模式或者他們做的SaaS應用是一種非常低級的模式,根本談不上是云計算的范疇,就是一個把局域網的東西放到了公網而已。
作為一種云計算模型,一個典型的SaaS模式需要以下三種計算模型支撐:
1)分布式計算模型
這是基本的模型,也是后兩種模型的基礎;現在非?;鸬腍adoop其實只是分布式計算模型中一種,而且并不是特別的復雜;
2)分布式數據存儲和訪問模型
這種模型很多,GFS,HFS,TFS都屬于這類,當然一些分布式數據庫包括阿里的Ocean數據庫都屬于這一類;分布式數據庫訪問和存取模型是SaaS 企業(yè)應用的基礎,對于企業(yè)級的應用底層數據節(jié)點不采用數據庫當然是可以的,但如果采用數據庫,好處也是非常多的,至少要簡單很多?,F有的分布式數據庫對于 SaaS應用,特別是SaaS企業(yè)應用來說采用GreenPlum這類數據庫并不是不可以,但需要根據你的SaaS應用的業(yè)務本身進行權衡(主要是數據分離方式和效率的問題)。特別是牽扯到關聯查詢的時候,對于一個按用戶分離和隔離的企業(yè)應用,如果數據節(jié)點采用關系數據庫,那么80%的企業(yè)應用的關聯查詢都會落到一個節(jié)點中,查詢的效率會比較高。如果采用分布式數據庫,一般都很難做到這點,因為分布式數據庫處理這類查詢的時候,都需要把數據集中到一個節(jié)點進行處理,雖然可以采用一些策略來減少無效數據的傳輸,但往往效果不大。(分布式數據庫中的A表和B表并不一定在一個數據節(jié)點的),這也是我一直以來的觀點:對于分布式計算,通用往往代表著效率更低。我比較認同Google的GFS設計理念:面向應用設計接口。
3)分布式部署與運維模型
作為云計算下的SaaS應用,必須是可以支撐橫向擴展(Scala out)的,而這些節(jié)點(包括應用節(jié)點和數據節(jié)點)的增加和管理完全靠人力去完成,基本是不可能的事情,因此只要是云計算模型下的SaaS應用,分布式部署與運維支撐模型就是必須的:應用程序節(jié)點的實時監(jiān)控,管理和部署,數據節(jié)點的實時監(jiān)控和部署,緩存節(jié)點的監(jiān)控,管理和部署,文件服務器的監(jiān)控,管理和部署等等。
以上三種模型就構成了SaaS應用的基礎,但SaaS應用又有自己的特殊性,因為牽扯到商務邏輯、事務處理(高一致性和準確性)以及數據的整理和分離等,SaaS應用的分布式數據存儲和訪問往往不能簡單的采用已有的一些開源分布式系統(tǒng),或者一些開源的分布式數據庫系統(tǒng),因為在大型的 SaaS應用中,數據的分割(分布的基礎)往往也不能做到單一,而數據的分割又會影響數據訪問的路由策略。這就導致通用型的做法不太適合具體的需求。
SaaS 的這種基礎實際上就已經非常具有技術含量了,而SaaS業(yè)務應用本身,在邏輯上就更難了,并不是訪問數據庫加上一個隔離字段那么簡單。一般SaaS系統(tǒng)除了基本的多用戶租賃(注意,設計SaaS的時候一定要以軟隔離為基礎,這樣可以做到最大化的自由,而且不會影響數據庫隔離和數據庫實例隔離的需求 )還會牽扯到在線許可,多時區(qū),多語言,以及功能、頁面、流程的可配置。特別是更深層次的應用更會涉及到在線跨企業(yè)資源共享和流程協(xié)作的問題,處理這類問題會非常棘手。特別是SaaS在線企業(yè)級應用,你需要面對的問題會更加復雜(業(yè)務規(guī)則的分與合)。如果在做架構的時候,如果沒有考慮到這些問題,后面的噩夢會很多。甚至你可能玩不轉。
SaaS應用其實并不簡單,哪怕就是一個CRM在線應用,也是非常具有業(yè)務和技術含量的。根據我的分析,紛享銷客和銷售易雖然融了不少的資,但他們的系統(tǒng)架構還算不上真正意義下的云計算模式下的SaaS。金蝶,用友,速達的在線應用雖然沒有深入研究,但通過他們用戶的一些反饋,我感覺60%的可能性是偽云計算SaaS應用。當然,如果知道內幕的,可以告訴我。
SaaS企業(yè)應用涉及的點非常多,而且很多點之間是有關聯的,因此你必須在這些問題點的處理中不斷地進行平衡,進行取舍。比如,采用面向服務(SOA)的架構,在一定程度上是可以減少一些復雜性,但這樣一來也降低了應用系統(tǒng)的整體性,SOA的粒度和邊界的劃分就是非常重要的權衡點。
在進行企業(yè)SaaS應用架構的時候,最好先弄清以下幾個點:
1) 數據隔離和數據分布的路由策略;
2) 需要做哪些業(yè)務,是否需要做用戶間進行資源共享和流程協(xié)作;
3) 如果需要資源共享和協(xié)作,那么這個過程中的用戶數據歸屬問題;
4) 企業(yè)數據的規(guī)范性和統(tǒng)一性問題(這會涉及到參照,統(tǒng)計等后續(xù)一系列問題點);
......
很多企業(yè)喜歡利用面試的方式來偷師,用處其實并不是很大,SaaS應用的單個問題點都并不是很復雜,關鍵在于這些點放到一起的時候,你如何根據你自己的業(yè)務進行取舍才是關鍵,而這種東西,靠拉再多的人來面試都是解決不了問題的,原因非常簡單:不懂的人跟你講,你會被誤導,而真正懂的人給你講的也未必適合于你的應用,如果你結合你的問題去問別人,別人也未必是hellokitty。