題目：基於微服務架構的客戶關係管理系統的研究
摘要：以往信息系統軟件堆積在單獨的系統中, 存在可擴展性差、可靠性低和維護成本高的問題。雖然SOA服務被引入到後期階段, 但由於SOA使用總線模式, 因此這種總線模式會與特定的技術堆棧一起回收, 並與特定的技術堆棧緊密相關。通過將應用程序和服務抽取到更小的應用程序和服務中, 它可以更容易地改進和擴展, 從而提高應用的高併發和高應用。作爲在雲中部署應用程序和服務的新技術, 微服務已成爲當今最新的熱門話題。關於微服務器的討論主要集中在容器或其他技術是否可以很好地執行微服務。公司和服務提供商正在尋找更好的方式將應用程序應用於雲環境, 它將是微服務的未來方向。
關鍵詞：IT行業; SOA服務化; 微服務;客戶關係管理系統
傳統的客戶關係管理系統的實現方式是所有服務端邏輯都集成在一起, 這樣的結構導致系統的擴展性差, 可靠性不高, 維護成本高。雖然有的引入了SOA服務化, 但是, 由於SOA使用總線模式, 這種總線模式與某個技術堆棧緊密耦合, 例如J2EE等特定技術堆棧緊密相連。這導致許多公司的現有系統難以對接, 交換週期太長, 成本太高, 新系統穩定性的收斂需要一些時間。最終SOA看上去很美, 但卻被認爲是企業級奢侈品, 中小公司都望而生畏。本系統是基於我國中小企業的管理現狀, 基於微服務架構研發出來的, 擴展性好, 可靠性高, 維護成不高, 技術棧不受限, 例如, 客戶微服務最初是用java編寫的。現在我們想要將客戶的微服務改爲node Js技術。這完全是可能的, 而且由於擔心只是客戶的邏輯, 所以技術更換的成本將會降低很多。所以如果研發成功, 達到預期的目標, 必定受到我國中小企業的歡迎。
微服務架構是一種基於雲中部署應用程序和服務的新技術。關於微服務的大多數討論集中在容器或其他技術是否可以很好地實現微服務, 並且API應該成爲焦點。微服務可以在他們自己的程序中運行並且可以通過“輕量級設備和HTTP型API進行通信”。關鍵是服務可以在自己的程序中運行。通過這個, 我們可以區分服務公開和微服務架構 (在現有系統中分部一個API) 。在服務公開中, 許多服務可能受到內部獨立進程的限制。如果這些服務中的任何一個需要添加某個功能, 則該進程必須縮小範圍。在微服務體系結構中, 只需將所需功能添加到特殊服務而不影響整個過程。本文就基於微服務架構的客戶關係管理系統進行如下研究:
1 主要研究內容、擬解決的技術難點和關鍵技術
1.1 主要研究內容
1) 微服務架構的研究;
2) 客戶關係管理系統的原有服務拆分粒度的研究;
3) 微服務分佈式事務的研究;
4) 設計實現適合客戶關係管理系統的微服務架構。
1.2 擬解決技術難點
1) API Gateway (客戶端如何訪問這些服務) :傳統的開發方法, 所有的服務都是本地的, 可以直接調用UI, 現在可以按功能劃分爲獨立的服務。客戶端UI如何訪問他的服務。後臺有N個服務, 前臺需要記住管理N服務。因此, 通常在後臺會有N個服務和UI之間的代理或API網關。他的功能包括:
提供統一的服務門戶, 使微服務對前臺透明;
整合後臺服務以節省流量並提高性能;
提供API管理功能, 如安全性, 過濾和流量控制;
2) 服務調用 (如何在服務之間進行通信) :因爲所有的微服務都是獨立運行在不同機器上的獨立進程, 服務之間的通信是IPC (inter process communication) , 並且有許多成熟的解決方案。現在基本上最常見的是方法:
REST (JAX-RS, Spring Boot) ;
RPC (Thrift, Dubbo) ;
異步消息調用 (Kafka, Notify) 。
同步呼叫相對簡單且一致, 但容易引發問題, 性能體驗稍差, 特別是長時間的呼叫級別。異步消息方法在分佈式系統中具有特別廣泛的應用範圍。他不僅可以減少呼叫業務之間的耦合, 還可以緩衝呼叫, 確保消息積壓不會沖洗被呼叫者, 同時保證呼叫。派對的服務體驗將繼續實現其自身的功能沒有被背景表現放慢。
3) 服務發現 (有多少服務查找) :在微服務體系結構中, 每種服務通常具有多個副本, 並通過Spring Cloud的Ribbon進行負載均衡。服務隨時可能脫機, 並且可能會響應臨時訪問壓力以添加新的服務節點。服務如何相互感知?服務如何管理?這是服務發現的問題。微服務通過Spring Cloud的Eureka進行註冊。當服務上線時, 服務提供商將其服務信息與註冊中心 (或類似框架) 一起註冊, 並通過心跳保持長鏈接以實時更新鏈接信息。可以通過Spring Boot Admin對註冊中心的服務進行監控 (服務的內存佔用情況, 日誌級別等) 。服務調用者訪問Eureka, 通過服務名稱找到相應服務使用服務。
4) 分佈式微服務下的session問題:在分佈式架構中, 由於服務是跨域訪問, 所以session很難做到共享, 要想共享session, 其中一種比較理想的方案則是將session信息存儲在redis緩存中。只需在maven的pom文件中加入相關依賴即可使用。
1.3 關鍵技術
本次研究選用了當今比較成熟的springboot和springcloud作爲開發架構, Springboot微服務開發架構, 提供了展現、依賴注入、持久化、嵌入式容器、日誌、緩存等常用功能, Eureka主要是實現服務註冊發現, Ribbon主要實現負載均衡, Hystrix主要是服務的延遲和容錯。ZUUL主要是提供動態路由功能。
2 項目擬採取的研究方法 (或技術工藝路線、實施方案) , 以及預期達到的目標、主要技術、經濟指標和水平
2.1 項目擬採取的研究方法
1) 收集整理資料;
2) 分析實施過程中要解決的技術難點;
3) 根據分析結果提出集中初步設計方案;
4) 對比分析各種初步方案, 確定合理解決方案。
2.2 預期達到的目標預期達到的目標、主要技術、經濟指標和水平
本次研究選用了當今比較成熟的springboot和springcloud作爲開發框架, Springboot微服務開發架構, 提供了展現、依賴注入、持久化、嵌入式容器、日誌、緩存等常用功能, Eureka主要是實現服務註冊發現, Ribbon主要實現負載均衡, Hystrix主要是服務的延遲和容錯。ZUUL主要是提供動態路由功能。
1) API Gateway (客戶端如何訪問這些服務) 實現了提供統一服務入口, 使每個服務對前臺透明, 在後臺聚合, 節省流量, 提升性能, 提供安全, 過濾, 流控等管理功能。
2) 服務調用通用的有以下幾種方式:REST (JAX-RS, Spring Boot) ;RPC (Thrift, Dubbo) 。
3) 服務發現:在微服務架構中, 通常每個服務都是有多個拷貝, 通過Spring Cloud的Ribbon來做負載均衡。微服務是通過Spring Cloud的Eureka做註冊中心, 當服務上線時, 服務提供者將自己的服務註冊到註冊中心, 通過心跳維持長鏈接, 實時更新鏈接信息。可以通過Spring Boot Admin對註冊中心的服務進行監控 (服務的內存佔用情況, 日誌級別等) 。服務調用者訪問Eureka, 通過服務名稱找到相應服務使用服務。
4) 分佈式微服務下的session問題:在分佈式架構中, 由於服務是跨域訪問, 所以session很難做到共享, 要想共享session, 其中一種比較理想的`方案則是將session信息存儲在redis緩存中。只需在maven的pom文件中加入相關依賴即可使用。
3 主要技術及應用轉化的前景預測分析
3.1 主要技術
html5、javascript、Ajax、Jquery、SQLSERVER2012、Maven、Redis、Git、springcloud、springboot等。
3.2 應用轉化的前景預測分析
隨着業務敏捷性需求的增加, 我們開始看到一個向“推送”架構或者基於事件體系結構的發展趨勢, 即:一個服務發送一個事件, 一個或多個觀察者容器異步地運行邏輯來響應該事件, 而不需要通知事件生產者。另一個好處是, 在設計各自的服務時, 開發人員可以更加獨立。雖然開發人員可以將容器環境構建爲事件驅動架構, 但功能即服務 (Faa S) 本身就體現了這種能力。在Faa S架構中, 函數作爲文本存儲在數據庫中, 並通過事件觸發。一旦調用了該函數, API控制器就會接收消息並通過負載均衡器將其發送到消息總線, 消息總線將其排入計劃並提供給一個調用容器。執行完後, 結果存儲在數據庫中, 併發送給用戶, 然後函數被分解, 直到再次觸發。Faa S的好處包括:1) 從編寫代碼到運行服務的時間縮短了, 因爲創建或push源碼之後不需要做額外操作。2) 當函數由Faa S平臺 (如AWS) 管理和縮放時, 開銷會減少。然而, Faa S並非沒有自身的挑戰。由於Faa S要求將服務的每個部分解耦, 因此可能會出現難以發現、管理、編排和監視的函數的擴散。最後, 如果沒有依賴項的全面可視化工作, 就很難調試Faa S系統, 可能會出現無限循環。
4 結束語
使用微服務架構構建應用程序很有意義, 因爲它允許您同時具有水平縮放和垂直縮放功能;它還具有可在整個架構中重複使用的額外API。可以每分鐘提供新服務, 因此您必須擁有敏捷且響應迅速的應用程序平臺。這個平臺必須是未來發展的方向。
參考文獻
[1]究竟什麼是微服務架構?[Z] Target SOA[2015-10-23].
[2]Red Hat:API層是微服務架構成功的關鍵[Z] Target[2015-10-10].
[3]微服務與SOA:與其重用不如抓住敏捷性[Z] Targe[2015-10-27].
客戶關係管理系統論文一（2）：
題目：以集成化供應鏈爲基礎的客戶關係管理系統分析
摘要：隨着我國市場經濟體制的完善與經濟全球化的發展, 企業必須採用更爲先進的客戶管理系統以處理更爲複雜的關係。本文對以集成化供應鏈爲基礎的客戶關係系統進行分析, 指出其組成結構與運行模式, 並對建設系統時用到的關鍵技術進行分析, 希望能給廣大相關工作人員提供幫助。
關鍵詞：集成化供應鏈; 客戶關係; 管理系統;
隨着改革開放的不斷推進, 我國市場經濟體制越發完善, 市場競爭模式也發生了巨大的變化。科學技術的快速普及縮小了各企業間產品間的差距。客戶在選擇產品時已經不僅僅關注於價格與產品質量, 對企業的服務也提出了更高的要求。在這樣的時代背景下, 任何企業都不可能獨立存在與發展。深度合作是大勢所趨, 基於集成化供應鏈的客戶關係管理系統是企業未來發展的必然趨勢。
1 以集成化供應鏈爲基礎的客戶關係管理系統
集成化供應鏈是指供應鏈內部成員爲了實現一個共同目標而組建的一個“虛擬組織”, 組織內部成員彼此間信息共享, 並通過一系列的協調與合作工作實現目標。以集成化供應鏈爲基礎的客戶關係包含兩種情況即傳統的競爭關係與合作關係。這樣的客戶關係需要企業與客戶之間實現有效的資源共享, 因此必須建立一種全新的、具有不同層次的客戶信息管理系統。[1]該系統需要滿足以下幾個方面的要求。 (1) 具備有效的客戶數據分析功能, 爲相關的決策人員提供可靠的數據參考。 (2) 必須具有面向客戶的交互平臺, 讓客戶可以及時獲得信息, 以及與企業取得聯繫。 (3) 具備企業和戰略合作伙伴的信息共享平臺, 實現信息流動, 爲各個節點的企業做出正確的決策提供數據、信息保障。
2 以集成化供應鏈爲基礎的客戶關係管理系統的基本結構
2.1 系統結構
以集成化供應鏈爲基礎的客戶關係管理系統主要由數據中心、功能層與用戶層三個部分組成。數據中心是由中心數據庫與客戶關係數據庫兩個部分組成。系統在獲得客戶的數據後會分別存儲在這兩個數據庫中。客戶關係數據庫涉及到的主要信息爲各單位間的具體業務信息。最終中心數據庫的數據與客戶關係數據庫都會進入多維數據庫, 從而實現對各類信息的保存與分析。管理系統的功能層是建立在對客戶數據的錄入的基礎上, 通過數據中心對數據信息進行加工分析, 從而形成相應的數據報告, 最終實現爲企業提供數據支持的目的, 幫助公司決策層做出正確的決策。用戶層是由客戶、合作伙伴、業務員等多個單位共同構成, 用戶層是面對客戶與合作伙伴等單位的交互平臺, 在這裏客戶與合作伙伴可以獲得相關數據。
2.2 運營模式
以集成化供應鏈爲基礎的客戶管理系統建立的目的是要處理複雜的客戶關係。在該系統中, 企業與客戶之間既有合作也有競爭, 因此, 集成化供應鏈的基本運行模式爲螺旋型週期循環模式。在系統具體的運行中, 需要爲不同的用戶羣體提供不同的終端。一方面可以滿足客戶、合作伙伴、業務人員等不同人員對於數據的要求, 另一方面也可以更加有效地收集其具體信息。在完成信息收集時, 系統數據庫以及數據處理中心會根據數學模型展開一系列複雜的運算獲得, 最後以最直觀的形式出現在公司決策人員面前。這些決策人員會根據數據分析結果制定制定相關的發展計劃以及相關部門的管理制度、運營標準。相關部門需要根據這些標準開展工作, 再通過系統收集相關信息繼而對工作標準加以調整、修改, 如此往復循環。該客戶管理系統的核心是用戶, 有效的數據分析可以爲決策人員提供最爲重要的數據參考, 有助於決策者做出正確的決定, 從而促進企業的的發展進步。
3 系統中應用的關鍵技術
3.1 數據庫
以集成化供應鏈爲基礎的客戶關係管理系統是建立在一系列數據保存與分析的基礎上的一個系統。在該客戶管理系統中主要運用的數據庫有中心數據庫、客戶關係數據庫、多維數據庫。數據庫可以實現對各單位數據信息, 並對這些分散的數據信息進行融合、以便實現各種信息的查閱、存取與分析。[2]在進行數據庫設計時需要確定數據收集範圍與數據收集方式;定義好數據的轉化、傳輸, 確保數據能夠進入到正確的數據庫中並繼而完成相關的具體操作。此外, 數據庫還擔負着數據優化的重要職責, 數據優化是確保數據準確性的重要手段,
3.2 數據挖掘