淺談SaaS線上CRM雲平臺架構

沒有標準並不等同于SaaS不能被使用者接受。 我們可以從某些常見的應用中以點帶面，看一看SaaS服務應該具有什麼樣的標準。 我們今天以企業使用者常用的CRM系統，來看一看標準的SaaS CRM應該是一個什麼樣子。

實際上，很多使用者對於CRM並不陌生，早在2000年的時候，有一些企業就已經開始嘗試CRM系統。 在很多人眼中，CRM就是一套C/S或者B/S的應用系統。 而當CRM進入了SaaS，他在架構上會是一個什麼樣子呢?採用企業級的多層次、多應用的系統結構的SaaS線上CRM平臺。 平臺架構從大的層次上來分主要為四層，根據調用關係依次為應用層、緩衝層、服務層以及存儲層。

應用層

從瀏覽器發送過來的請求，直接由應用層來進行直接回應;平臺是多租賃使用者的線上多應用來實現的，由於每個使用者的具體業務需求不同，因此每個租賃使用者的應用是相互隔離的，但應用層的結構卻都是相同，從上到下主要分為業務展現層、 業務邏輯層、業務模型層、實體訪問層;業務展現層主要為使用者資料的不同視圖表現，為使用者呈現各種易於流覽、便於理解的各種資料表現方式，如表單、表格、報表、圖表等;業務邏輯層主要是業務邏輯的具體實現層，對於使用者動作、 觸發事件以及工作流程等由業務邏輯層來實現業務的處理以及回應，通過業務邏輯層對下層業務模型的訪問來實現具體的邏輯處理;業務模型層主要是業務物件的具體定義與封裝，是對於現實中業務在平臺中的最直接的映射; 實體訪問層是對於業務邏輯層對於業務模型操作的封裝，業務模型的實體狀態的更新、刪除、查詢等都是通過實體訪問層來實現。

緩衝層

緩衝層主要對於靜態資源以及動態資料的緩存。 靜態資源主要是指應用層中展現層中所要使用到的靜態資源檔，以及由使用者在業務操作中產生的檔等，如圖片、上傳的檔等;而動態資料是指使用者在使用平臺的過程中所產生的業務資料，在實現業務中，這部分資料大部分都是讀操作比較多， 而寫操作比較少，因此可以針對這部分資料根據特定的緩存失效策略機制來進行相應的緩存;緩衝層的緩存針對應用層是透明的，而且針對多應用也是透明的，因此緩衝層具有更大的彈性與靈活性。

服務層

服務主要是指平臺的核心服務，核心服務分為業務共通服務以及平臺共通服務，平臺共通服務是指與業務無關且是平臺最基礎的服務，如任務調度、訊息佇列、郵件服務、圖片處理、工作流引擎等;而業務共通服務指基於平臺共通服務， 而對於所有業務具有共通性的服務，如日誌審核、操作回滾、資料安全、全文檢索、許可權角色等;服務層是對於平臺運營、維護最核心的服務實現，是平臺正常運行的基礎。

存儲層

存儲主要分為兩部分：分散式檔存儲以及分散式的資料存儲;由於是多應用的平臺，因此隨著平臺的運營，會產生海量的業務資料以及資源檔，因此伴隨著海量的資料而來的問題就是存儲、檢索、分析以及統計等問題;針對上述問題， 361CRM平臺採用了分散式的存儲系統，基於Map-Reduce來進行相應的檢索、分析以及統計，實現了對於海量資料的統一操作。

這種結構能做到真正的分散式網路計算，有效降低網路流量，減輕用戶端負擔，還能安全、方便地與互聯網介面。 另外公司員工或客戶分佈或行走于全國各地，通常都有移動辦公需求。

REST 架構

REST是基於HTTP的，因此天生就有在互聯網上穿透防火牆的能力，REST可以簡單地認為它是羽量級的WebService，但是它具有自己的一些顯著特點：所有的資源通過統一的介面訪問(HTTP/HTTPSGET、POST、 PUT、ELETE)，而且介面比較統一，便於與協力廠商的集成;因為是基於HTTP/HTTPS的，因此可以將資源(回應)分為可快取的和不可快取的，以及採用瀏覽器的標準壓縮方式，有效地提升網路效能。 也可以在客戶和資源之間插入不同的中間元件來提升性能和安全等，如，代理服務，快取服務，閘道服務等;因為是基於HTTP/HTTPS的資源請求，因此本次連接和下一次到伺服器的連接之間沒有狀態。 由於361CRM平臺採用了REST架構，因此也就決定了361CRM平臺天然就具備以下幾方面的優勢：

由於REST本身無狀態的特性，361CRM平臺天然就是分散式的，決定了後臺通過根據業務量而彈性地增加伺服器就可以實現平臺計算能力的線性增加;所有的請求都是統一通過RESTAPI進行相應的資源與服務的請求， 這樣就能夠保證系統提供的服務都是解耦的，極大的簡化了系統，從而改善了系統的交互性和再使用性，同時也能夠根據業務進行相應統一且透明的記憶體緩存；用戶端瀏覽器能夠輕鬆通過Ajax實現REST資源的非同步調用處理， 同時也可以有效地減少應用伺服器地壓力；通過提供開放的RESTAPI，能夠輕鬆實現與協力廠商的集成。

平臺服務

平臺服務層的調用是通過RESTAPI進行的，由於REST的特點，通過在URI中添加資源路徑以及版本資訊，很方便地能夠實現平臺的平滑升級以及資料相容性問題。

平臺服務層實現的都是共通的服務，服務之間是獨立的，而且是外掛程式式的方式來實現的，平臺選用了面向分散式運算的Erlang語言來實現的，因此保證了這些外掛程式式的服務能夠熱拔插地部署，實現真正地不宕機地部署與更新。

平臺服務層的外掛程式式架構，決定了平臺的無限擴展能力，能夠根據不斷變化地使用者需求而進行平臺的不斷地線上反覆運算與更新，與使用者的需求形成一個良性的迴圈。 配置定制平臺通過伺服器(Apache)的自訂開發，實現了企業使用者應用的透明隔離，因此平臺具有面向不同企業使用者根據不同需求進行個人化定制的能力。 不同的企業使用者，一般主要有幾方面的自訂需求：業務物件、工作流程、報表、佈局等，而CRM平臺的平臺框架就決定著能夠很好地滿足使用者的自訂需求，主要分為以下幾個方面：

由於使用者使用的是文檔資料庫，有著鬆散的資料結構，因此使用者根據需求，而可以隨意自訂自己的業務物件; CRM平臺後臺的平臺服務層，有相應的即時的工作流引擎，提供給使用者強大的自訂工作流程功能; CRM平臺有業內是豐富的報表範本，使用者只需要根據自己的需要來選擇即可，針對一些自訂的動態資料，還提供範本的再定義功能，能夠很好地滿足使用者的報表需求;由於平臺是應用隔離的，因此針對著頁面的佈局， 可以很容易地實現個人化地定制; CRM平臺的配置功能的強大，並不以損失平臺應用的易用性為基礎，CRM平臺在操作上採用引導式操作，以及提供方便易用的線上說明，大大地降低了系統使用的複雜度，使系統更加地人性化、簡易化。

即時即時

361CRM平臺的平臺服務層與通常的應用服務不同，它是即時運行的服務，平臺服務層有相應的任務調度機制，郵件服務、訊息佇列以及即時的工作流引擎等，這些服務都是即時運行的，因此當企業使用者的業務物件或者業務流程發生變化時， 通過這些平臺服務就可以把即時的狀態訊息(通過郵件、短信或者其它的IM工具)推送給使用者，讓使用者真正瞭解到業務的即時與即時的狀態資訊。

而通常的應用服務是靜態的，只有當使用者登錄時，才會進行相應的業務狀態的檢查，這樣就嚴重影響了業務處理的速度，對於即時性業務，就會帶來很大的損失。

多級負載

平臺是一個多租賃使用者的線上SaaS系統，因此會給平臺帶來大量的高併發的請求，361CRM平臺是一個多層次的結構，而且採用了REST架構，REST天生就是分散式，因此通過物理部署就可以實現高併發帶的負載均衡。

四層負載在鏈路層解決來自互聯網的併發請求壓力，使用LVS+Heartbeat的主從雙備的架構，保證不會出現單點故障; Web應用的大部分壓力都來自于資源的請求，如圖片，靜態檔，樣式表等檔的請求，伺服器壓力的70%都來自于這些資源的請求，因此對於這些靜態資源的請求，通過靜態資源緩衝層就能夠很好解決這些請求對於後臺造成的壓力;經過實測， 經過一段時間穩定運行之後，靜態資源緩衝層能夠命中前臺請求的80%以上，有效地緩解了應用伺服器的壓力;七層負載層主要是做業務、以及資源的請求分流，把負載均衡到多台檔案伺服器以及應用伺服器上;檔案伺服器與應用伺服器是分散式的 ，通過Map-Reduce進行任務的拆分與結果的合併，充分利用多台伺服器的平行計算能力，提升整體平臺的運行性能;檔案快取採用多級緩存策略，解決命中率高的檔的頻繁請求。 而資料緩存則通過業務標籤以及時效性策略進行資料的緩存，並且進行緩存的增量更新，有效地解決了對於後臺的資料讀寫壓力;分散式的存儲系統有效地解決了海量資料的存儲、檢索、分析以及統計等問題。

可見，當傳統的CRM系統轉換為SaaS服務後，其架構方面還是發生了不少的變動的，也只有這樣的變動，才使得CRM能夠在SaaS平臺上更好的為客戶所服務。

(責任編輯：蒙遺善)