客戶關系管理系統(CRM)核心功能的技術實現

青島護適通醫療科技有限公司 山東 青島 266101

CRM系統在國內推廣實施已經二十余年了。為了規范管理、降低成本、提高競爭力,各家企業均紛紛上馬該系統。隨著技術的不斷進步,CRM系統自身也在發生者深刻的變革。現就家電領域CRM系統的技術實現做一下淺顯的探討。

一、總體架構與設計方案

總體架構方案基于微服務的理念,前后端實現分離方案,結合Spring-Cloud實現分布式微服務,將每個微服務設計成無狀態服務,可以借助于Kubernetes等具備彈性伸縮能力的基礎平臺,實現按需彈性伸縮,更好的應對不同模塊的不用訪問量帶來的壓力,同時降低運維等成本。

↑整體架構方案

二、View層

View為整個系統的“窗戶”,屬于用戶的視圖層,用戶視覺效果的展示。View層采用Vue進行開發,使用螞蟻金服開源的AntDesign模板風格實現Web端的設計,采用微信前端團隊開源的WeUI庫結合DCloud的uni-app實現移動端的開發,uni-app可以實現一套代碼生成IOS、Android、微信小程序、支付寶小程序等多平臺多形態的移動端程序。

三、Gateway

Gateway為整個系統的鑒權、授權和路由模塊,每一次的前端的訪問請求,都要經過Gateway的審核,首先驗證用戶是否已經登錄,其次驗證用戶是否有權限訪問當前的URI,然后再決定是否放行。

Gateway的方案采用SpringCloud生態體系中的Kong,Kong是一個云原生,快速,可擴展和分布式微服務抽象層(也稱為API網關,API中間件或某些情況下的Service Mesh)。作為2015年的開源項目,其核心價值在于高性能和可擴展性。Kong積極維護,廣泛應用于從創業公司到Global 5000以及政府組織等公司的生產,其特性如下:

Cloud-Native:平臺不可知,Kong可以從裸機運行到Kubernetes。

動態負載平衡:跨多個上游服務負載均衡流量。

基于散列的負載平衡:使用一致的散列/粘性會話進行負載平衡。

斷路器:智能跟蹤不健康的上游服務。

運行狀況檢查:上游服務的主動和被動監控。

服務發現:在Consul等第三方DNS解析器中解析SRV記錄。

無服務器:直接從Kong調用并保護AWS Lambda或OpenWhisk功能。

WebSockets:通過WebSockets與您的上游服務進行通信。

OAuth2.0:輕松將OAuth2.0身份驗證添加到API。

日志記錄:通過HTTP,TCP,UDP或磁盤記錄對系統的請求和響應。

安全性:ACL,Bot檢測,白名單/黑名單IP等……

Syslog:登錄系統日志。

SSL:為基礎服務或API設置特定SSL證書。

監控:實時監控提供關鍵負載和性能服務器指標。

轉發代理:使Kong連接到中間透明HTTP代理。

身份驗證:HMAC,JWT,Basic等。

速率限制:基于許多變量阻止和限制請求。

轉換:添加,刪除或操作HTTP請求和響應。

緩存:在代理層緩存并提供響應。

CLI:從命令行控制您的Kong集群。

REST API:Kong可以使用其RESTful API進行操作,以獲得最大的靈活性。

地理復制:配置始終是不同地區的最新信息。

故障檢測和恢復:如果您的某個Cassandra節點發生故障,Kong不會受到影響。

群集:所有Kong節點自動加入群集,使其配置在節點之間更新。

可擴展性:通過自然分布,Kong通過簡單地添加節點來水平擴展。

性能:Kong通過擴展和核心使用NGINX輕松處理負載。

插件:可擴展的體系結構,用于為Kong和API添加功能。

四、業務模塊

業務模塊共分為六個,每個模塊均為無狀態服務,以便在單模塊高壓訪問的時候實現彈性伸縮和負載均衡。

業務模塊的開發框架為SpringBoot,SpringBoot是由Pivotal團隊在2013年開始研發、2014年4月發布第一個版本的全新開源的輕量級框架。它基于Spring4.0設計,不僅繼承了Spring框架原有的優秀特性,而且還通過簡化配置來進一步簡化了Spring應用的整個搭建和開發過程。另外Spring-Boot通過集成大量的框架使得依賴包的版本沖突,以及引用的不穩定性等問題得到了很好的解決。SpringBoot所具備的特征有:

(1)可以創建獨立的Spring應用程序,并且基于其Maven或Gradle插件,可以創建可執行的JARs和WARs;

(2)內嵌Tomcat或Jetty等Servlet容器;

(3)提供自動配置的“starter”項目對象模型(POMS)以簡化 Maven配置;

(4)盡可能自動配置Spring容器;

(5)提供準備好的特性,如指標、健康檢查和外部化配置;

(6)絕對沒有代碼生成,不需要XML配置。

五、緩存

緩存使用Redis Cluster,Redis單機負載能力官方數據能達到180k的QPS,在面對高并發的情況下有很好的支撐能力,并且集群模式下,其自帶的高可用能力為大流量大并發場景提供了更好的支持。

六、DB層

DB層采用MySQL 8,采用一主兩從的架構。Master負責主數據的讀取和寫入,Slave 1實時從Master中復制數據,做主從同步和讀寫分離(如果有需要的話),Slave 2作為延遲熱備份,延遲一小時從Master拉取數據。

七、數據災備

Redis集群中的數據為緩存數據,當Redis Node宕機后,Redis集群能夠主動發生主從切換,實現整個集群的高可用。

MySQL使用KeepAlive進行監控,當發生主節點宕機的情況,自動觸發主從切換機制,將Slave 1切換成主機,保證整個集群的可用性。另外,制定相關的數據災備策略,每周一凌晨0點做Slave 1的全量備份,每周四、六凌晨0點做Slave 1的數據增量備份。以上僅為個人的一點淺見,希望能對企業有所幫助。