題目：基於微服務架構的客戶關係管理系統的研究
摘要：以往資訊系統軟體堆積在單獨的系統中, 存在可擴充套件性差、可靠性低和維護成本高的問題。雖然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 資料探勘