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