客戶關系管理系統論文

時間：2024-07-28 12:44:47 管理畢業論文我要投稿

商業銀行客戶關系管理系統設計與實現論文推薦度：
相關推薦

客戶關系管理系統論文

　　題目：基于微服務架構的客戶關系管理系統的研究

客戶關系管理系統論文

　　摘要：以往信息系統軟件堆積在單獨的系統中, 存在可擴展性差、可靠性低和維護成本高的問題。雖然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, 通過服務名稱找到相應服務使用服務。

　　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].Tech Target SOA[2015-10-23].

　　[2]Red Hat:API層是微服務架構成功的關鍵[Z].Tech Target[2015-10-10].

　　[3]微服務與SOA:與其重用不如抓住敏捷性[Z].Tech Targe[2015-10-27].

　　客戶關系管理系統論文一（2）：

　　題目：以集成化供應鏈為基礎的客戶關系管理系統分析

　　摘要：隨著我國市場經濟體制的完善與經濟全球化的發展, 企業必須采用更為先進的客戶管理系統以處理更為復雜的關系。本文對以集成化供應鏈為基礎的客戶關系系統進行分析, 指出其組成結構與運行模式, 并對建設系統時用到的關鍵技術進行分析, 希望能給廣大相關工作人員提供幫助。

　　關鍵詞：集成化供應鏈; 客戶關系; 管理系統;

　　隨著改革開放的不斷推進, 我國市場經濟體制越發完善, 市場競爭模式也發生了巨大的變化。科學技術的快速普及縮小了各企業間產品間的差距。客戶在選擇產品時已經不僅僅關注于價格與產品質量, 對企業的服務也提出了更高的要求。在這樣的時代背景下, 任何企業都不可能獨立存在與發展。深度合作是大勢所趨, 基于集成化供應鏈的客戶關系管理系統是企業未來發展的必然趨勢。

　　1 以集成化供應鏈為基礎的客戶關系管理系統

　　集成化供應鏈是指供應鏈內部成員為了實現一個共同目標而組建的一個“虛擬組織”, 組織內部成員彼此間信息共享, 并通過一系列的協調與合作工作實現目標。以集成化供應鏈為基礎的客戶關系包含兩種情況即傳統的競爭關系與合作關系。這樣的客戶關系需要企業與客戶之間實現有效的資源共享, 因此必須建立一種全新的、具有不同層次的客戶信息管理系統。[1]該系統需要滿足以下幾個方面的要求。 (1) 具備有效的客戶數據分析功能, 為相關的決策人員提供可靠的數據參考。 (2) 必須具有面向客戶的交互平臺, 讓客戶可以及時獲得信息, 以及與企業取得聯系。 (3) 具備企業和戰略合作伙伴的信息共享平臺, 實現信息流動, 為各個節點的企業做出正確的決策提供數據、信息保障。

　　2 以集成化供應鏈為基礎的客戶關系管理系統的基本結構

　　2.1 系統結構

　　以集成化供應鏈為基礎的客戶關系管理系統主要由數據中心、功能層與用戶層三個部分組成。數據中心是由中心數據庫與客戶關系數據庫兩個部分組成。系統在獲得客戶的數據后會分別存儲在這兩個數據庫中。客戶關系數據庫涉及到的主要信息為各單位間的具體業務信息。最終中心數據庫的數據與客戶關系數據庫都會進入多維數據庫, 從而實現對各類信息的保存與分析。管理系統的功能層是建立在對客戶數據的錄入的基礎上, 通過數據中心對數據信息進行加工分析, 從而形成相應的數據報告, 最終實現為企業提供數據支持的目的, 幫助公司決策層做出正確的決策。用戶層是由客戶、合作伙伴、業務員等多個單位共同構成, 用戶層是面對客戶與合作伙伴等單位的交互平臺, 在這里客戶與合作伙伴可以獲得相關數據。

　　2.2 運營模式

　　以集成化供應鏈為基礎的客戶管理系統建立的目的是要處理復雜的客戶關系。在該系統中, 企業與客戶之間既有合作也有競爭, 因此, 集成化供應鏈的基本運行模式為螺旋型周期循環模式。在系統具體的運行中, 需要為不同的用戶群體提供不同的終端。一方面可以滿足客戶、合作伙伴、業務人員等不同人員對于數據的要求, 另一方面也可以更加有效地收集其具體信息。在完成信息收集時, 系統數據庫以及數據處理中心會根據數學模型展開一系列復雜的運算獲得, 最后以最直觀的形式出現在公司決策人員面前。這些決策人員會根據數據分析結果制定制定相關的發展計劃以及相關部門的管理制度、運營標準。相關部門需要根據這些標準開展工作, 再通過系統收集相關信息繼而對工作標準加以調整、修改, 如此往復循環。該客戶管理系統的核心是用戶, 有效的數據分析可以為決策人員提供最為重要的數據參考, 有助于決策者做出正確的決定, 從而促進企業的的發展進步。

　　3 系統中應用的關鍵技術

　　3.1 數據庫

　　以集成化供應鏈為基礎的客戶關系管理系統是建立在一系列數據保存與分析的基礎上的一個系統。在該客戶管理系統中主要運用的數據庫有中心數據庫、客戶關系數據庫、多維數據庫。數據庫可以實現對各單位數據信息, 并對這些分散的數據信息進行融合、以便實現各種信息的查閱、存取與分析。[2]在進行數據庫設計時需要確定數據收集范圍與數據收集方式;定義好數據的轉化、傳輸, 確保數據能夠進入到正確的數據庫中并繼而完成相關的具體操作。此外, 數據庫還擔負著數據優化的重要職責, 數據優化是確保數據準確性的重要手段,

　　3.2 數據挖掘

　　大多數有用的信息都隱藏在數據背后。數據挖掘是指對數據模型與數據之間深層次的關系進行深一步的挖掘, 從而將隱藏在海量數據背后的信息找出來, 揭示信息內部的規律性, 并呈現在相關決策人員面前。在完成數據采集后必須要對數據進行挖掘, 從中獲取更多有用的信息, 從而為相關決策人員提供高質量的數據參考。在具體的實施過程中, 首先要確保被選擇數據的準確性。其次根據相關規則與時間序列進行初步預測。最后再實踐工作中對結果進行必須的驗證, 從而得到準確的結果。

　　3.3 信息集成

　　信息集成技術要求該系統與其他系統之間進行數據同步、信息交流, 是客戶管理系統與其他系統進行協作的基礎, 是將客戶管理系統與其他系統進行融合工作的紐帶。信息集成技術主要包含有信息轉換標準協議與信息傳輸標準協議。在實際的工作中, 主要采用的信息轉換協議為XML協議, 通過對SOAP技術進行運用以完成標準畫的信息傳輸協議。在進行系統建設過程中使用各種標準化的協議可以解決各系統間的不協調問題, 提高信息傳輸與轉換的穩定性與效率。

　　4 結語

　　以集成化供應鏈為基礎的客戶關系系統是是處理新時期企業與客戶復雜關系的有效系統, 進行該系統建設時必須對其內部結構與運形模式進行深層次的了解, 并做好數據庫、數據挖掘技術的應用工作。通過對系統數據的進一步挖掘揭示數據背后的規律, 為相關決策者提供可靠的數據支持, 從而促進企業的健康穩定發展。

　　參考文獻

　　[1]鄭麗娟, 張乾.基于集成化供應鏈的客戶關系管理系統研究[J].商業時代, 2008 (10) :45-46.

　　[2]張繼德, 時斐.基于電子商務的供應鏈管理應用研究——以蘇寧易購為例[J].會計之友, 2014 (36) :122-126.

【客戶關系管理系統論文】相關文章：

客戶關系管理的論文07-28

商業銀行客戶關系管理系統設計與實現論文06-28