沒有標準并不等同于SaaS不能被用戶接受。我們可以從某些常見的應用中以點帶面，看一看SaaS服務應該具有什么樣的標準。我們今天以企業(yè)用戶常用的CRM系統(tǒng)，來看一看標準的SaaS CRM應該是一個什么樣子。
實際上，很多用戶對于CRM并不陌生，早在2000年的時候，有一些企業(yè)就已經(jīng)開始嘗試CRM系統(tǒng)。在很多人眼中，CRM就是一套C/S或者B/S的應用系統(tǒng)。而當CRM進入了SaaS，他在架構(gòu)上會是一個什么樣子呢?采用企業(yè)級的多層次、多應用的系統(tǒng)結(jié)構(gòu)的SaaS在線CRM平臺。平臺架構(gòu)從大的層次上來分主要為四層，根據(jù)調(diào)用關(guān)系依次為應用層、緩沖層、服務層以及存儲層。
應用層
從瀏覽器發(fā)送過來的請求，直接由應用層來進行直接響應;平臺是多租賃用戶的在線多應用來實現(xiàn)的，由于每個用戶的具體業(yè)務需求不同，因此每個租賃用戶的應用是相互隔離的，但應用層的結(jié)構(gòu)卻都是相同，從上到下主要分為業(yè)務展現(xiàn)層、業(yè)務邏輯層、業(yè)務模型層、實體訪問層;業(yè)務展現(xiàn)層主要為用戶數(shù)據(jù)的不同視圖表現(xiàn)，為用戶呈現(xiàn)各種易于瀏覽、便于理解的各種數(shù)據(jù)表現(xiàn)方式，如表單、表格、報表、圖表等;業(yè)務邏輯層主要是業(yè)務邏輯的具體實現(xiàn)層，對于用戶動作、觸發(fā)事件以及工作流程等由業(yè)務邏輯層來實現(xiàn)業(yè)務的處理以及響應，通過業(yè)務邏輯層對下層業(yè)務模型的訪問來實現(xiàn)具體的邏輯處理;業(yè)務模型層主要是業(yè)務對象的具體定義與封裝，是對于現(xiàn)實中業(yè)務在平臺中的最直接的映射;實體訪問層是對于業(yè)務邏輯層對于業(yè)務模型操作的封裝，業(yè)務模型的實體狀態(tài)的更新、刪除、查詢等都是通過實體訪問層來實現(xiàn)。
緩沖層
緩沖層主要對于靜態(tài)資源以及動態(tài)數(shù)據(jù)的緩存。靜態(tài)資源主要是指應用層中展現(xiàn)層中所要使用到的靜態(tài)資源文件，以及由用戶在業(yè)務操作中產(chǎn)生的文件等，如圖片、上傳的文件等;而動態(tài)數(shù)據(jù)是指用戶在使用平臺的過程中所產(chǎn)生的業(yè)務數(shù)據(jù)，在實現(xiàn)業(yè)務中，這部分數(shù)據(jù)大部分都是讀操作比較多，而寫操作比較少，因此可以針對這部分數(shù)據(jù)根據(jù)特定的緩存失效策略機制來進行相應的緩存;緩沖層的緩存針對應用層是透明的，而且針對多應用也是透明的，因此緩沖層具有更大的彈性與靈活性。
服務層
服務主要是指平臺的核心服務，核心服務分為業(yè)務共通服務以及平臺共通服務，平臺共通服務是指與業(yè)務無關(guān)且是平臺最基礎的服務，如任務調(diào)度、消息隊列、郵件服務、圖片處理、工作流引擎等;而業(yè)務共通服務指基于平臺共通服務，而對于所有業(yè)務具有共通性的服務，如日志審核、操作回滾、數(shù)據(jù)安全、全文檢索、權(quán)限角色等;服務層是對于平臺運營、維護最核心的服務實現(xiàn)，是平臺正常運行的基礎。
存儲層
存儲主要分為兩部分：分布式文件存儲以及分布式的數(shù)據(jù)存儲;由于是多應用的平臺，因此隨著平臺的運營，會產(chǎn)生海量的業(yè)務數(shù)據(jù)以及資源文件，因此伴隨著海量的數(shù)據(jù)而來的問題就是存儲、檢索、分析以及統(tǒng)計等問題;針對上述問題，361CRM平臺采用了分布式的存儲系統(tǒng)，基于Map-Reduce來進行相應的檢索、分析以及統(tǒng)計，實現(xiàn)了對于海量數(shù)據(jù)的統(tǒng)一操作。
這種結(jié)構(gòu)能做到真正的分布式網(wǎng)絡計算，有效降低網(wǎng)絡流量，減輕客戶端負擔，還能安全、方便地與互聯(lián)網(wǎng)接口。另外公司員工或客戶分布或行走于全國各地，通常都有移動辦公需求。
REST 架構(gòu)
REST是基于HTTP的，因此天生就有在互聯(lián)網(wǎng)上穿透防火墻的能力，REST可以簡單地認為它是輕量級的WebService，但是它具有自己的一些顯著特點：所有的資源通過統(tǒng)一的接口訪問(HTTP/HTTPSGET、POST、PUT、ELETE)，而且接口比較統(tǒng)一，便于與第三方的集成;因為是基于HTTP/HTTPS的，因此可以將資源(響應)分為可緩存的和不可緩存的，以及采用瀏覽器的標準壓縮方式，有效地提升網(wǎng)絡效能。也可以在客戶和資源之間插入不同的中間組件來提升性能和安全等，如，代理服務，緩存服務，網(wǎng)關(guān)服務等;因為是基于HTTP/HTTPS的資源請求，因此本次連接和下一次到服務器的連接之間沒有狀態(tài)。由于361CRM平臺采用了REST架構(gòu)，因此也就決定了361CRM平臺天然就具備以下幾方面的優(yōu)勢：
由于REST本身無狀態(tài)的特性，361CRM平臺天然就是分布式的，決定了后臺通過根據(jù)業(yè)務量而彈性地增加服務器就可以實現(xiàn)平臺計算能力的線性增加;所有的請求都是統(tǒng)一通過RESTAPI進行相應的資源與服務的請求，這樣就能夠保證系統(tǒng)提供的服務都是解耦的，極大的簡化了系統(tǒng)，從而改善了系統(tǒng)的交互性和可重用性，同時也能夠根據(jù)業(yè)務進行相應統(tǒng)一且透明的內(nèi)存緩存;客戶端瀏覽器能夠輕松通過Ajax實現(xiàn)REST資源的異步調(diào)用處理，同時也可以有效地減少應用服務器地壓力;通過提供開放的RESTAPI，能夠輕松實現(xiàn)與第三方的集成。
平臺服務
平臺服務層的調(diào)用是通過RESTAPI進行的，由于REST的特點，通過在URI中添加資源路徑以及版本信息，很方便地能夠?qū)崿F(xiàn)平臺的平滑升級以及數(shù)據(jù)兼容性問題。
平臺服務層實現(xiàn)的都是共通的服務，服務之間是獨立的，而且是插件式的方式來實現(xiàn)的，平臺選用了面向分布式計算的Erlang語言來實現(xiàn)的，因此保證了這些插件式的服務能夠熱拔插地部署，實現(xiàn)真正地不宕機地部署與更新。
平臺服務層的插件式架構(gòu)，決定了平臺的無限擴展能力，能夠根據(jù)不斷變化地用戶需求而進行平臺的不斷地在線迭代與更新，與用戶的需求形成一個良性的循環(huán)。配置定制平臺通過服務器(Apache)的自定義開發(fā)，實現(xiàn)了企業(yè)用戶應用的透明隔離，因此平臺具有面向不同企業(yè)用戶根據(jù)不同需求進行個性化定制的能力。不同的企業(yè)用戶，一般主要有幾方面的自定義需求：業(yè)務對象、工作流程、報表、布局等，而CRM平臺的平臺框架就決定著能夠很好地滿足用戶的自定義需求，主要分為以下幾個方面：
由于用戶使用的是文檔數(shù)據(jù)庫，有著松散的數(shù)據(jù)結(jié)構(gòu)，因此用戶根據(jù)需求，而可以隨意自定義自己的業(yè)務對象;CRM平臺后臺的平臺服務層，有相應的實時的工作流引擎，提供給用戶強大的自定義工作流程功能;CRM平臺有業(yè)內(nèi)是豐富的報表模板，用戶只需要根據(jù)自己的需要來選擇即可，針對一些自定義的動態(tài)數(shù)據(jù)，還提供模板的再定義功能，能夠很好地滿足用戶的報表需求;由于平臺是應用隔離的，因此針對著頁面的布局，可以很容易地實現(xiàn)個性化地定制;CRM平臺的配置功能的強大，并不以損失平臺應用的易用性為基礎，CRM平臺在操作上采用引導式操作，以及提供方便易用的在線幫助，大大地降低了系統(tǒng)使用的復雜度，使系統(tǒng)更加地人性化、簡易化。
實時即時
361CRM平臺的平臺服務層與通常的應用服務不同，它是實時運行的服務，平臺服務層有相應的任務調(diào)度機制，郵件服務、消息隊列以及實時的工作流引擎等，這些服務都是實時運行的，因此當企業(yè)用戶的業(yè)務對象或者業(yè)務流程發(fā)生變化時，通過這些平臺服務就可以把即時的狀態(tài)消息(通過郵件、短信或者其它的IM工具)推送給用戶，讓用戶真正了解到業(yè)務的即時與實時的狀態(tài)信息。
而通常的應用服務是靜態(tài)的，只有當用戶登錄時，才會進行相應的業(yè)務狀態(tài)的檢查，這樣就嚴重影響了業(yè)務處理的速度，對于即時性業(yè)務，就會帶來很大的損失。
多級負載
平臺是一個多租賃用戶的在線SaaS系統(tǒng)，因此會給平臺帶來大量的高并發(fā)的請求，361CRM平臺是一個多層次的結(jié)構(gòu)，而且采用了REST架構(gòu)，REST天生就是分布式，因此通過物理部署就可以實現(xiàn)高并發(fā)帶的負載均衡。
四層負載在鏈路層解決來自互聯(lián)網(wǎng)的并發(fā)請求壓力，使用LVS+Heartbeat的主從雙備的架構(gòu)，保證不會出現(xiàn)單點故障;Web應用的大部分壓力都來自于資源的請求，如圖片，靜態(tài)文件，樣式表等文件的請求，服務器壓力的70%都來自于這些資源的請求，因此對于這些靜態(tài)資源的請求，通過靜態(tài)資源緩沖層就能夠很好解決這些請求對于后臺造成的壓力;經(jīng)過實測，經(jīng)過一段時間穩(wěn)定運行之后，靜態(tài)資源緩沖層能夠命中前臺請求的80%以上，有效地緩解了應用服務器的壓力;七層負載層主要是做業(yè)務、以及資源的請求分流，把負載均衡到多臺文件服務器以及應用服務器上;文件服務器與應用服務器是分布式的，通過Map-Reduce進行任務的拆分與結(jié)果的合并，充分利用多臺服務器的并行計算能力，提升整體平臺的運行性能;文件緩存采用多級緩存策略，解決命中率高的文件的頻繁請求。而數(shù)據(jù)緩存則通過業(yè)務標簽以及時效性策略進行數(shù)據(jù)的緩存，并且進行緩存的增量更新，有效地解決了對于后臺的數(shù)據(jù)讀寫壓力;分布式的存儲系統(tǒng)有效地解決了海量數(shù)據(jù)的存儲、檢索、分析以及統(tǒng)計等問題。
可見，當傳統(tǒng)的CRM系統(tǒng)轉(zhuǎn)換為SaaS服務后，其架構(gòu)方面還是發(fā)生了不少的變動的，也只有這樣的變動，才使得CRM能夠在SaaS平臺上更好的為客戶所服務。
附：什么是REST架構(gòu)
REST軟件架構(gòu)是當今世界上最成功的互聯(lián)網(wǎng)的超媒體分布式系統(tǒng)。它讓人們真正理解我們的網(wǎng)絡協(xié)議HTTP本來面貌。它正在成為網(wǎng)絡服務的主流技術(shù)，同時也正在改變互聯(lián)網(wǎng)的網(wǎng)絡軟件開發(fā)的全新思維方式。AJAX技術(shù)和Rails框架把REST軟件架構(gòu)思想真正地在實際中很好表現(xiàn)出來。今天微軟也已經(jīng)應用REST并且提出把我們現(xiàn)有的網(wǎng)絡變成為一個語義網(wǎng)，這種網(wǎng)絡將會使得搜索更加智能化。
REST與HTTP協(xié)議
REST軟件架構(gòu)是由RoyThomasFielding博士在2000年首次提出的。他為我們描繪了開發(fā)基于互聯(lián)網(wǎng)的網(wǎng)絡軟件的藍圖。REST軟件架構(gòu)是一個抽象的概念，是一種為了實現(xiàn)這一互聯(lián)網(wǎng)的超媒體分布式系統(tǒng)的行動指南。利用任何的技術(shù)都可以實現(xiàn)這種理念。而實現(xiàn)這一軟件架構(gòu)最著名的就是HTTP協(xié)議。通常我們把REST也寫作為REST/HTTP，在實際中往往把REST理解為基于HTTP的REST軟件架構(gòu)，或者更進一步把REST和HTTP看作為等同的概念。
今天，HTTP是互聯(lián)網(wǎng)上應用最廣泛的計算機協(xié)議。HTTP不是一個簡單的運載數(shù)據(jù)的協(xié)議，而是一個具有豐富內(nèi)涵的網(wǎng)絡軟件的協(xié)議。它不僅僅能夠?qū)τ诨ヂ?lián)網(wǎng)資源進行唯一定位，而且還能告訴我們對于該資源進行怎樣運作。這也是REST軟件架構(gòu)當中最重要的兩個理念。而REST軟件架構(gòu)理念是真正理解HTTP協(xié)議而形成的。有了REST軟件架構(gòu)理念出現(xiàn)，才使得軟件業(yè)避免了對HTTP協(xié)議的片面理解。只有正確的理論指導，才能避免在軟件開發(fā)的實際工作過程中少走彎路。
REST與URI(資源定位)
REST軟件架構(gòu)之所以是一個超媒體系統(tǒng)，是因為它可以把網(wǎng)絡上所有資源進行唯一的定位，不管你的文件是圖片、文件Word還是視頻文件，也不管你的文件是txt文件格式、xml文件格式還是其它文本文件格式。它利用支持HTTP的TCP/IP協(xié)議來確定互聯(lián)網(wǎng)上的資源。
REST與CRUD原則
REST軟件架構(gòu)遵循了CRUD原則，該原則告訴我們對于資源(包括網(wǎng)絡資源)只需要四種行為：創(chuàng)建(Create)、獲取(Read)、更新(Update)和銷毀(DELETE)就可以完成對其操作和處理了。其實世界萬物都是遵循這一規(guī)律：生、變、見、滅。所以計算機世界也不例外。這個原則是源自于我們對于數(shù)據(jù)庫表的數(shù)據(jù)操作：insert(生)、select(見)、update(變)和delete(滅)，所以有時候CRUD也寫作為RUDI，其中的I就是insert。這四個操作是一種原子操作，即一種無法再分的操作，通過它們可以構(gòu)造復雜的操作過程，正如數(shù)學上四則運算是數(shù)字的最基本的運算一樣。
REST與網(wǎng)絡服務
盡管在Java語言世界中網(wǎng)絡服務目前是以SOAP技術(shù)為主，但是REST將是是網(wǎng)絡服務的另一選擇，并且是真正意義上的網(wǎng)絡服務?；赗EST思想的網(wǎng)絡服務不久的將來也會成為是網(wǎng)絡服務的主流技術(shù)。REST不僅僅把HTTP作為自己的數(shù)據(jù)運輸協(xié)議，而且也作為直接進行數(shù)據(jù)處理的工具。而當前的網(wǎng)絡服務技術(shù)都需要使用其它手段來完成數(shù)據(jù)處理工作，它們完全獨立于HTTP協(xié)議來進行的，這樣增加了大量的復雜軟件架構(gòu)設計工作。REST的思想充分利用了現(xiàn)有的HTTP技術(shù)的網(wǎng)絡能力。在德國電視臺上曾經(jīng)出現(xiàn)過一個這樣的五十萬歐元智力題：如何實現(xiàn)網(wǎng)絡服務才能充分利用現(xiàn)有的HTTP協(xié)議?該問題給出了四個答案：去問微軟;WSDL2.0/SOAP1.2;WS-Transfer;根本沒有。這個問題告訴我們HTTP并不是一個簡單的數(shù)據(jù)傳來傳去的協(xié)議，而是一個聰明的會表現(xiàn)自己的協(xié)議，這也許是REST=RepresentationalStateTransfer的真正含義。
實際上目前很多大公司已經(jīng)采用了REST技術(shù)作為網(wǎng)絡服務，如Google、Amazon等。在Java語言中重要的兩個以SOAP技術(shù)開始的網(wǎng)絡服務框架XFire和Axis也把REST作為自己的另一種選擇。它們的新的項目分別是ApacheCXF和Axis2。Java語言也制定關(guān)于REST網(wǎng)絡服務規(guī)范：JAX-RS:JavaAPIforRESTfulWebServices(JSR311)。相信還會出現(xiàn)更多與REST相關(guān)的激動人心的信息。
REST與AJAX技術(shù)
盡管AJAX技術(shù)的出現(xiàn)才不到兩年時間，但是AJAX技術(shù)遵循了REST的一些重要原則。AJAX技術(shù)充分利用了HTTP來獲取網(wǎng)絡資源并且實現(xiàn)了HTTP沒有的對于異步數(shù)據(jù)進行傳輸?shù)墓δ堋JAX技術(shù)還使得軟件更好地實現(xiàn)分布性功能，在一個企業(yè)內(nèi)只要一個人下載了AJAX引擎，其它企業(yè)內(nèi)部的人員，就可以共享該資源了。AJAX技術(shù)遵守REST準則的應用程序中簡單和可伸縮的架構(gòu)，凡是采用AJAX技術(shù)的頁面簡潔而又豐富，一個頁面表現(xiàn)了豐富多彩的形態(tài)。
AJAX技術(shù)還使用了一種不同于XML格式的JSON文件格式，這個意義在哪里呢?在REST軟件架構(gòu)下我們不能對于XML文件進行序列化處理，這樣程序員必須要使用自己的XML綁定框架。而以序列化的JavaScript對象為基礎的JSON已經(jīng)獲得了廣泛認可，它被認為能以遠比XML更好的方式來序列化和傳輸簡單數(shù)據(jù)結(jié)構(gòu)，而且它更簡潔。這對REST是一個極大貢獻和補充。
當前的網(wǎng)絡應用軟件還違背了REST的“無狀態(tài)服務器”約束。REST服務器只知道自己的狀態(tài)。REST不關(guān)心客戶端的狀態(tài)，客戶端的狀態(tài)自己來管理，這是AJAX技術(shù)的應用之地。通過AJAX技術(shù)，可以發(fā)揮有狀態(tài)網(wǎng)絡客戶機的優(yōu)勢。而REST的服務器關(guān)心的是從所有網(wǎng)絡客戶端發(fā)送到服務器操作的順序。這樣使得互聯(lián)網(wǎng)這樣一個巨大的網(wǎng)絡得到有序的管理。
REST與Rails框架
RubyonRails框架(簡稱Rails或者Rails框架)是一個基于Ruby語言的越來越流行的網(wǎng)絡應用軟件開發(fā)框架。它提供了關(guān)于REST最好的支持，也是當今應用REST最成功的一個軟件開發(fā)框架。Rails框架(從版本1.2.x起)成為了第一個引入REST作為核心思想的主流網(wǎng)絡軟件開發(fā)框架。在Rails框架的充分利用了REST軟件架構(gòu)之后，人們更加堅信REST的重要性和必要性。Rails利用REST軟件架構(gòu)思想對網(wǎng)絡服務也提供了一流的支持。從最直觀的角度看待REST，它是網(wǎng)絡服務最理想的手段，但是Rails框架把REST帶到了網(wǎng)絡應用軟件開發(fā)框架。這是一次飛躍，讓REST的思想從網(wǎng)絡服務的應用提升到了網(wǎng)絡應用軟件開發(fā)。利用REST思想的simply_restful插件已經(jīng)成為了Rails框架的核心內(nèi)容。
REST安全性
我們把現(xiàn)有基于SOAP的網(wǎng)絡服務和基于REST/HTTP網(wǎng)絡服務作個比喻，前者是一種傳統(tǒng)的寄信方式，而后者是現(xiàn)代網(wǎng)絡的電子郵件方式。要是是寄信和電子郵件都有病毒存在的話，傳統(tǒng)的寄信被送到對方就很危險，而電子郵件是開發(fā)的，電子郵件供應商比如Google為我們檢查了電子郵件是否有病毒。這里并不是說明SOAP網(wǎng)絡服務消息包含義病毒，而是說明HTTP是無法處理SOAP信息包究竟好不好，需要額外的軟件工具解決這一問題，包括防火墻也用不上和管不了。
REST/HTTP網(wǎng)絡服務的信息包可以被防火墻理解和控制。你可以按照操作和鏈接進行過濾信息包，如你可以規(guī)定從外部來的只能讀取(GET操作)自己服務器的資源。這樣對于系統(tǒng)管理員而言使得軟件管理更為簡單。REST的安全性還可以利用傳輸安全協(xié)議SSL/TLS、基本和摘要式認證(BasicundDigestAuthentication)。除了這些REST自身的安全性功能外，還可以利用像基于信息的WebServicesSecurity(JSR155)作為REST不錯的補充。
