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

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

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

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

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

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

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

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

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

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

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

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

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

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

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