客戶(hù)關(guān)系管理系統論文

　　題目：基于微服務(wù)架構的客戶(hù)關(guān)系管理系統的研究

　　摘要：以往信息系統軟件堆積在單獨的系統中, 存在可擴展性差、可靠性低和維護成本高的問(wèn)題。雖然SOA服務(wù)被引入到后期階段, 但由于SOA使用總線(xiàn)模式, 因此這種總線(xiàn)模式會(huì )與特定的技術(shù)堆棧一起回收, 并與特定的技術(shù)堆棧緊密相關(guān)。通過(guò)將應用程序和服務(wù)抽取到更小的應用程序和服務(wù)中, 它可以更容易地改進(jìn)和擴展, 從而提高應用的高并發(fā)和高應用。作為在云中部署應用程序和服務(wù)的新技術(shù), 微服務(wù)已成為當今最新的熱門(mén)話(huà)題。關(guān)于微服務(wù)器的討論主要集中在容器或其他技術(shù)是否可以很好地執行微服務(wù)。公司和服務(wù)提供商正在尋找更好的方式將應用程序應用于云環(huán)境, 它將是微服務(wù)的未來(lái)方向。

　　關(guān)鍵詞：IT行業(yè); SOA服務(wù)化; 微服務(wù);客戶(hù)關(guān)系管理系統

　　傳統的客戶(hù)關(guān)系管理系統的實(shí)現方式是所有服務(wù)端邏輯都集成在一起, 這樣的結構導致系統的擴展性差, 可靠性不高, 維護成本高。雖然有的引入了SOA服務(wù)化, 但是, 由于SOA使用總線(xiàn)模式, 這種總線(xiàn)模式與某個(gè)技術(shù)堆棧緊密耦合, 例如J2EE等特定技術(shù)堆棧緊密相連。這導致許多公司的現有系統難以對接, 交換周期太長(cháng), 成本太高, 新系統穩定性的收斂需要一些時(shí)間。最終SOA看上去很美, 但卻被認為是企業(yè)級奢侈品, 中小公司都望而生畏。本系統是基于我國中小企業(yè)的管理現狀, 基于微服務(wù)架構研發(fā)出來(lái)的, 擴展性好, 可靠性高, 維護成不高, 技術(shù)棧不受限, 例如, 客戶(hù)微服務(wù)最初是用java編寫(xiě)的�，F在我們想要將客戶(hù)的微服務(wù)改為node Js技術(shù)。這完全是可能的, 而且由于擔心只是客戶(hù)的邏輯, 所以技術(shù)更換的成本將會(huì )降低很多。所以如果研發(fā)成功, 達到預期的目標, 必定受到我國中小企業(yè)的歡迎。

　　微服務(wù)架構是一種基于云中部署應用程序和服務(wù)的新技術(shù)。關(guān)于微服務(wù)的大多數討論集中在容器或其他技術(shù)是否可以很好地實(shí)現微服務(wù), 并且API應該成為焦點(diǎn)。微服務(wù)可以在他們自己的程序中運行并且可以通過(guò)“輕量級設備和HTTP型API進(jìn)行通信”。關(guān)鍵是服務(wù)可以在自己的程序中運行。通過(guò)這個(gè), 我們可以區分服務(wù)公開(kāi)和微服務(wù)架構 (在現有系統中分部一個(gè)API) 。在服務(wù)公開(kāi)中, 許多服務(wù)可能受到內部獨立進(jìn)程的限制。如果這些服務(wù)中的任何一個(gè)需要添加某個(gè)功能, 則該進(jìn)程必須縮小范圍。在微服務(wù)體系結構中, 只需將所需功能添加到特殊服務(wù)而不影響整個(gè)過(guò)程。本文就基于微服務(wù)架構的客戶(hù)關(guān)系管理系統進(jìn)行如下研究:

　　1 主要研究?jì)热�、擬解決的技術(shù)難點(diǎn)和關(guān)鍵技術(shù)

　　1.1 主要研究?jì)热?/p>

　　1) 微服務(wù)架構的研究;

　　2) 客戶(hù)關(guān)系管理系統的原有服務(wù)拆分粒度的研究;

　　3) 微服務(wù)分布式事務(wù)的研究;

　　4) 設計實(shí)現適合客戶(hù)關(guān)系管理系統的微服務(wù)架構。

　　1.2 擬解決技術(shù)難點(diǎn)

　　1) API Gateway (客戶(hù)端如何訪(fǎng)問(wèn)這些服務(wù)) :傳統的開(kāi)發(fā)方法, 所有的服務(wù)都是本地的, 可以直接調用UI, 現在可以按功能劃分為獨立的服務(wù)�？蛻�(hù)端UI如何訪(fǎng)問(wèn)他的服務(wù)。后臺有N個(gè)服務(wù), 前臺需要記住管理N服務(wù)。因此, 通常在后臺會(huì )有N個(gè)服務(wù)和UI之間的代理或API網(wǎng)關(guān)。他的功能包括:

　　提供統一的服務(wù)門(mén)戶(hù), 使微服務(wù)對前臺透明;

　　整合后臺服務(wù)以節省流量并提高性能;

　　提供API管理功能, 如安全性, 過(guò)濾和流量控制;

　　2) 服務(wù)調用 (如何在服務(wù)之間進(jìn)行通信) :因為所有的微服務(wù)都是獨立運行在不同機器上的獨立進(jìn)程, 服務(wù)之間的通信是IPC (inter process communication) , 并且有許多成熟的解決方案�，F在基本上最常見(jiàn)的是方法:

　　REST (JAX-RS, Spring Boot) ;

　　RPC (Thrift, Dubbo) ;

　　異步消息調用 (Kafka, Notify) 。

　　同步呼叫相對簡(jiǎn)單且一致, 但容易引發(fā)問(wèn)題, 性能體驗稍差, 特別是長(cháng)時(shí)間的呼叫級別。異步消息方法在分布式系統中具有特別廣泛的應用范圍。他不僅可以減少呼叫業(yè)務(wù)之間的耦合, 還可以緩沖呼叫, 確保消息積壓不會(huì )沖洗被呼叫者, 同時(shí)保證呼叫。派對的服務(wù)體驗將繼續實(shí)現其自身的功能沒(méi)有被背景表現放慢。

　　3) 服務(wù)發(fā)現 (有多少服務(wù)查找) :在微服務(wù)體系結構中, 每種服務(wù)通常具有多個(gè)副本, 并通過(guò)Spring Cloud的Ribbon進(jìn)行負載均衡。服務(wù)隨時(shí)可能脫機, 并且可能會(huì )響應臨時(shí)訪(fǎng)問(wèn)壓力以添加新的服務(wù)節點(diǎn)。服務(wù)如何相互感知?服務(wù)如何管理?這是服務(wù)發(fā)現的問(wèn)題。微服務(wù)通過(guò)Spring Cloud的Eureka進(jìn)行注冊。當服務(wù)上線(xiàn)時(shí), 服務(wù)提供商將其服務(wù)信息與注冊中心 (或類(lèi)似框架) 一起注冊, 并通過(guò)心跳保持長(cháng)鏈接以實(shí)時(shí)更新鏈接信息�？梢酝ㄟ^(guò)Spring Boot Admin對注冊中心的服務(wù)進(jìn)行監控 (服務(wù)的內存占用情況, 日志級別等) 。服務(wù)調用者訪(fǎng)問(wèn)Eureka, 通過(guò)服務(wù)名稱(chēng)找到相應服務(wù)使用服務(wù)。

　　4) 分布式微服務(wù)下的session問(wèn)題:在分布式架構中, 由于服務(wù)是跨域訪(fǎng)問(wèn), 所以session很難做到共享, 要想共享session, 其中一種比較理想的方案則是將session信息存儲在redis緩存中。只需在maven的pom文件中加入相關(guān)依賴(lài)即可使用。

　　1.3 關(guān)鍵技術(shù)

　　本次研究選用了當今比較成熟的springboot和springcloud作為開(kāi)發(fā)架構, Springboot微服務(wù)開(kāi)發(fā)架構, 提供了展現、依賴(lài)注入、持久化、嵌入式容器、日志、緩存等常用功能, Eureka主要是實(shí)現服務(wù)注冊發(fā)現, Ribbon主要實(shí)現負載均衡, Hystrix主要是服務(wù)的延遲和容錯。ZUUL主要是提供動(dòng)態(tài)路由功能。

　　2 項目擬采取的研究方法 (或技術(shù)工藝路線(xiàn)、實(shí)施方案) , 以及預期達到的目標、主要技術(shù)、經(jīng)濟指標和水平

　　2.1 項目擬采取的研究方法

　　1) 收集整理資料;

　　2) 分析實(shí)施過(guò)程中要解決的技術(shù)難點(diǎn);

　　3) 根據分析結果提出集中初步設計方案;

　　4) 對比分析各種初步方案, 確定合理解決方案。

　　2.2 預期達到的目標預期達到的目標、主要技術(shù)、經(jīng)濟指標和水平

　　本次研究選用了當今比較成熟的springboot和springcloud作為開(kāi)發(fā)框架, Springboot微服務(wù)開(kāi)發(fā)架構, 提供了展現、依賴(lài)注入、持久化、嵌入式容器、日志、緩存等常用功能, Eureka主要是實(shí)現服務(wù)注冊發(fā)現, Ribbon主要實(shí)現負載均衡, Hystrix主要是服務(wù)的延遲和容錯。ZUUL主要是提供動(dòng)態(tài)路由功能。

　　1) API Gateway (客戶(hù)端如何訪(fǎng)問(wèn)這些服務(wù)) 實(shí)現了提供統一服務(wù)入口, 使每個(gè)服務(wù)對前臺透明, 在后臺聚合, 節省流量, 提升性能, 提供安全, 過(guò)濾, 流控等管理功能。

　　2) 服務(wù)調用通用的有以下幾種方式:REST (JAX-RS, Spring Boot) ;RPC (Thrift, Dubbo) 。

　　3) 服務(wù)發(fā)現:在微服務(wù)架構中, 通常每個(gè)服務(wù)都是有多個(gè)拷貝, 通過(guò)Spring Cloud的Ribbon來(lái)做負載均衡。微服務(wù)是通過(guò)Spring Cloud的Eureka做注冊中心, 當服務(wù)上線(xiàn)時(shí), 服務(wù)提供者將自己的服務(wù)注冊到注冊中心, 通過(guò)心跳維持長(cháng)鏈接, 實(shí)時(shí)更新鏈接信息�？梢酝ㄟ^(guò)Spring Boot Admin對注冊中心的服務(wù)進(jìn)行監控 (服務(wù)的內存占用情況, 日志級別等) 。服務(wù)調用者訪(fǎng)問(wèn)Eureka, 通過(guò)服務(wù)名稱(chēng)找到相應服務(wù)使用服務(wù)。

　　4) 分布式微服務(wù)下的session問(wèn)題:在分布式架構中, 由于服務(wù)是跨域訪(fǎng)問(wèn), 所以session很難做到共享, 要想共享session, 其中一種比較理想的方案則是將session信息存儲在redis緩存中。只需在maven的pom文件中加入相關(guān)依賴(lài)即可使用。

　　3 主要技術(shù)及應用轉化的前景預測分析

　　3.1 主要技術(shù)

　　html5、javascript、Ajax、Jquery、SQLSERVER2012、Maven、Redis、Git、springcloud、springboot等。

　　3.2 應用轉化的前景預測分析

　　隨著(zhù)業(yè)務(wù)敏捷性需求的增加, 我們開(kāi)始看到一個(gè)向“推送”架構或者基于事件體系結構的發(fā)展趨勢, 即:一個(gè)服務(wù)發(fā)送一個(gè)事件, 一個(gè)或多個(gè)觀(guān)察者容器異步地運行邏輯來(lái)響應該事件, 而不需要通知事件生產(chǎn)者。另一個(gè)好處是, 在設計各自的服務(wù)時(shí), 開(kāi)發(fā)人員可以更加獨立。雖然開(kāi)發(fā)人員可以將容器環(huán)境構建為事件驅動(dòng)架構, 但功能即服務(wù) (Faa S) 本身就體現了這種能力。在Faa S架構中, 函數作為文本存儲在數據庫中, 并通過(guò)事件觸發(fā)。一旦調用了該函數, API控制器就會(huì )接收消息并通過(guò)負載均衡器將其發(fā)送到消息總線(xiàn), 消息總線(xiàn)將其排入計劃并提供給一個(gè)調用容器。執行完后, 結果存儲在數據庫中, 并發(fā)送給用戶(hù), 然后函數被分解, 直到再次觸發(fā)。Faa S的好處包括:1) 從編寫(xiě)代碼到運行服務(wù)的時(shí)間縮短了, 因為創(chuàng )建或push源碼之后不需要做額外操作。2) 當函數由Faa S平臺 (如AWS) 管理和縮放時(shí), 開(kāi)銷(xiāo)會(huì )減少。然而, Faa S并非沒(méi)有自身的挑戰。由于Faa S要求將服務(wù)的每個(gè)部分解耦, 因此可能會(huì )出現難以發(fā)現、管理、編排和監視的函數的擴散。最后, 如果沒(méi)有依賴(lài)項的全面可視化工作, 就很難調試Faa S系統, 可能會(huì )出現無(wú)限循環(huán)。

　　4 結束語(yǔ)

　　使用微服務(wù)架構構建應用程序很有意義, 因為它允許您同時(shí)具有水平縮放和垂直縮放功能;它還具有可在整個(gè)架構中重復使用的額外API�？梢悦糠昼娞峁┬路�務(wù), 因此您必須擁有敏捷且響應迅速的應用程序平臺。這個(gè)平臺必須是未來(lái)發(fā)展的方向。

　　參考文獻

　　[1]究竟什么是微服務(wù)架構?[Z].Tech Target SOA[2015-10-23].

　　[2]Red Hat:API層是微服務(wù)架構成功的關(guān)鍵[Z].Tech Target[2015-10-10].

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

　　客戶(hù)關(guān)系管理系統論文一（2）：

　　題目：以集成化供應鏈為基礎的客戶(hù)關(guān)系管理系統分析

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

　　關(guān)鍵詞：集成化供應鏈; 客戶(hù)關(guān)系; 管理系統;

　　隨著(zhù)改革開(kāi)放的不斷推進(jìn), 我國市場(chǎng)經(jīng)濟體制越發(fā)完善, 市場(chǎng)競爭模式也發(fā)生了巨大的變化�？茖W(xué)技術(shù)的快速普及縮小了各企業(yè)間產(chǎn)品間的差距�？蛻�(hù)在選擇產(chǎn)品時(shí)已經(jīng)不僅僅關(guān)注于價(jià)格與產(chǎn)品質(zhì)量, 對企業(yè)的服務(wù)也提出了更高的要求。在這樣的時(shí)代背景下, 任何企業(yè)都不可能獨立存在與發(fā)展。深度合作是大勢所趨, 基于集成化供應鏈的客戶(hù)關(guān)系管理系統是企業(yè)未來(lái)發(fā)展的必然趨勢。

　　1 以集成化供應鏈為基礎的客戶(hù)關(guān)系管理系統

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

　　2 以集成化供應鏈為基礎的客戶(hù)關(guān)系管理系統的基本結構

　　2.1 系統結構

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

　　2.2 運營(yíng)模式

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

　　3 系統中應用的關(guān)鍵技術(shù)

　　3.1 數據庫

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

　　3.2 數據挖掘

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

　　3.3 信息集成

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

　　4 結語(yǔ)

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

　　參考文獻

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

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

【客戶(hù)關(guān)系管理系統論文】相關(guān)文章：

客戶(hù)關(guān)系管理的論文07-28

客戶(hù)關(guān)系管理的論文07-28

商業(yè)銀行客戶(hù)關(guān)系管理系統設計與實(shí)現論文06-28

關(guān)于客戶(hù)關(guān)系管理的論文07-05

客戶(hù)關(guān)系管理論文08-22

管理系統設計論文08-10

關(guān)于客戶(hù)關(guān)系管理數據挖掘論文06-26

客戶(hù)關(guān)系管理的價(jià)值論文參考07-13

管理系統論文發(fā)表10-24

物資管理系統論文08-22