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