分布式架構在電信CRM系統中的研究與應用

摘要：隨著科學技術日益進步，CRM系統已經成為電信行業競爭中的核心競爭力之一。文章根據現有的CRM系統的發展現狀，探討了CRM系統的基本架構及該架構的分布式原理，并對中國電信集團CRM項目分布式實現做了分析，從而凸顯分布式架構在CRM系統的運用價值。

關鍵詞：CRM系統；分布式架構；開源ESB

中圖分類號：TP272 文獻標識碼：A 文章編號：1009-2374（2014）27-0061-03

1 電信CRM系統架構分析

1.1 系統分布式架構原理

1.1.1 基于消息方式實現系統間通信。系統依靠發送消息來進行通信，消息包括字節流、字節數組，甚至是java對象，系統接收到消息后則進行相應的業務處理。消息方式的系統通信，基于網絡協議，常用協議是TCP/IP和UDP/IP。

TCP/IP是一種可靠的網絡數據傳輸協議，它要求通信雙方首先建立連接，之后再進行數據的傳輸，TCP/IP負責保證數據傳輸的可靠性，包括數據的可到達，數據到達的順序等，但由于需要保證連接及數據傳輸的可靠，因此可能會犧牲一些性能。

UDP/IP是一種不保證數據一定到達的網絡傳輸協議，它并不直接給通信雙方建立連接，而是發送到網絡上進行傳遞，由于它不建立連接，并且不能保證數據傳輸的可靠，因此性能上相對較好，但可能出現數據丟失。TCP/IP和UDP/IP可用于完成數據的傳輸，但要完成系統間通信，還需要對數據進行處理，例如讀取和寫入數據，按照POSIX標準分為同步IO和異步IO兩種，其中同步IO最常用的是BIO和NIO。

從程序角度而言，BIO就是當發起IO的讀或寫操作時，均為阻塞方式，只有當程序讀到了流或者流寫入操作系統后，才會釋放資源。NIO是基于事件驅動思想的，程序角度而言，發起IO的讀或寫操作時，是非阻塞的，java對TCP/IP和UDP/IP均支持，在網絡IO的操作上，jdk支持BIO和NIO兩種方式。

1.1.2 基于遠程方法調用方式實現系統間通信。遠程方法調用（RPC）是機器間不同進程的過程調用，它使得運行在多臺機器上的傳統進程間實現相互通信成為可能，因此，為實現進程或機器間的相互通信，RPC提供了一種較簡單的方式。

同RPC相比，java中引入的遠程方法調用（RMI），能夠實現分布式對象通信，因此開發者可以將網絡使能代碼實現成純java對象，從而使用到OOP的強大功能，比如繼承、封裝及多態等特性。網絡或機器的不穩定性。對于基于單JVM的應用而言，一旦JVM癱瘓，則整個應用將癱瘓。但是，對于分布式對象應用而言，由于存在多個JVM協同工作，因此即使某個JVM癱瘓，也不會對業務系統造成任何影響，在遠程方法調用場合，為保證網絡或機器的穩定性，需要提供一致的編程模型處理突發事件，比如JVM癱瘓，機器癱瘓，網絡不穩定，在代碼處理遠程調用時，一旦發生了任何遠程異常事件，必須告知應用。顯然，為完成遠程調用，需要解決大量的底層問題。由于RMI屏蔽了大量的底層細節問題，因此可以快速構建出健壯的分布式應用。

1.2 系統分布式架構實現

中國電信CRM系統分為多個業務邏輯子系統，例如客戶管理、賬務信息、客戶報表子系統等等，這些功能有各自的特色，但又有很多可用的業務邏輯，例如用戶信息，如果這些系統都維護自己的用戶信息讀寫或者業務邏輯，會造成的問題是某個子系統修改了用戶信息，所有系統都需要修改，會相當復雜。這相當提出了一個系統間應用層面如何交互的問題，如果不控制會出現多個系統之間存在多種交互方式：HTTP、TCP/IP、RMI、Web Service等；同步、異步等方式可能都會出現。解決方法就是統一交互的方式，SOA是這種問題的解決方案首選。SOA是面向服務架構，它定義了標準的服務方式進行交互，各系統可采用不同的語言不同的框架實現，交互則通過服務的方式進行，利用ESB實現SOA

平臺。

1.2.1 ESB優勢。

面向服務的架構：分布式的應用由可重用的服務組成。

面向消息的架構：應用之間通過ESB發送和接受消息。

事件驅動的架構：應用之間異步的產生和接收消息。

1.2.2 ESB工作原理。核心思想基于消息中間件來實現系統間的交互。基于消息中間件所構建的系統交互的中間場所稱為總線，系統間交互的數據格式采用統一的消息格式，由總線完成消息的轉化、路由，發送到相應的目標應用，ESB系統結構如圖1所示：

（1）標準的消息通信格式。ESB框架定義系統發送及接收消息時的消息格式，以便各個系統保持一樣的方式與總線通信。

（2）消息路由。當總線收到消息后，根據消息的數據決定發送到哪個系統，在更復雜的情況下，還可以基于消息路由實現功能編排，即當某個功能需要由多個系統共同完成時，可在總線上以流程的方式編排訪問系統的順序。

（3）支持多數據格式并能進行相互轉換。多個系統均發送消息至總線，并由總線將消息轉發，但各個系統消息中的數據格式可能不一致，此時總線需要支持數據的轉換。在統一以服務進行交互這點上，ESB中的消息方式交互承擔轉換的功能，并且支持多種通信及交互（同步、異步）方式，在調試、跟蹤支持上沒有定義，在依賴管理上，由于所有的交互都通過總線進行，在此基礎上可根據消息的流轉來判斷和形成各個系統的依賴關系。在高性能和高可用這兩點上，則取決于實現框架。ESB是一個完全面向企業級的中間件解決方案，可以架構在企業現有的網絡框架、軟硬件系統之上，構筑出一個企業級的信息系統解決方案。在ESB中，服務器猶如一個個汽車站，可以自由地連接和脫離ESB中間件，所有的信息系統都可以通過其發送或接受任務、指令，它適用于所有的現有的或未來的信息應用平臺。

2 中國電信集團CRM項目分布式部署方案

群集是在多個應用服務器實例上同時運行相同的應用程序的行為，每個應用服務器都知道群集中的其他應用服務器。作為群集一部分的應用服務器稱為節點。群集中的節點必須能夠互相通信，從而進行有意義的操作，例如，復制狀態或提供故障轉移性能。由于群集離不開負載均衡，故先討論負載均衡技術。

2.1 負載均衡

負載均衡是通過多個應用服務器實例均衡傳入負載或并行請求的一種方式，從而使應用程序具有可擴展性和高可用性。擴展性是無須更改代碼，應用程序就可以添加硬件處理更多用戶負載的能力。因為可以對負載均衡器添加多個服務器，從而均衡負載增加應用程序可以處理的流量，因此負載均衡有助于擴展應用程序。高可用性是在服務器出現故障的情況下繼續處理請求的能力。

2.2 群集的拓撲和組成

群集由運行在一臺計算機或多臺計算機上的節點組成，群集節點的構造通常指的是群集的拓撲。當一個群集的節點位于不同計算機上時，群集是水平的。節點位于相同計算機上時，群集是垂直的。許多群集既可以是水平的，也可以是垂直的，如圖2所示：

圖2左上角是運行在服務器上的兩個應用服務器實例，對這些實例進行配置使其在相同的集群中運行，并建立一個垂直集群，右方的水平集群由運行在左方服務器上的一個應用服務器實例和一個運行在圖底部服務器上的應用服務器實例構成。混合群集也可以由運行在相同計算機或不同計算機上的應用服務器構成。

2.2.1 垂直集群

（1）支撐高訪問量。Web應用隨著訪問量的增長，通常其瓶頸會出現在CPU或者內存上，網絡IO或磁盤IO出現瓶頸的幾率較低，在此僅分析當增加CPU或內存時，應用如何做到線性增長。

（2）增加CPU。要做到增加CPU后系統的服務能力線性的增長，要求系統能夠隨著CPU的增加，響應速度提升或同時可用于處理請求的線程增加，需要解決以下三種情況才能提升系統支撐的訪問量：

一是鎖競爭激烈。鎖競爭激烈會造成多線程等待鎖，就算增加CPU，也不能讓線程得到更快處理，應對策略是盡可能降低系統中鎖競爭的現象，降低競爭后，可以提升響應速度也可以開啟更多線程支撐訪問量。

二是支撐并發請求的線程數固定。在Java應用中，依靠啟動多個線程來支撐高并發量，如啟動的線程數是固定的，那么即使CPU增加，系統的服務能力也不會得到提升，因此最佳的方法是根據CPU數計算出一個合理的線程數。

三是單線程任務。對于單線程任務，增加CPU不會帶來任何的提升，此時可以考慮按照CPU數對任務進行合理劃分，以能夠通過啟動多個線程來并行地將任務分解成多個任務完成。

（3）增加內存。要做到增加內存后系統的服務能力線性增長，要求系統能夠隨著內存的增加，響應速度提升，主要關注以下兩點。

一是Cache的集合大小固定。系統中通常會借助Cache來提升性能，而為了避免內存資源消耗過多，會限制用于Cache的集合的大小，如這個大小是固定的，那么即使增加了內存，Cache的數據也不會增多。

二是JVM堆內存是固定的。JVM堆通常是在啟動參數中設置的，因此有些時候可能會出現增加了內存，但JVM堆大小沒有調整。所以要避免GC造成CPU出現瓶頸。

2.2.2 水平集群。支撐高訪問量。對于水平集群而言，最佳情況是應用是無狀態的，但系統很難做到完全沒有狀態，業界通常采用一種稱為SNA的體系來指導如何構建無狀態的應用，SNA架構在實現時通常采用的方法是將有狀態的部分集中放入緩存或數據庫中，通常數據庫采用集中存儲的方式。對于java應用而言，通常可采取的方法如下：

（1）廣播同步。廣播同步通常基于Multicast實現，當用戶登錄時，系統的行為如圖3所示：

用戶登錄時，假設訪問為節點A的機器，A機器在驗證用戶的身份后，如通過，則將用戶已登錄的信息廣播，廣播后節點B，節點C也就收到了此信息，因此之后用戶訪問到節點B，也不會要求重新登錄。

（2）分布式緩存。對于需要緩存的狀態數據增多的情況，可采取分布式緩存的方案來解決，分布式緩存是指由多臺機器來構成一個緩存池，每臺機器上緩存一部分數據，采用分布式緩存后，當用戶登陸時，系統行為如圖4。

用戶登錄時訪問的是節點A機器，節點A機器在驗證通過了用戶信息后，將用戶的信息放入分布式緩存集群中的某臺機器上，當用戶登錄后訪問其他功能進入節點B機器時，節點B即可從分布式緩存集群的機器上尋找用戶登錄信息。

總之，對于分布式緩存而言，需要解決的是節點A和節點B在操作同一用戶登錄信息時能分布式緩存集群的同一臺機器上操作。

總線服務層中包括接入服務、配置服務、統計分析服務，這些業務服務系統是相對獨立的，不存在一個統一的標準。這里采用MuleESB將它們通過各種適配技術連接到ESB上來。ESB服務層中有MuleESB、tomcat服務器以及weblogic應用服務器。該層核心是ESB，它能夠實現最大程度的應用集成。客戶應用層對請求用戶操作結算系統提供用戶界面。

3.2 業務邏輯設計

3.2.1 系統中Web服務查詢流程：

（1）服務查詢者構建SOAP消息，發送給WebLogic應用服務器。

（2）如果沒有得到服務器響應，則連接失敗，調用結束。

（3）應用服務器收到查詢請求后，在后臺數據源中查找相應Web服務的信息。

（4）后臺數據源向應用服務器返回相應的查詢結果。

（5）應用服務器將結果以SOAP消息形式，返回給服務查詢者。

3.2.2 系統中MuleESB消息流程：

（1）外部應用程序服務發出請求消息后，消息接收器上的監聽進程監聽到該消息，消息接收器根據業務流程器定義文件中定義的配置信息，獲取訪問點URL。

（2）消息接收器通過解析訪問點URL，獲取所使用的連接器描述符。

（3）消息接收器根據連接器描述符的具體配置快速定位到相應的連接器。

（4）根據業務流程定義文件，如果訪問點URL上配置有消息轉換器，則轉5，否則轉6。

（5）連接器調用消息轉換器進行消息轉換。

（6）消息分配器獲得轉換后的消息，將該消息發送給外部應用程序服務接收或者消息路由器。

（7）流程結束。

4 結語

隨著國內外眾多研究機構、學者以及企業對CRM系統的研究的深入，關于CRM系統的研究已涌現出諸多成果。如學者李兵研究了CRM產品應用集成技術；國外SAP、SIEBEL、IBM等IT企業推出了CRM的解決方案，ORACLE等企業已把CRM系統的應用作為一個重要的發展方向。本論文討論了以下幾個問題：

（1）目前電信CRM系統使用的分布式通信的原理。

（2）研究實現SOA平臺的流行框架：ESB。

（3）研究電信集團CRM群集構建系統的原理及功能架構設計。

參考文獻

[1] 倪曉熔.電信企業ERP系統解決方案及應用[J].電信

網技術，2005，30（5）.

[2] 林昊.分布式Java應用[M].北京：電子工業出版社，2010.

[3] 賀新征.Oracle Weblogic Server 開發權威指南[M].北京：清華大學出版社，2011.

[4] 曾海穎.客戶關系管理中的數據挖掘[D].南京航空航天大學， 2003.

作者簡介：杜劍勐（1980-），男（壯族），廣西柳州人，中國電信股份有限公司上海企業信息化運營中心工程師，碩士，研究方向：軟件工程。

群集是在多個應用服務器實例上同時運行相同的應用程序的行為，每個應用服務器都知道群集中的其他應用服務器。作為群集一部分的應用服務器稱為節點。群集中的節點必須能夠互相通信，從而進行有意義的操作，例如，復制狀態或提供故障轉移性能。由于群集離不開負載均衡，故先討論負載均衡技術。

2.1 負載均衡

負載均衡是通過多個應用服務器實例均衡傳入負載或并行請求的一種方式，從而使應用程序具有可擴展性和高可用性。擴展性是無須更改代碼，應用程序就可以添加硬件處理更多用戶負載的能力。因為可以對負載均衡器添加多個服務器，從而均衡負載增加應用程序可以處理的流量，因此負載均衡有助于擴展應用程序。高可用性是在服務器出現故障的情況下繼續處理請求的能力。

2.2 群集的拓撲和組成

群集由運行在一臺計算機或多臺計算機上的節點組成，群集節點的構造通常指的是群集的拓撲。當一個群集的節點位于不同計算機上時，群集是水平的。節點位于相同計算機上時，群集是垂直的。許多群集既可以是水平的，也可以是垂直的，如圖2所示：

圖2左上角是運行在服務器上的兩個應用服務器實例，對這些實例進行配置使其在相同的集群中運行，并建立一個垂直集群，右方的水平集群由運行在左方服務器上的一個應用服務器實例和一個運行在圖底部服務器上的應用服務器實例構成。混合群集也可以由運行在相同計算機或不同計算機上的應用服務器構成。

2.2.1 垂直集群

（1）支撐高訪問量。Web應用隨著訪問量的增長，通常其瓶頸會出現在CPU或者內存上，網絡IO或磁盤IO出現瓶頸的幾率較低，在此僅分析當增加CPU或內存時，應用如何做到線性增長。

（2）增加CPU。要做到增加CPU后系統的服務能力線性的增長，要求系統能夠隨著CPU的增加，響應速度提升或同時可用于處理請求的線程增加，需要解決以下三種情況才能提升系統支撐的訪問量：

一是鎖競爭激烈。鎖競爭激烈會造成多線程等待鎖，就算增加CPU，也不能讓線程得到更快處理，應對策略是盡可能降低系統中鎖競爭的現象，降低競爭后，可以提升響應速度也可以開啟更多線程支撐訪問量。

二是支撐并發請求的線程數固定。在Java應用中，依靠啟動多個線程來支撐高并發量，如啟動的線程數是固定的，那么即使CPU增加，系統的服務能力也不會得到提升，因此最佳的方法是根據CPU數計算出一個合理的線程數。

三是單線程任務。對于單線程任務，增加CPU不會帶來任何的提升，此時可以考慮按照CPU數對任務進行合理劃分，以能夠通過啟動多個線程來并行地將任務分解成多個任務完成。

（3）增加內存。要做到增加內存后系統的服務能力線性增長，要求系統能夠隨著內存的增加，響應速度提升，主要關注以下兩點。

一是Cache的集合大小固定。系統中通常會借助Cache來提升性能，而為了避免內存資源消耗過多，會限制用于Cache的集合的大小，如這個大小是固定的，那么即使增加了內存，Cache的數據也不會增多。

二是JVM堆內存是固定的。JVM堆通常是在啟動參數中設置的，因此有些時候可能會出現增加了內存，但JVM堆大小沒有調整。所以要避免GC造成CPU出現瓶頸。

2.2.2 水平集群。支撐高訪問量。對于水平集群而言，最佳情況是應用是無狀態的，但系統很難做到完全沒有狀態，業界通常采用一種稱為SNA的體系來指導如何構建無狀態的應用，SNA架構在實現時通常采用的方法是將有狀態的部分集中放入緩存或數據庫中，通常數據庫采用集中存儲的方式。對于java應用而言，通常可采取的方法如下：

（1）廣播同步。廣播同步通常基于Multicast實現，當用戶登錄時，系統的行為如圖3所示：

用戶登錄時，假設訪問為節點A的機器，A機器在驗證用戶的身份后，如通過，則將用戶已登錄的信息廣播，廣播后節點B，節點C也就收到了此信息，因此之后用戶訪問到節點B，也不會要求重新登錄。

（2）分布式緩存。對于需要緩存的狀態數據增多的情況，可采取分布式緩存的方案來解決，分布式緩存是指由多臺機器來構成一個緩存池，每臺機器上緩存一部分數據，采用分布式緩存后，當用戶登陸時，系統行為如圖4。

用戶登錄時訪問的是節點A機器，節點A機器在驗證通過了用戶信息后，將用戶的信息放入分布式緩存集群中的某臺機器上，當用戶登錄后訪問其他功能進入節點B機器時，節點B即可從分布式緩存集群的機器上尋找用戶登錄信息。

總之，對于分布式緩存而言，需要解決的是節點A和節點B在操作同一用戶登錄信息時能分布式緩存集群的同一臺機器上操作。

總線服務層中包括接入服務、配置服務、統計分析服務，這些業務服務系統是相對獨立的，不存在一個統一的標準。這里采用MuleESB將它們通過各種適配技術連接到ESB上來。ESB服務層中有MuleESB、tomcat服務器以及weblogic應用服務器。該層核心是ESB，它能夠實現最大程度的應用集成。客戶應用層對請求用戶操作結算系統提供用戶界面。

3.2 業務邏輯設計

3.2.1 系統中Web服務查詢流程：

（1）服務查詢者構建SOAP消息，發送給WebLogic應用服務器。

（2）如果沒有得到服務器響應，則連接失敗，調用結束。

（3）應用服務器收到查詢請求后，在后臺數據源中查找相應Web服務的信息。

（4）后臺數據源向應用服務器返回相應的查詢結果。

（5）應用服務器將結果以SOAP消息形式，返回給服務查詢者。

3.2.2 系統中MuleESB消息流程：

（1）外部應用程序服務發出請求消息后，消息接收器上的監聽進程監聽到該消息，消息接收器根據業務流程器定義文件中定義的配置信息，獲取訪問點URL。

（2）消息接收器通過解析訪問點URL，獲取所使用的連接器描述符。

（3）消息接收器根據連接器描述符的具體配置快速定位到相應的連接器。

（4）根據業務流程定義文件，如果訪問點URL上配置有消息轉換器，則轉5，否則轉6。

（5）連接器調用消息轉換器進行消息轉換。

（6）消息分配器獲得轉換后的消息，將該消息發送給外部應用程序服務接收或者消息路由器。

（7）流程結束。

4 結語

隨著國內外眾多研究機構、學者以及企業對CRM系統的研究的深入，關于CRM系統的研究已涌現出諸多成果。如學者李兵研究了CRM產品應用集成技術；國外SAP、SIEBEL、IBM等IT企業推出了CRM的解決方案，ORACLE等企業已把CRM系統的應用作為一個重要的發展方向。本論文討論了以下幾個問題：

（1）目前電信CRM系統使用的分布式通信的原理。

（2）研究實現SOA平臺的流行框架：ESB。

（3）研究電信集團CRM群集構建系統的原理及功能架構設計。

參考文獻

[1] 倪曉熔.電信企業ERP系統解決方案及應用[J].電信

網技術，2005，30（5）.

[2] 林昊.分布式Java應用[M].北京：電子工業出版社，2010.

[3] 賀新征.Oracle Weblogic Server 開發權威指南[M].北京：清華大學出版社，2011.

[4] 曾海穎.客戶關系管理中的數據挖掘[D].南京航空航天大學， 2003.

作者簡介：杜劍勐（1980-），男（壯族），廣西柳州人，中國電信股份有限公司上海企業信息化運營中心工程師，碩士，研究方向：軟件工程。

群集是在多個應用服務器實例上同時運行相同的應用程序的行為，每個應用服務器都知道群集中的其他應用服務器。作為群集一部分的應用服務器稱為節點。群集中的節點必須能夠互相通信，從而進行有意義的操作，例如，復制狀態或提供故障轉移性能。由于群集離不開負載均衡，故先討論負載均衡技術。

2.1 負載均衡

負載均衡是通過多個應用服務器實例均衡傳入負載或并行請求的一種方式，從而使應用程序具有可擴展性和高可用性。擴展性是無須更改代碼，應用程序就可以添加硬件處理更多用戶負載的能力。因為可以對負載均衡器添加多個服務器，從而均衡負載增加應用程序可以處理的流量，因此負載均衡有助于擴展應用程序。高可用性是在服務器出現故障的情況下繼續處理請求的能力。

2.2 群集的拓撲和組成

群集由運行在一臺計算機或多臺計算機上的節點組成，群集節點的構造通常指的是群集的拓撲。當一個群集的節點位于不同計算機上時，群集是水平的。節點位于相同計算機上時，群集是垂直的。許多群集既可以是水平的，也可以是垂直的，如圖2所示：

圖2左上角是運行在服務器上的兩個應用服務器實例，對這些實例進行配置使其在相同的集群中運行，并建立一個垂直集群，右方的水平集群由運行在左方服務器上的一個應用服務器實例和一個運行在圖底部服務器上的應用服務器實例構成。混合群集也可以由運行在相同計算機或不同計算機上的應用服務器構成。

2.2.1 垂直集群

（1）支撐高訪問量。Web應用隨著訪問量的增長，通常其瓶頸會出現在CPU或者內存上，網絡IO或磁盤IO出現瓶頸的幾率較低，在此僅分析當增加CPU或內存時，應用如何做到線性增長。

（2）增加CPU。要做到增加CPU后系統的服務能力線性的增長，要求系統能夠隨著CPU的增加，響應速度提升或同時可用于處理請求的線程增加，需要解決以下三種情況才能提升系統支撐的訪問量：

一是鎖競爭激烈。鎖競爭激烈會造成多線程等待鎖，就算增加CPU，也不能讓線程得到更快處理，應對策略是盡可能降低系統中鎖競爭的現象，降低競爭后，可以提升響應速度也可以開啟更多線程支撐訪問量。

二是支撐并發請求的線程數固定。在Java應用中，依靠啟動多個線程來支撐高并發量，如啟動的線程數是固定的，那么即使CPU增加，系統的服務能力也不會得到提升，因此最佳的方法是根據CPU數計算出一個合理的線程數。

三是單線程任務。對于單線程任務，增加CPU不會帶來任何的提升，此時可以考慮按照CPU數對任務進行合理劃分，以能夠通過啟動多個線程來并行地將任務分解成多個任務完成。

（3）增加內存。要做到增加內存后系統的服務能力線性增長，要求系統能夠隨著內存的增加，響應速度提升，主要關注以下兩點。

一是Cache的集合大小固定。系統中通常會借助Cache來提升性能，而為了避免內存資源消耗過多，會限制用于Cache的集合的大小，如這個大小是固定的，那么即使增加了內存，Cache的數據也不會增多。

二是JVM堆內存是固定的。JVM堆通常是在啟動參數中設置的，因此有些時候可能會出現增加了內存，但JVM堆大小沒有調整。所以要避免GC造成CPU出現瓶頸。

2.2.2 水平集群。支撐高訪問量。對于水平集群而言，最佳情況是應用是無狀態的，但系統很難做到完全沒有狀態，業界通常采用一種稱為SNA的體系來指導如何構建無狀態的應用，SNA架構在實現時通常采用的方法是將有狀態的部分集中放入緩存或數據庫中，通常數據庫采用集中存儲的方式。對于java應用而言，通常可采取的方法如下：

（1）廣播同步。廣播同步通常基于Multicast實現，當用戶登錄時，系統的行為如圖3所示：

用戶登錄時，假設訪問為節點A的機器，A機器在驗證用戶的身份后，如通過，則將用戶已登錄的信息廣播，廣播后節點B，節點C也就收到了此信息，因此之后用戶訪問到節點B，也不會要求重新登錄。

（2）分布式緩存。對于需要緩存的狀態數據增多的情況，可采取分布式緩存的方案來解決，分布式緩存是指由多臺機器來構成一個緩存池，每臺機器上緩存一部分數據，采用分布式緩存后，當用戶登陸時，系統行為如圖4。

用戶登錄時訪問的是節點A機器，節點A機器在驗證通過了用戶信息后，將用戶的信息放入分布式緩存集群中的某臺機器上，當用戶登錄后訪問其他功能進入節點B機器時，節點B即可從分布式緩存集群的機器上尋找用戶登錄信息。

總之，對于分布式緩存而言，需要解決的是節點A和節點B在操作同一用戶登錄信息時能分布式緩存集群的同一臺機器上操作。

總線服務層中包括接入服務、配置服務、統計分析服務，這些業務服務系統是相對獨立的，不存在一個統一的標準。這里采用MuleESB將它們通過各種適配技術連接到ESB上來。ESB服務層中有MuleESB、tomcat服務器以及weblogic應用服務器。該層核心是ESB，它能夠實現最大程度的應用集成。客戶應用層對請求用戶操作結算系統提供用戶界面。

3.2 業務邏輯設計

3.2.1 系統中Web服務查詢流程：

（1）服務查詢者構建SOAP消息，發送給WebLogic應用服務器。

（2）如果沒有得到服務器響應，則連接失敗，調用結束。

（3）應用服務器收到查詢請求后，在后臺數據源中查找相應Web服務的信息。

（4）后臺數據源向應用服務器返回相應的查詢結果。

（5）應用服務器將結果以SOAP消息形式，返回給服務查詢者。

3.2.2 系統中MuleESB消息流程：

（1）外部應用程序服務發出請求消息后，消息接收器上的監聽進程監聽到該消息，消息接收器根據業務流程器定義文件中定義的配置信息，獲取訪問點URL。

（2）消息接收器通過解析訪問點URL，獲取所使用的連接器描述符。

（3）消息接收器根據連接器描述符的具體配置快速定位到相應的連接器。

（4）根據業務流程定義文件，如果訪問點URL上配置有消息轉換器，則轉5，否則轉6。

（5）連接器調用消息轉換器進行消息轉換。

（6）消息分配器獲得轉換后的消息，將該消息發送給外部應用程序服務接收或者消息路由器。

（7）流程結束。

4 結語

隨著國內外眾多研究機構、學者以及企業對CRM系統的研究的深入，關于CRM系統的研究已涌現出諸多成果。如學者李兵研究了CRM產品應用集成技術；國外SAP、SIEBEL、IBM等IT企業推出了CRM的解決方案，ORACLE等企業已把CRM系統的應用作為一個重要的發展方向。本論文討論了以下幾個問題：

（1）目前電信CRM系統使用的分布式通信的原理。

（2）研究實現SOA平臺的流行框架：ESB。

（3）研究電信集團CRM群集構建系統的原理及功能架構設計。

參考文獻

[1] 倪曉熔.電信企業ERP系統解決方案及應用[J].電信

網技術，2005，30（5）.

[2] 林昊.分布式Java應用[M].北京：電子工業出版社，2010.

[3] 賀新征.Oracle Weblogic Server 開發權威指南[M].北京：清華大學出版社，2011.

[4] 曾海穎.客戶關系管理中的數據挖掘[D].南京航空航天大學， 2003.

作者簡介：杜劍勐（1980-），男（壯族），廣西柳州人，中國電信股份有限公司上海企業信息化運營中心工程師，碩士，研究方向：軟件工程。