基于SaaS模式的進(jìn)銷存實(shí)戰(zhàn)架構(gòu)分析

1、基于saas模式的進(jìn)銷存實(shí)戰(zhàn)架構(gòu)分析作者：邢波濤關(guān)于什么是saas (software as a service ) ，無(wú)論是各大媒體，包括網(wǎng)絡(luò)媒體，還是程序員雜志本身，都已經(jīng)講了很多了（程序員雜志還分別在2007年第10期和2008年第8期，做了兩期關(guān)于saas的專題），我也就不再重復(fù)?；趕aas模式的應(yīng)用還是很豐富的，但是對(duì)企業(yè)管理軟件這個(gè)領(lǐng)域來(lái)講，無(wú)論是美國(guó)的salesforce , 還是國(guó)內(nèi)的八百客，都是從crm做起的。直至現(xiàn)在，基于saas模式的進(jìn)銷存，在技術(shù)架構(gòu)上，都還是處于摸索階段，甚至有人在我的blog上留言，金蝶的友商網(wǎng)只是象征性的推出了用asp.net技術(shù)編寫的第一版，第

2、二版要完全轉(zhuǎn)向java平臺(tái)，從.net平臺(tái)轉(zhuǎn)向java平臺(tái)，那就相當(dāng)于把整個(gè)軟件重新寫了一遍。用友雖然推出了偉庫(kù)網(wǎng)，但是至今尚未看到它的進(jìn)銷存應(yīng)用，只是“網(wǎng)上訂貨”和“租戶營(yíng)銷”兩大功能模塊。進(jìn)銷存對(duì)廣大中小企業(yè)來(lái)講，還是非常有市場(chǎng)的，但是各大軟件廠商，遲遲未推出基于saas模式的穩(wěn)定成熟的進(jìn)銷存軟件，這說(shuō)明什么呢？這說(shuō)明它的確不好做，在技術(shù)架構(gòu)上，的確有很難解決的問(wèn)題。我做了很多年的mis/erp/進(jìn)銷存管理軟件，關(guān)注saas模式也好幾年了，所以我就做了一套基于saas模式的進(jìn)銷存軟件，和大家一起探討一下基于saas模式的進(jìn)銷存軟件的技術(shù)架構(gòu)，就當(dāng)是拋磚引玉，無(wú)知者無(wú)畏吧。一、 saas成熟

3、度模型程序員在第八期，刊登了阿里軟件首席架構(gòu)師趙進(jìn)的文章saas成熟度模型淺析， 他借用frederick和gianpanolo carraro的文章，把saas的成熟度，從低到高分成4個(gè)級(jí)別：第一，每個(gè)租戶使用一個(gè)獨(dú)立的數(shù)據(jù)庫(kù)實(shí)例和應(yīng)用服務(wù)器實(shí)例，數(shù)據(jù)庫(kù)中的數(shù)據(jù)結(jié)構(gòu)和應(yīng)用程序的代碼根據(jù)租戶需求，訂制化修改。第二，每個(gè)租戶依然使用一個(gè)獨(dú)立的數(shù)據(jù)庫(kù)實(shí)例和應(yīng)用服務(wù)器實(shí)例，但是應(yīng)用程序已經(jīng)考慮到了可擴(kuò)展性，針對(duì)每個(gè)租戶的可定制化通過(guò)配置的方式實(shí)現(xiàn)，它是一套應(yīng)用程序。第三，單實(shí)例，多租戶，所有租戶共享一個(gè)數(shù)據(jù)庫(kù)實(shí)例和一個(gè)應(yīng)用服務(wù)器實(shí)例，數(shù)據(jù)庫(kù)通過(guò)增加tenant表和tenant_id字段來(lái)解決識(shí)別租戶

4、的問(wèn)題。這時(shí)也是一套應(yīng)用程序。第四，多實(shí)例，多租戶，這時(shí)有多個(gè)應(yīng)用服務(wù)器實(shí)例，最終租戶通過(guò)負(fù)載均衡被分配到不同的應(yīng)用服務(wù)器實(shí)例，并且該租戶攜帶某個(gè)業(yè)務(wù)數(shù)據(jù)庫(kù)實(shí)例信息，由應(yīng)用服務(wù)器動(dòng)態(tài)鏈接到相應(yīng)得業(yè)務(wù)數(shù)據(jù)庫(kù)。此時(shí)也是一套應(yīng)用程序。二、 技術(shù)架構(gòu)設(shè)計(jì)目標(biāo)由上面分析可以看出，從理論上saas已經(jīng)有了一套完整的成熟度模型，所以基于saas模式的應(yīng)用，還是蠻豐富的。但是由于進(jìn)銷存軟件的需求，完全不同于crm軟件和財(cái)務(wù)軟件，相對(duì)于財(cái)務(wù)軟件，國(guó)家有著明確的法律規(guī)范，而進(jìn)銷存系統(tǒng)是個(gè)性化非常強(qiáng)的一個(gè)系統(tǒng)，要求所有的租戶采用同一個(gè)用戶界面和同一個(gè)業(yè)務(wù)邏輯，是不現(xiàn)實(shí)的。對(duì)于進(jìn)銷存這塊來(lái)說(shuō)，租戶有強(qiáng)烈的個(gè)性化需求的

5、意愿。所以，本著這個(gè)思想，應(yīng)用層的設(shè)計(jì)要求能夠做到以下兩點(diǎn)：（1）所有的租戶理論上均可以自定義自己的頁(yè)面（2）所有的租戶理論上均可以自定義自己的業(yè)務(wù)邏輯這個(gè)目標(biāo)和saas模型成熟度的第一類是類似的，但是我們要支持多實(shí)例，多租戶，并且是一套程序，一個(gè)framwork。也就是說(shuō)我們既要實(shí)現(xiàn)saas模型成熟度第一類的目標(biāo)，又要實(shí)現(xiàn)第四類的技術(shù)架構(gòu)。下面我從數(shù)據(jù)庫(kù)層到業(yè)務(wù)邏輯層，再到視圖層，詳細(xì)講解我是如何做的，其系統(tǒng)架構(gòu)圖如圖一所示。(圖一)三、 數(shù)據(jù)庫(kù)層的設(shè)計(jì) 數(shù)據(jù)庫(kù)這一層的設(shè)計(jì)模式，無(wú)外乎只有3種方案：（1）每個(gè)租戶獨(dú)立一個(gè)數(shù)據(jù)庫(kù)： 在應(yīng)用服務(wù)器中配制不同的數(shù)據(jù)源，或者使用不同的連接池。這個(gè)方案

6、的優(yōu)點(diǎn)是不同租戶的數(shù)據(jù)物理分離，安全性比較好。它的缺點(diǎn)是數(shù)據(jù)庫(kù)連接的利用效率不高。性能問(wèn)題會(huì)很大。它對(duì)應(yīng)saas模型成熟度第一類和第一類。（2）所有租戶的數(shù)據(jù)都存放在一個(gè)數(shù)據(jù)庫(kù)的同一套表中， 增加tenant表和tenant_id字段，表明該業(yè)務(wù)數(shù)據(jù)是屬于哪個(gè)租戶的。它的優(yōu)缺點(diǎn)在趙進(jìn)的那篇文章saas成熟度模型淺析也已經(jīng)講了很清晰了。它對(duì)應(yīng)saas模型成熟度第三類。(3) 多schema，單數(shù)據(jù)源。這個(gè)方案基本是方案（1）的變種。同一個(gè)數(shù)據(jù)庫(kù)下可以有多個(gè)schema。它的優(yōu)點(diǎn)是除了方案（1）的優(yōu)點(diǎn)以外，它共享數(shù)據(jù)源或連接池，效率更高。缺點(diǎn)是和方案(2)比較起來(lái)，數(shù)據(jù)庫(kù)連接池開(kāi)銷會(huì)比較大 說(shuō)實(shí)話

7、，我不太確認(rèn)這個(gè)模式是不是對(duì)應(yīng)saas模型成熟度第(4)類, 如果是的話，那么數(shù)據(jù)庫(kù)之間的負(fù)載均衡是沒(méi)有意義的，因?yàn)槊總€(gè)數(shù)據(jù)庫(kù)之間的數(shù)據(jù)根本不一樣（不包括備份數(shù)據(jù)庫(kù)）。如果不是的話，那么saas模型成熟度第(4)類數(shù)據(jù)庫(kù)是如何劃分的呢？趙進(jìn)也沒(méi)有講清楚，或者是我自己沒(méi)有看明白。 具體到我的設(shè)計(jì)，這里我選擇方案（3）,并結(jié)合了方案（2），對(duì)于登陸/驗(yàn)證/權(quán)限，所有的租戶共享一個(gè)schema,而對(duì)于業(yè)務(wù)數(shù)據(jù)，則每個(gè)租戶的業(yè)務(wù)數(shù)據(jù)，是獨(dú)立一個(gè)schema。這樣，每個(gè)租戶的業(yè)務(wù)數(shù)據(jù)達(dá)到了物理分離，安全性比較好，導(dǎo)入導(dǎo)出也很方便。四、 應(yīng)用層的設(shè)計(jì) 前面咱們說(shuō)過(guò)，進(jìn)銷存程序不同于別的應(yīng)用程序，進(jìn)銷存應(yīng)用

8、程序有強(qiáng)烈的個(gè)性化需求，應(yīng)用層的設(shè)計(jì)要求能夠做到以下兩點(diǎn)：（1）所有的租戶理論上均可以自定義自己的頁(yè)面（2）所有的租戶理論上均可以自定義自己的業(yè)務(wù)邏輯下面我說(shuō)說(shuō)我是如何做到以上兩點(diǎn)的：要做到以上兩點(diǎn)，只能有一套代碼，一個(gè)framework才算成功，如果針對(duì)不同的用戶界面和用戶邏輯需求，framework也需要變動(dòng)的話，那就是項(xiàng)目性質(zhì)了，也就是saas模型成熟度第一類的目標(biāo)。（1）所有的租戶理論上均可以自定義自己的頁(yè)面我這里也是采用了mvc的架構(gòu)，參考了struts 的源代碼，并重新寫了一個(gè)web framework，使之能適應(yīng)saas架構(gòu)的需求。上篇咱們說(shuō)過(guò)，對(duì)數(shù)據(jù)庫(kù)這一層，我采用的是方案3，

9、每個(gè)租戶有自己獨(dú)立的一個(gè)schema,但所有的租戶，在菜單、角色、權(quán)限方面，他們采用了同一個(gè)公共的schema,也就是說(shuō)，用戶的登陸驗(yàn)證和對(duì)應(yīng)的菜單，是在這個(gè)公共的schema里面實(shí)現(xiàn)的。缺省的，這些租戶共享這些菜單，每個(gè)菜單對(duì)應(yīng)一個(gè)action,每個(gè)action對(duì)應(yīng)一個(gè)view, 這一點(diǎn)，是采用了struts的思想。對(duì)于租戶的個(gè)性需求，如果有的租戶的界面跟其余租戶的界面不同，則新增一個(gè)菜單（登陸的時(shí)候，會(huì)覆蓋掉原來(lái)的同一個(gè)menu_id的菜單），這個(gè)菜單當(dāng)然有一個(gè)字段compamy_id,表明這個(gè)菜單是這個(gè)租戶所獨(dú)有的，在登陸的時(shí)候，把這個(gè)菜單加載到界面上，而這個(gè)菜單對(duì)應(yīng)了一個(gè)新的actio

10、n,這個(gè)新的action對(duì)應(yīng)了一個(gè)新的view層，這樣就實(shí)現(xiàn)了不同租戶，可以有自己完全不同的界面的需求。下面談?wù)劦?個(gè)目標(biāo)： 所有的客戶理論上均可以自定義自己的業(yè)務(wù)邏輯在這里，我采用了eclipse插件的思想(本人的現(xiàn)本職工作是eclipse插件tooling 工具開(kāi)發(fā))，所有和業(yè)務(wù)層相關(guān)的業(yè)務(wù)邏輯代碼，按照業(yè)務(wù)功能模塊分類，我都放在配置文件里，動(dòng)態(tài)加載，還是回到那個(gè)menu-action-view , 這個(gè)action不僅對(duì)應(yīng)一個(gè)view層，還對(duì)應(yīng)一個(gè)業(yè)務(wù)邏輯，通過(guò)不同的租戶，配置不同的菜單， 這些菜單又對(duì)應(yīng)不同的action,這些action又對(duì)應(yīng)不同的業(yè)務(wù)邏輯，并且是動(dòng)態(tài)加載的，這樣，就

11、做到了業(yè)務(wù)邏輯和framework的分離。例如，有的客戶的應(yīng)付款和采購(gòu)入庫(kù)對(duì)應(yīng)上，入庫(kù)了，才會(huì)形成應(yīng)付款，而有的客戶，可能跟采購(gòu)訂單對(duì)應(yīng)上，只要下了采購(gòu)訂單，就會(huì)形成應(yīng)付款，等等這些，無(wú)論客戶的需求怎么變化，這個(gè)framework是不變的，當(dāng)然，形成應(yīng)收應(yīng)付的業(yè)務(wù)邏輯代碼還是要自己寫的。五、 視圖層的選擇對(duì)于view這一層，我選擇了flex，我之所以沒(méi)有采用jsp+ajax,是因?yàn)榧虞dajax框架，比如ext,可能也是很浪費(fèi)時(shí)間的，造成加載速度很慢。可擴(kuò)展性和可持續(xù)發(fā)展性也沒(méi)flex好，而且，flex天生長(zhǎng)著一張?bào)@艷的臉，會(huì)給用戶帶來(lái)很好的ui體驗(yàn)，借用別人的一句話：“乍一看，很唬人”。在fl

12、ex框架選擇上，我沒(méi)有采用flex流行的framewok, 比如modelglueflex/cairngorm/flex fds/puremvc/blazeds等等f(wàn)ramework,我直接自己寫了一個(gè)，感覺(jué)還是很好用的，增加、修改、查詢、刪除等等基本操作，基本上做到自動(dòng)化了，不用寫什么代碼了。學(xué)習(xí)這些framework的曲線都比較陡，要沉下心，不容易啊。如果fds不要錢，我還是推薦fds。 flex最大的不方便是客戶端的flash容器和服務(wù)器端的tomcat等容器，根本就是兩碼事，兩者之間也可以說(shuō)沒(méi)有任何關(guān)系，就像ie跟tomcat 沒(méi)有任何關(guān)系一樣，所以在 flash容器內(nèi)，找到sessi

13、on,還是不容易的，當(dāng)然也有一些framework，例如blazeds似乎解決了這個(gè)問(wèn)題，我沒(méi)有仔細(xì)看，網(wǎng)上也有一些文章，說(shuō)解決了這個(gè)問(wèn)題，我看了看，都不是很方便的解決方案。拿不到session,還是蠻不方便的。對(duì)于菜單，我還是用了jsp。因?yàn)椴藛我鶕?jù)每個(gè)客戶的不同權(quán)限，顯示不同的菜單，我在flex里面沒(méi)有解決好session的問(wèn)題，所以沒(méi)有用flex做菜單。六、關(guān)于o/r mapping工具的的選擇關(guān)于o/r mapping工具，我并沒(méi)有采用流行的hibernate。saas模式進(jìn)銷存的第一個(gè)目標(biāo)是允許用戶自定義自己的界面，界面的不同，也就意味著數(shù)據(jù)庫(kù)字段的不同，而hibernate要求數(shù)

14、據(jù)庫(kù)字段和hibernate類嚴(yán)格一一對(duì)應(yīng)，我個(gè)人覺(jué)得它不適合saas模式的業(yè)務(wù)架構(gòu)。當(dāng)然也許有hibernate的高人能夠解決這個(gè)問(wèn)題，我對(duì)hibernate僅僅是一知半解。我采用的是apache tuscany das(/das-overview.html), das 雖然犧牲了oo特性，用了類似于hashmap的東西，但是它的靈活架構(gòu)，還是很適合saas這種模式的。不過(guò)，在緩存上，tuscany das肯定沒(méi)有hibernate那么成熟，而且，tuscany das還有一個(gè)問(wèn)題是它更新比較慢，不像tuscany sca/sdo更新那么快，就

15、好像不是一個(gè)娘生的。tuscany das 目前的版本還有一個(gè)很大的bug,就是double數(shù)據(jù)類型存盤有問(wèn)題，我看他們現(xiàn)在也沒(méi)修改過(guò)來(lái)。我自己更改了它的sdodatatypehelper類的源代碼，修改了它的bug。七、關(guān)于soa/sca關(guān)于sca,在寫這個(gè)進(jìn)銷存的第一版的時(shí)候，所有service和service之間的調(diào)用，我都是基于sca實(shí)現(xiàn)的。后來(lái)出于性能的考慮，以及這些source codes和service全是我自己控制的，就把所有有關(guān)sca的調(diào)用全去掉了，service和service之間修改為直接調(diào)用。再后來(lái)，想想這些租戶之間，很可能有很強(qiáng)的業(yè)務(wù)協(xié)同需求。而這些租戶之間的service,也可能分布在不同的機(jī)器上，所以再次更新版本的時(shí)候，又加入了一些service和service之間的動(dòng)態(tài)調(diào)用，而這些動(dòng)態(tài)調(diào)用的service之間，就是用sca來(lái)整合到一起了。八、開(kāi)發(fā)后記：在開(kāi)發(fā)過(guò)程當(dāng)中，我參考了很多framework，總是感覺(jué)和自己想要得差距很大，與其整合別人的fram