沒(méi)有標(biāo)準(zhǔn)并不等同于SaaS不能被用戶(hù)接受。我們可以從某些常見(jiàn)的應(yīng)用中以點(diǎn)帶面，看一看SaaS服務(wù)應(yīng)該具有什么樣的標(biāo)準(zhǔn)。我們今天以企業(yè)用戶(hù)常用的CRM系統(tǒng)，來(lái)看一看標(biāo)準(zhǔn)的SaaS CRM應(yīng)該是一個(gè)什么樣子。

　　實(shí)際上，很多用戶(hù)對(duì)于CRM并不陌生，早在2000年的時(shí)候，有一些企業(yè)就已經(jīng)開(kāi)始嘗試CRM系統(tǒng)。在很多人眼中，CRM就是一套C/S或者B/S的應(yīng)用系統(tǒng)。而當(dāng)CRM進(jìn)入了SaaS，他在架構(gòu)上會(huì)是一個(gè)什么樣子呢?采用企業(yè)級(jí)的多層次、多應(yīng)用的系統(tǒng)結(jié)構(gòu)的SaaS在線(xiàn)CRM平臺(tái)。平臺(tái)架構(gòu)從大的層次上來(lái)分主要為四層，根據(jù)調(diào)用關(guān)系依次為應(yīng)用層、緩沖層、服務(wù)層以及存儲(chǔ)層。

　　應(yīng)用層

　　從瀏覽器發(fā)送過(guò)來(lái)的請(qǐng)求，直接由應(yīng)用層來(lái)進(jìn)行直接響應(yīng);平臺(tái)是多租賃用戶(hù)的在線(xiàn)多應(yīng)用來(lái)實(shí)現(xiàn)的，由于每個(gè)用戶(hù)的具體業(yè)務(wù)需求不同，因此每個(gè)租賃用戶(hù)的應(yīng)用是相互隔離的，但應(yīng)用層的結(jié)構(gòu)卻都是相同，從上到下主要分為業(yè)務(wù)展現(xiàn)層、業(yè)務(wù)邏輯層、業(yè)務(wù)模型層、實(shí)體訪(fǎng)問(wèn)層;業(yè)務(wù)展現(xiàn)層主要為用戶(hù)數(shù)據(jù)的不同視圖表現(xiàn)，為用戶(hù)呈現(xiàn)各種易于瀏覽、便于理解的各種數(shù)據(jù)表現(xiàn)方式，如表單、表格、報(bào)表、圖表等;業(yè)務(wù)邏輯層主要是業(yè)務(wù)邏輯的具體實(shí)現(xiàn)層，對(duì)于用戶(hù)動(dòng)作、觸發(fā)事件以及工作流程等由業(yè)務(wù)邏輯層來(lái)實(shí)現(xiàn)業(yè)務(wù)的處理以及響應(yīng)，通過(guò)業(yè)務(wù)邏輯層對(duì)下層業(yè)務(wù)模型的訪(fǎng)問(wèn)來(lái)實(shí)現(xiàn)具體的邏輯處理;業(yè)務(wù)模型層主要是業(yè)務(wù)對(duì)象的具體定義與封裝，是對(duì)于現(xiàn)實(shí)中業(yè)務(wù)在平臺(tái)中的最直接的映射;實(shí)體訪(fǎng)問(wèn)層是對(duì)于業(yè)務(wù)邏輯層對(duì)于業(yè)務(wù)模型操作的封裝，業(yè)務(wù)模型的實(shí)體狀態(tài)的更新、刪除、查詢(xún)等都是通過(guò)實(shí)體訪(fǎng)問(wèn)層來(lái)實(shí)現(xiàn)。

　　緩沖層

　　緩沖層主要對(duì)于靜態(tài)資源以及動(dòng)態(tài)數(shù)據(jù)的緩存。靜態(tài)資源主要是指應(yīng)用層中展現(xiàn)層中所要使用到的靜態(tài)資源文件，以及由用戶(hù)在業(yè)務(wù)操作中產(chǎn)生的文件等，如圖片、上傳的文件等;而動(dòng)態(tài)數(shù)據(jù)是指用戶(hù)在使用平臺(tái)的過(guò)程中所產(chǎn)生的業(yè)務(wù)數(shù)據(jù)，在實(shí)現(xiàn)業(yè)務(wù)中，這部分?jǐn)?shù)據(jù)大部分都是讀操作比較多，而寫(xiě)操作比較少，因此可以針對(duì)這部分?jǐn)?shù)據(jù)根據(jù)特定的緩存失效策略機(jī)制來(lái)進(jìn)行相應(yīng)的緩存;緩沖層的緩存針對(duì)應(yīng)用層是透明的，而且針對(duì)多應(yīng)用也是透明的，因此緩沖層具有更大的彈性與靈活性。

　　服務(wù)層

　　服務(wù)主要是指平臺(tái)的核心服務(wù)，核心服務(wù)分為業(yè)務(wù)共通服務(wù)以及平臺(tái)共通服務(wù)，平臺(tái)共通服務(wù)是指與業(yè)務(wù)無(wú)關(guān)且是平臺(tái)最基礎(chǔ)的服務(wù)，如任務(wù)調(diào)度、消息隊(duì)列、郵件服務(wù)、圖片處理、工作流引擎等;而業(yè)務(wù)共通服務(wù)指基于平臺(tái)共通服務(wù)，而對(duì)于所有業(yè)務(wù)具有共通性的服務(wù)，如日志審核、操作回滾、數(shù)據(jù)安全、全文檢索、權(quán)限角色等;服務(wù)層是對(duì)于平臺(tái)運(yùn)營(yíng)、維護(hù)最核心的服務(wù)實(shí)現(xiàn)，是平臺(tái)正常運(yùn)行的基礎(chǔ)。

　　存儲(chǔ)層

　　存儲(chǔ)主要分為兩部分：分布式文件存儲(chǔ)以及分布式的數(shù)據(jù)存儲(chǔ);由于是多應(yīng)用的平臺(tái)，因此隨著平臺(tái)的運(yùn)營(yíng)，會(huì)產(chǎn)生海量的業(yè)務(wù)數(shù)據(jù)以及資源文件，因此伴隨著海量的數(shù)據(jù)而來(lái)的問(wèn)題就是存儲(chǔ)、檢索、分析以及統(tǒng)計(jì)等問(wèn)題;針對(duì)上述問(wèn)題，361CRM平臺(tái)采用了分布式的存儲(chǔ)系統(tǒng)，基于Map-Reduce來(lái)進(jìn)行相應(yīng)的檢索、分析以及統(tǒng)計(jì)，實(shí)現(xiàn)了對(duì)于海量數(shù)據(jù)的統(tǒng)一操作。

　　這種結(jié)構(gòu)能做到真正的分布式網(wǎng)絡(luò)計(jì)算，有效降低網(wǎng)絡(luò)流量，減輕客戶(hù)端負(fù)擔(dān)，還能安全、方便地與互聯(lián)網(wǎng)接口。另外公司員工或客戶(hù)分布或行走于全國(guó)各地，通常都有移動(dòng)辦公需求。

　　REST 架構(gòu)

　　REST是基于HTTP的，因此天生就有在互聯(lián)網(wǎng)上穿透防火墻的能力，REST可以簡(jiǎn)單地認(rèn)為它是輕量級(jí)的WebService，但是它具有自己的一些顯著特點(diǎn)：所有的資源通過(guò)統(tǒng)一的接口訪(fǎng)問(wèn)(HTTP/HTTPSGET、POST、PUT、ELETE)，而且接口比較統(tǒng)一，便于與第三方的集成;因?yàn)槭腔贖TTP/HTTPS的，因此可以將資源(響應(yīng))分為可緩存的和不可緩存的，以及采用瀏覽器的標(biāo)準(zhǔn)壓縮方式，有效地提升網(wǎng)絡(luò)效能。也可以在客戶(hù)和資源之間插入不同的中間組件來(lái)提升性能和安全等，如，代理服務(wù)，緩存服務(wù)，網(wǎng)關(guān)服務(wù)等;因?yàn)槭腔贖TTP/HTTPS的資源請(qǐng)求，因此本次連接和下一次到服務(wù)器的連接之間沒(méi)有狀態(tài)。由于361CRM平臺(tái)采用了REST架構(gòu)，因此也就決定了361CRM平臺(tái)天然就具備以下幾方面的優(yōu)勢(shì)：

　　由于REST本身無(wú)狀態(tài)的特性，361CRM平臺(tái)天然就是分布式的，決定了后臺(tái)通過(guò)根據(jù)業(yè)務(wù)量而彈性地增加服務(wù)器就可以實(shí)現(xiàn)平臺(tái)計(jì)算能力的線(xiàn)性增加;所有的請(qǐng)求都是統(tǒng)一通過(guò)RESTAPI進(jìn)行相應(yīng)的資源與服務(wù)的請(qǐng)求，這樣就能夠保證系統(tǒng)提供的服務(wù)都是解耦的，極大的簡(jiǎn)化了系統(tǒng)，從而改善了系統(tǒng)的交互性和可重用性，同時(shí)也能夠根據(jù)業(yè)務(wù)進(jìn)行相應(yīng)統(tǒng)一且透明的內(nèi)存緩存;客戶(hù)端瀏覽器能夠輕松通過(guò)Ajax實(shí)現(xiàn)REST資源的異步調(diào)用處理，同時(shí)也可以有效地減少應(yīng)用服務(wù)器地壓力;通過(guò)提供開(kāi)放的RESTAPI，能夠輕松實(shí)現(xiàn)與第三方的集成。

　　平臺(tái)服務(wù)

　　平臺(tái)服務(wù)層的調(diào)用是通過(guò)RESTAPI進(jìn)行的，由于REST的特點(diǎn)，通過(guò)在URI中添加資源路徑以及版本信息，很方便地能夠?qū)崿F(xiàn)平臺(tái)的平滑升級(jí)以及數(shù)據(jù)兼容性問(wèn)題。

　　平臺(tái)服務(wù)層實(shí)現(xiàn)的都是共通的服務(wù)，服務(wù)之間是獨(dú)立的，而且是插件式的方式來(lái)實(shí)現(xiàn)的，平臺(tái)選用了面向分布式計(jì)算的Erlang語(yǔ)言來(lái)實(shí)現(xiàn)的，因此保證了這些插件式的服務(wù)能夠熱拔插地部署，實(shí)現(xiàn)真正地不宕機(jī)地部署與更新。

　　平臺(tái)服務(wù)層的插件式架構(gòu)，決定了平臺(tái)的無(wú)限擴(kuò)展能力，能夠根據(jù)不斷變化地用戶(hù)需求而進(jìn)行平臺(tái)的不斷地在線(xiàn)迭代與更新，與用戶(hù)的需求形成一個(gè)良性的循環(huán)。配置定制平臺(tái)通過(guò)服務(wù)器(Apache)的自定義開(kāi)發(fā)，實(shí)現(xiàn)了企業(yè)用戶(hù)應(yīng)用的透明隔離，因此平臺(tái)具有面向不同企業(yè)用戶(hù)根據(jù)不同需求進(jìn)行個(gè)性化定制的能力。不同的企業(yè)用戶(hù)，一般主要有幾方面的自定義需求：業(yè)務(wù)對(duì)象、工作流程、報(bào)表、布局等，而CRM平臺(tái)的平臺(tái)框架就決定著能夠很好地滿(mǎn)足用戶(hù)的自定義需求，主要分為以下幾個(gè)方面：

　　由于用戶(hù)使用的是文檔數(shù)據(jù)庫(kù)，有著松散的數(shù)據(jù)結(jié)構(gòu)，因此用戶(hù)根據(jù)需求，而可以隨意自定義自己的業(yè)務(wù)對(duì)象;CRM平臺(tái)后臺(tái)的平臺(tái)服務(wù)層，有相應(yīng)的實(shí)時(shí)的工作流引擎，提供給用戶(hù)強(qiáng)大的自定義工作流程功能;CRM平臺(tái)有業(yè)內(nèi)是豐富的報(bào)表模板，用戶(hù)只需要根據(jù)自己的需要來(lái)選擇即可，針對(duì)一些自定義的動(dòng)態(tài)數(shù)據(jù)，還提供模板的再定義功能，能夠很好地滿(mǎn)足用戶(hù)的報(bào)表需求;由于平臺(tái)是應(yīng)用隔離的，因此針對(duì)著頁(yè)面的布局，可以很容易地實(shí)現(xiàn)個(gè)性化地定制;CRM平臺(tái)的配置功能的強(qiáng)大，并不以損失平臺(tái)應(yīng)用的易用性為基礎(chǔ)，CRM平臺(tái)在操作上采用引導(dǎo)式操作，以及提供方便易用的在線(xiàn)幫助，大大地降低了系統(tǒng)使用的復(fù)雜度，使系統(tǒng)更加地人性化、簡(jiǎn)易化。

　　實(shí)時(shí)即時(shí)

　　361CRM平臺(tái)的平臺(tái)服務(wù)層與通常的應(yīng)用服務(wù)不同，它是實(shí)時(shí)運(yùn)行的服務(wù)，平臺(tái)服務(wù)層有相應(yīng)的任務(wù)調(diào)度機(jī)制，郵件服務(wù)、消息隊(duì)列以及實(shí)時(shí)的工作流引擎等，這些服務(wù)都是實(shí)時(shí)運(yùn)行的，因此當(dāng)企業(yè)用戶(hù)的業(yè)務(wù)對(duì)象或者業(yè)務(wù)流程發(fā)生變化時(shí)，通過(guò)這些平臺(tái)服務(wù)就可以把即時(shí)的狀態(tài)消息(通過(guò)郵件、短信或者其它的IM工具)推送給用戶(hù)，讓用戶(hù)真正了解到業(yè)務(wù)的即時(shí)與實(shí)時(shí)的狀態(tài)信息。

　　而通常的應(yīng)用服務(wù)是靜態(tài)的，只有當(dāng)用戶(hù)登錄時(shí)，才會(huì)進(jìn)行相應(yīng)的業(yè)務(wù)狀態(tài)的檢查，這樣就嚴(yán)重影響了業(yè)務(wù)處理的速度，對(duì)于即時(shí)性業(yè)務(wù)，就會(huì)帶來(lái)很大的損失。

　　多級(jí)負(fù)載

　　平臺(tái)是一個(gè)多租賃用戶(hù)的在線(xiàn)SaaS系統(tǒng)，因此會(huì)給平臺(tái)帶來(lái)大量的高并發(fā)的請(qǐng)求，361CRM平臺(tái)是一個(gè)多層次的結(jié)構(gòu)，而且采用了REST架構(gòu)，REST天生就是分布式，因此通過(guò)物理部署就可以實(shí)現(xiàn)高并發(fā)帶的負(fù)載均衡。

　　四層負(fù)載在鏈路層解決來(lái)自互聯(lián)網(wǎng)的并發(fā)請(qǐng)求壓力，使用LVS+Heartbeat的主從雙備的架構(gòu)，保證不會(huì)出現(xiàn)單點(diǎn)故障;Web應(yīng)用的大部分壓力都來(lái)自于資源的請(qǐng)求，如圖片，靜態(tài)文件，樣式表等文件的請(qǐng)求，服務(wù)器壓力的70%都來(lái)自于這些資源的請(qǐng)求，因此對(duì)于這些靜態(tài)資源的請(qǐng)求，通過(guò)靜態(tài)資源緩沖層就能夠很好解決這些請(qǐng)求對(duì)于后臺(tái)造成的壓力;經(jīng)過(guò)實(shí)測(cè)，經(jīng)過(guò)一段時(shí)間穩(wěn)定運(yùn)行之后，靜態(tài)資源緩沖層能夠命中前臺(tái)請(qǐng)求的80%以上，有效地緩解了應(yīng)用服務(wù)器的壓力;七層負(fù)載層主要是做業(yè)務(wù)、以及資源的請(qǐng)求分流，把負(fù)載均衡到多臺(tái)文件服務(wù)器以及應(yīng)用服務(wù)器上;文件服務(wù)器與應(yīng)用服務(wù)器是分布式的，通過(guò)Map-Reduce進(jìn)行任務(wù)的拆分與結(jié)果的合并，充分利用多臺(tái)服務(wù)器的并行計(jì)算能力，提升整體平臺(tái)的運(yùn)行性能;文件緩存采用多級(jí)緩存策略，解決命中率高的文件的頻繁請(qǐng)求。而數(shù)據(jù)緩存則通過(guò)業(yè)務(wù)標(biāo)簽以及時(shí)效性策略進(jìn)行數(shù)據(jù)的緩存，并且進(jìn)行緩存的增量更新，有效地解決了對(duì)于后臺(tái)的數(shù)據(jù)讀寫(xiě)壓力;分布式的存儲(chǔ)系統(tǒng)有效地解決了海量數(shù)據(jù)的存儲(chǔ)、檢索、分析以及統(tǒng)計(jì)等問(wèn)題。

　　可見(jiàn)，當(dāng)傳統(tǒng)的CRM系統(tǒng)轉(zhuǎn)換為SaaS服務(wù)后，其架構(gòu)方面還是發(fā)生了不少的變動(dòng)的，也只有這樣的變動(dòng)，才使得CRM能夠在SaaS平臺(tái)上更好的為客戶(hù)所服務(wù)。