摘要：隨著科學(xué)技術(shù)日益進(jìn)步，CRM系統(tǒng)已經(jīng)成為電信行業(yè)競(jìng)爭(zhēng)中的核心競(jìng)爭(zhēng)力之一。文章根據(jù)現(xiàn)有的CRM系統(tǒng)的發(fā)展現(xiàn)狀，探討了CRM系統(tǒng)的基本架構(gòu)及該架構(gòu)的分布式原理，并對(duì)中國電信集團(tuán)CRM項(xiàng)目分布式實(shí)現(xiàn)做了分析，從而凸顯分布式架構(gòu)在CRM系統(tǒng)的運(yùn)用價(jià)值。

關(guān)鍵詞：CRM系統(tǒng)；分布式架構(gòu)；開源ESB

中圖分類號(hào)：TP272 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1009-2374（2014）27-0061-03

1 電信CRM系統(tǒng)架構(gòu)分析

1.1 系統(tǒng)分布式架構(gòu)原理

1.1.1 基于消息方式實(shí)現(xiàn)系統(tǒng)間通信。系統(tǒng)依靠發(fā)送消息來進(jìn)行通信，消息包括字節(jié)流、字節(jié)數(shù)組，甚至是java對(duì)象，系統(tǒng)接收到消息后則進(jìn)行相應(yīng)的業(yè)務(wù)處理。消息方式的系統(tǒng)通信，基于網(wǎng)絡(luò)協(xié)議，常用協(xié)議是TCP/IP和UDP/IP。

TCP/IP是一種可靠的網(wǎng)絡(luò)數(shù)據(jù)傳輸協(xié)議，它要求通信雙方首先建立連接，之后再進(jìn)行數(shù)據(jù)的傳輸，TCP/IP負(fù)責(zé)保證數(shù)據(jù)傳輸?shù)目煽啃裕〝?shù)據(jù)的可到達(dá)，數(shù)據(jù)到達(dá)的順序等，但由于需要保證連接及數(shù)據(jù)傳輸?shù)目煽浚虼丝赡軙?huì)犧牲一些性能。

UDP/IP是一種不保證數(shù)據(jù)一定到達(dá)的網(wǎng)絡(luò)傳輸協(xié)議，它并不直接給通信雙方建立連接，而是發(fā)送到網(wǎng)絡(luò)上進(jìn)行傳遞，由于它不建立連接，并且不能保證數(shù)據(jù)傳輸?shù)目煽浚虼诵阅苌舷鄬?duì)較好，但可能出現(xiàn)數(shù)據(jù)丟失。TCP/IP和UDP/IP可用于完成數(shù)據(jù)的傳輸，但要完成系統(tǒng)間通信，還需要對(duì)數(shù)據(jù)進(jìn)行處理，例如讀取和寫入數(shù)據(jù)，按照POSIX標(biāo)準(zhǔn)分為同步IO和異步IO兩種，其中同步IO最常用的是BIO和NIO。

從程序角度而言，BIO就是當(dāng)發(fā)起IO的讀或?qū)懖僮鲿r(shí)，均為阻塞方式，只有當(dāng)程序讀到了流或者流寫入操作系統(tǒng)后，才會(huì)釋放資源。NIO是基于事件驅(qū)動(dòng)思想的，程序角度而言，發(fā)起IO的讀或?qū)懖僮鲿r(shí)，是非阻塞的，java對(duì)TCP/IP和UDP/IP均支持，在網(wǎng)絡(luò)IO的操作上，jdk支持BIO和NIO兩種方式。

1.1.2 基于遠(yuǎn)程方法調(diào)用方式實(shí)現(xiàn)系統(tǒng)間通信。遠(yuǎn)程方法調(diào)用（RPC）是機(jī)器間不同進(jìn)程的過程調(diào)用，它使得運(yùn)行在多臺(tái)機(jī)器上的傳統(tǒng)進(jìn)程間實(shí)現(xiàn)相互通信成為可能，因此，為實(shí)現(xiàn)進(jìn)程或機(jī)器間的相互通信，RPC提供了一種較簡(jiǎn)單的方式。

同RPC相比，java中引入的遠(yuǎn)程方法調(diào)用（RMI），能夠?qū)崿F(xiàn)分布式對(duì)象通信，因此開發(fā)者可以將網(wǎng)絡(luò)使能代碼實(shí)現(xiàn)成純java對(duì)象，從而使用到OOP的強(qiáng)大功能，比如繼承、封裝及多態(tài)等特性。網(wǎng)絡(luò)或機(jī)器的不穩(wěn)定性。對(duì)于基于單JVM的應(yīng)用而言，一旦JVM癱瘓，則整個(gè)應(yīng)用將癱瘓。但是，對(duì)于分布式對(duì)象應(yīng)用而言，由于存在多個(gè)JVM協(xié)同工作，因此即使某個(gè)JVM癱瘓，也不會(huì)對(duì)業(yè)務(wù)系統(tǒng)造成任何影響，在遠(yuǎn)程方法調(diào)用場(chǎng)合，為保證網(wǎng)絡(luò)或機(jī)器的穩(wěn)定性，需要提供一致的編程模型處理突發(fā)事件，比如JVM癱瘓，機(jī)器癱瘓，網(wǎng)絡(luò)不穩(wěn)定，在代碼處理遠(yuǎn)程調(diào)用時(shí)，一旦發(fā)生了任何遠(yuǎn)程異常事件，必須告知應(yīng)用。顯然，為完成遠(yuǎn)程調(diào)用，需要解決大量的底層問題。由于RMI屏蔽了大量的底層細(xì)節(jié)問題，因此可以快速構(gòu)建出健壯的分布式應(yīng)用。

1.2 系統(tǒng)分布式架構(gòu)實(shí)現(xiàn)

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

平臺(tái)。

1.2.1 ESB優(yōu)勢(shì)。

面向服務(wù)的架構(gòu)：分布式的應(yīng)用由可重用的服務(wù)組成。

面向消息的架構(gòu)：應(yīng)用之間通過ESB發(fā)送和接受消息。

事件驅(qū)動(dòng)的架構(gòu)：應(yīng)用之間異步的產(chǎn)生和接收消息。

1.2.2 ESB工作原理。核心思想基于消息中間件來實(shí)現(xiàn)系統(tǒng)間的交互?；谙⒅虚g件所構(gòu)建的系統(tǒng)交互的中間場(chǎng)所稱為總線，系統(tǒng)間交互的數(shù)據(jù)格式采用統(tǒng)一的消息格式，由總線完成消息的轉(zhuǎn)化、路由，發(fā)送到相應(yīng)的目標(biāo)應(yīng)用，ESB系統(tǒng)結(jié)構(gòu)如圖1所示：

（1）標(biāo)準(zhǔn)的消息通信格式。ESB框架定義系統(tǒng)發(fā)送及接收消息時(shí)的消息格式，以便各個(gè)系統(tǒng)保持一樣的方式與總線通信。

（2）消息路由。當(dāng)總線收到消息后，根據(jù)消息的數(shù)據(jù)決定發(fā)送到哪個(gè)系統(tǒng)，在更復(fù)雜的情況下，還可以基于消息路由實(shí)現(xiàn)功能編排，即當(dāng)某個(gè)功能需要由多個(gè)系統(tǒng)共同完成時(shí)，可在總線上以流程的方式編排訪問系統(tǒng)的順序。

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

2 中國電信集團(tuán)CRM項(xiàng)目分布式部署方案

群集是在多個(gè)應(yīng)用服務(wù)器實(shí)例上同時(shí)運(yùn)行相同的應(yīng)用程序的行為，每個(gè)應(yīng)用服務(wù)器都知道群集中的其他應(yīng)用服務(wù)器。作為群集一部分的應(yīng)用服務(wù)器稱為節(jié)點(diǎn)。群集中的節(jié)點(diǎn)必須能夠互相通信，從而進(jìn)行有意義的操作，例如，復(fù)制狀態(tài)或提供故障轉(zhuǎn)移性能。由于群集離不開負(fù)載均衡，故先討論負(fù)載均衡技術(shù)。

2.1 負(fù)載均衡

負(fù)載均衡是通過多個(gè)應(yīng)用服務(wù)器實(shí)例均衡傳入負(fù)載或并行請(qǐng)求的一種方式，從而使應(yīng)用程序具有可擴(kuò)展性和高可用性。擴(kuò)展性是無須更改代碼，應(yīng)用程序就可以添加硬件處理更多用戶負(fù)載的能力。因?yàn)榭梢詫?duì)負(fù)載均衡器添加多個(gè)服務(wù)器，從而均衡負(fù)載增加應(yīng)用程序可以處理的流量，因此負(fù)載均衡有助于擴(kuò)展應(yīng)用程序。高可用性是在服務(wù)器出現(xiàn)故障的情況下繼續(xù)處理請(qǐng)求的能力。

2.2 群集的拓?fù)浜徒M成

群集由運(yùn)行在一臺(tái)計(jì)算機(jī)或多臺(tái)計(jì)算機(jī)上的節(jié)點(diǎn)組成，群集節(jié)點(diǎn)的構(gòu)造通常指的是群集的拓?fù)洹．?dāng)一個(gè)群集的節(jié)點(diǎn)位于不同計(jì)算機(jī)上時(shí)，群集是水平的。節(jié)點(diǎn)位于相同計(jì)算機(jī)上時(shí)，群集是垂直的。許多群集既可以是水平的，也可以是垂直的，如圖2所示：

圖2左上角是運(yùn)行在服務(wù)器上的兩個(gè)應(yīng)用服務(wù)器實(shí)例，對(duì)這些實(shí)例進(jìn)行配置使其在相同的集群中運(yùn)行，并建立一個(gè)垂直集群，右方的水平集群由運(yùn)行在左方服務(wù)器上的一個(gè)應(yīng)用服務(wù)器實(shí)例和一個(gè)運(yùn)行在圖底部服務(wù)器上的應(yīng)用服務(wù)器實(shí)例構(gòu)成?；旌先杭部梢杂蛇\(yùn)行在相同計(jì)算機(jī)或不同計(jì)算機(jī)上的應(yīng)用服務(wù)器構(gòu)成。

2.2.1 垂直集群

（1）支撐高訪問量。Web應(yīng)用隨著訪問量的增長，通常其瓶頸會(huì)出現(xiàn)在CPU或者內(nèi)存上，網(wǎng)絡(luò)IO或磁盤IO出現(xiàn)瓶頸的幾率較低，在此僅分析當(dāng)增加CPU或內(nèi)存時(shí)，應(yīng)用如何做到線性增長。

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

一是鎖競(jìng)爭(zhēng)激烈。鎖競(jìng)爭(zhēng)激烈會(huì)造成多線程等待鎖，就算增加CPU，也不能讓線程得到更快處理，應(yīng)對(duì)策略是盡可能降低系統(tǒng)中鎖競(jìng)爭(zhēng)的現(xiàn)象，降低競(jìng)爭(zhēng)后，可以提升響應(yīng)速度也可以開啟更多線程支撐訪問量。

二是支撐并發(fā)請(qǐng)求的線程數(shù)固定。在Java應(yīng)用中，依靠啟動(dòng)多個(gè)線程來支撐高并發(fā)量，如啟動(dòng)的線程數(shù)是固定的，那么即使CPU增加，系統(tǒng)的服務(wù)能力也不會(huì)得到提升，因此最佳的方法是根據(jù)CPU數(shù)計(jì)算出一個(gè)合理的線程數(shù)。

三是單線程任務(wù)。對(duì)于單線程任務(wù)，增加CPU不會(huì)帶來任何的提升，此時(shí)可以考慮按照CPU數(shù)對(duì)任務(wù)進(jìn)行合理劃分，以能夠通過啟動(dòng)多個(gè)線程來并行地將任務(wù)分解成多個(gè)任務(wù)完成。

（3）增加內(nèi)存。要做到增加內(nèi)存后系統(tǒng)的服務(wù)能力線性增長，要求系統(tǒng)能夠隨著內(nèi)存的增加，響應(yīng)速度提升，主要關(guān)注以下兩點(diǎn)。

一是Cache的集合大小固定。系統(tǒng)中通常會(huì)借助Cache來提升性能，而為了避免內(nèi)存資源消耗過多，會(huì)限制用于Cache的集合的大小，如這個(gè)大小是固定的，那么即使增加了內(nèi)存，Cache的數(shù)據(jù)也不會(huì)增多。

二是JVM堆內(nèi)存是固定的。JVM堆通常是在啟動(dòng)參數(shù)中設(shè)置的，因此有些時(shí)候可能會(huì)出現(xiàn)增加了內(nèi)存，但JVM堆大小沒有調(diào)整。所以要避免GC造成CPU出現(xiàn)瓶頸。

2.2.2 水平集群。支撐高訪問量。對(duì)于水平集群而言，最佳情況是應(yīng)用是無狀態(tài)的，但系統(tǒng)很難做到完全沒有狀態(tài)，業(yè)界通常采用一種稱為SNA的體系來指導(dǎo)如何構(gòu)建無狀態(tài)的應(yīng)用，SNA架構(gòu)在實(shí)現(xiàn)時(shí)通常采用的方法是將有狀態(tài)的部分集中放入緩存或數(shù)據(jù)庫中，通常數(shù)據(jù)庫采用集中存儲(chǔ)的方式。對(duì)于java應(yīng)用而言，通?？刹扇〉姆椒ㄈ缦拢?/p>

（1）廣播同步。廣播同步通?；贛ulticast實(shí)現(xiàn)，當(dāng)用戶登錄時(shí)，系統(tǒng)的行為如圖3所示：

用戶登錄時(shí)，假設(shè)訪問為節(jié)點(diǎn)A的機(jī)器，A機(jī)器在驗(yàn)證用戶的身份后，如通過，則將用戶已登錄的信息廣播，廣播后節(jié)點(diǎn)B，節(jié)點(diǎn)C也就收到了此信息，因此之后用戶訪問到節(jié)點(diǎn)B，也不會(huì)要求重新登錄。

（2）分布式緩存。對(duì)于需要緩存的狀態(tài)數(shù)據(jù)增多的情況，可采取分布式緩存的方案來解決，分布式緩存是指由多臺(tái)機(jī)器來構(gòu)成一個(gè)緩存池，每臺(tái)機(jī)器上緩存一部分?jǐn)?shù)據(jù)，采用分布式緩存后，當(dāng)用戶登陸時(shí)，系統(tǒng)行為如圖4。

用戶登錄時(shí)訪問的是節(jié)點(diǎn)A機(jī)器，節(jié)點(diǎn)A機(jī)器在驗(yàn)證通過了用戶信息后，將用戶的信息放入分布式緩存集群中的某臺(tái)機(jī)器上，當(dāng)用戶登錄后訪問其他功能進(jìn)入節(jié)點(diǎn)B機(jī)器時(shí)，節(jié)點(diǎn)B即可從分布式緩存集群的機(jī)器上尋找用戶登錄信息。

總之，對(duì)于分布式緩存而言，需要解決的是節(jié)點(diǎn)A和節(jié)點(diǎn)B在操作同一用戶登錄信息時(shí)能分布式緩存集群的同一臺(tái)機(jī)器上操作。

總線服務(wù)層中包括接入服務(wù)、配置服務(wù)、統(tǒng)計(jì)分析服務(wù)，這些業(yè)務(wù)服務(wù)系統(tǒng)是相對(duì)獨(dú)立的，不存在一個(gè)統(tǒng)一的標(biāo)準(zhǔn)。這里采用MuleESB將它們通過各種適配技術(shù)連接到ESB上來。ESB服務(wù)層中有MuleESB、tomcat服務(wù)器以及weblogic應(yīng)用服務(wù)器。該層核心是ESB，它能夠?qū)崿F(xiàn)最大程度的應(yīng)用集成。客戶應(yīng)用層對(duì)請(qǐng)求用戶操作結(jié)算系統(tǒng)提供用戶界面。

3.2 業(yè)務(wù)邏輯設(shè)計(jì)

3.2.1 系統(tǒng)中Web服務(wù)查詢流程：

（1）服務(wù)查詢者構(gòu)建SOAP消息，發(fā)送給WebLogic應(yīng)用服務(wù)器。

（2）如果沒有得到服務(wù)器響應(yīng)，則連接失敗，調(diào)用結(jié)束。

（3）應(yīng)用服務(wù)器收到查詢請(qǐng)求后，在后臺(tái)數(shù)據(jù)源中查找相應(yīng)Web服務(wù)的信息。

（4）后臺(tái)數(shù)據(jù)源向應(yīng)用服務(wù)器返回相應(yīng)的查詢結(jié)果。

（5）應(yīng)用服務(wù)器將結(jié)果以SOAP消息形式，返回給服務(wù)查詢者。

3.2.2 系統(tǒng)中MuleESB消息流程：

（1）外部應(yīng)用程序服務(wù)發(fā)出請(qǐng)求消息后，消息接收器上的監(jiān)聽進(jìn)程監(jiān)聽到該消息，消息接收器根據(jù)業(yè)務(wù)流程器定義文件中定義的配置信息，獲取訪問點(diǎn)URL。

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

（3）消息接收器根據(jù)連接器描述符的具體配置快速定位到相應(yīng)的連接器。

（4）根據(jù)業(yè)務(wù)流程定義文件，如果訪問點(diǎn)URL上配置有消息轉(zhuǎn)換器，則轉(zhuǎn)5，否則轉(zhuǎn)6。

（5）連接器調(diào)用消息轉(zhuǎn)換器進(jìn)行消息轉(zhuǎn)換。

（6）消息分配器獲得轉(zhuǎn)換后的消息，將該消息發(fā)送給外部應(yīng)用程序服務(wù)接收或者消息路由器。

（7）流程結(jié)束。

4 結(jié)語

隨著國內(nèi)外眾多研究機(jī)構(gòu)、學(xué)者以及企業(yè)對(duì)CRM系統(tǒng)的研究的深入，關(guān)于CRM系統(tǒng)的研究已涌現(xiàn)出諸多成果。如學(xué)者李兵研究了CRM產(chǎn)品應(yīng)用集成技術(shù)；國外SAP、SIEBEL、IBM等IT企業(yè)推出了CRM的解決方案，ORACLE等企業(yè)已把CRM系統(tǒng)的應(yīng)用作為一個(gè)重要的發(fā)展方向。本論文討論了以下幾個(gè)問題：

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

（2）研究實(shí)現(xiàn)SOA平臺(tái)的流行框架：ESB。

（3）研究電信集團(tuán)CRM群集構(gòu)建系統(tǒng)的原理及功能架構(gòu)設(shè)計(jì)。

參考文獻(xiàn)

[1] 倪曉熔.電信企業(yè)ERP系統(tǒng)解決方案及應(yīng)用[J].電信

網(wǎng)技術(shù)，2005，30（5）.

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

[3] 賀新征.Oracle Weblogic Server 開發(fā)權(quán)威指南[M].北京：清華大學(xué)出版社，2011.

[4] 曾海穎.客戶關(guān)系管理中的數(shù)據(jù)挖掘[D].南京航空航天大學(xué)， 2003.

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

群集是在多個(gè)應(yīng)用服務(wù)器實(shí)例上同時(shí)運(yùn)行相同的應(yīng)用程序的行為，每個(gè)應(yīng)用服務(wù)器都知道群集中的其他應(yīng)用服務(wù)器。作為群集一部分的應(yīng)用服務(wù)器稱為節(jié)點(diǎn)。群集中的節(jié)點(diǎn)必須能夠互相通信，從而進(jìn)行有意義的操作，例如，復(fù)制狀態(tài)或提供故障轉(zhuǎn)移性能。由于群集離不開負(fù)載均衡，故先討論負(fù)載均衡技術(shù)。

2.1 負(fù)載均衡

負(fù)載均衡是通過多個(gè)應(yīng)用服務(wù)器實(shí)例均衡傳入負(fù)載或并行請(qǐng)求的一種方式，從而使應(yīng)用程序具有可擴(kuò)展性和高可用性。擴(kuò)展性是無須更改代碼，應(yīng)用程序就可以添加硬件處理更多用戶負(fù)載的能力。因?yàn)榭梢詫?duì)負(fù)載均衡器添加多個(gè)服務(wù)器，從而均衡負(fù)載增加應(yīng)用程序可以處理的流量，因此負(fù)載均衡有助于擴(kuò)展應(yīng)用程序。高可用性是在服務(wù)器出現(xiàn)故障的情況下繼續(xù)處理請(qǐng)求的能力。

2.2 群集的拓?fù)浜徒M成

群集由運(yùn)行在一臺(tái)計(jì)算機(jī)或多臺(tái)計(jì)算機(jī)上的節(jié)點(diǎn)組成，群集節(jié)點(diǎn)的構(gòu)造通常指的是群集的拓?fù)洹．?dāng)一個(gè)群集的節(jié)點(diǎn)位于不同計(jì)算機(jī)上時(shí)，群集是水平的。節(jié)點(diǎn)位于相同計(jì)算機(jī)上時(shí)，群集是垂直的。許多群集既可以是水平的，也可以是垂直的，如圖2所示：

圖2左上角是運(yùn)行在服務(wù)器上的兩個(gè)應(yīng)用服務(wù)器實(shí)例，對(duì)這些實(shí)例進(jìn)行配置使其在相同的集群中運(yùn)行，并建立一個(gè)垂直集群，右方的水平集群由運(yùn)行在左方服務(wù)器上的一個(gè)應(yīng)用服務(wù)器實(shí)例和一個(gè)運(yùn)行在圖底部服務(wù)器上的應(yīng)用服務(wù)器實(shí)例構(gòu)成?；旌先杭部梢杂蛇\(yùn)行在相同計(jì)算機(jī)或不同計(jì)算機(jī)上的應(yīng)用服務(wù)器構(gòu)成。

2.2.1 垂直集群

（1）支撐高訪問量。Web應(yīng)用隨著訪問量的增長，通常其瓶頸會(huì)出現(xiàn)在CPU或者內(nèi)存上，網(wǎng)絡(luò)IO或磁盤IO出現(xiàn)瓶頸的幾率較低，在此僅分析當(dāng)增加CPU或內(nèi)存時(shí)，應(yīng)用如何做到線性增長。

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

一是鎖競(jìng)爭(zhēng)激烈。鎖競(jìng)爭(zhēng)激烈會(huì)造成多線程等待鎖，就算增加CPU，也不能讓線程得到更快處理，應(yīng)對(duì)策略是盡可能降低系統(tǒng)中鎖競(jìng)爭(zhēng)的現(xiàn)象，降低競(jìng)爭(zhēng)后，可以提升響應(yīng)速度也可以開啟更多線程支撐訪問量。

二是支撐并發(fā)請(qǐng)求的線程數(shù)固定。在Java應(yīng)用中，依靠啟動(dòng)多個(gè)線程來支撐高并發(fā)量，如啟動(dòng)的線程數(shù)是固定的，那么即使CPU增加，系統(tǒng)的服務(wù)能力也不會(huì)得到提升，因此最佳的方法是根據(jù)CPU數(shù)計(jì)算出一個(gè)合理的線程數(shù)。

三是單線程任務(wù)。對(duì)于單線程任務(wù)，增加CPU不會(huì)帶來任何的提升，此時(shí)可以考慮按照CPU數(shù)對(duì)任務(wù)進(jìn)行合理劃分，以能夠通過啟動(dòng)多個(gè)線程來并行地將任務(wù)分解成多個(gè)任務(wù)完成。

（3）增加內(nèi)存。要做到增加內(nèi)存后系統(tǒng)的服務(wù)能力線性增長，要求系統(tǒng)能夠隨著內(nèi)存的增加，響應(yīng)速度提升，主要關(guān)注以下兩點(diǎn)。

一是Cache的集合大小固定。系統(tǒng)中通常會(huì)借助Cache來提升性能，而為了避免內(nèi)存資源消耗過多，會(huì)限制用于Cache的集合的大小，如這個(gè)大小是固定的，那么即使增加了內(nèi)存，Cache的數(shù)據(jù)也不會(huì)增多。

二是JVM堆內(nèi)存是固定的。JVM堆通常是在啟動(dòng)參數(shù)中設(shè)置的，因此有些時(shí)候可能會(huì)出現(xiàn)增加了內(nèi)存，但JVM堆大小沒有調(diào)整。所以要避免GC造成CPU出現(xiàn)瓶頸。

2.2.2 水平集群。支撐高訪問量。對(duì)于水平集群而言，最佳情況是應(yīng)用是無狀態(tài)的，但系統(tǒng)很難做到完全沒有狀態(tài)，業(yè)界通常采用一種稱為SNA的體系來指導(dǎo)如何構(gòu)建無狀態(tài)的應(yīng)用，SNA架構(gòu)在實(shí)現(xiàn)時(shí)通常采用的方法是將有狀態(tài)的部分集中放入緩存或數(shù)據(jù)庫中，通常數(shù)據(jù)庫采用集中存儲(chǔ)的方式。對(duì)于java應(yīng)用而言，通常可采取的方法如下：

（1）廣播同步。廣播同步通?；贛ulticast實(shí)現(xiàn)，當(dāng)用戶登錄時(shí)，系統(tǒng)的行為如圖3所示：

用戶登錄時(shí)，假設(shè)訪問為節(jié)點(diǎn)A的機(jī)器，A機(jī)器在驗(yàn)證用戶的身份后，如通過，則將用戶已登錄的信息廣播，廣播后節(jié)點(diǎn)B，節(jié)點(diǎn)C也就收到了此信息，因此之后用戶訪問到節(jié)點(diǎn)B，也不會(huì)要求重新登錄。

（2）分布式緩存。對(duì)于需要緩存的狀態(tài)數(shù)據(jù)增多的情況，可采取分布式緩存的方案來解決，分布式緩存是指由多臺(tái)機(jī)器來構(gòu)成一個(gè)緩存池，每臺(tái)機(jī)器上緩存一部分?jǐn)?shù)據(jù)，采用分布式緩存后，當(dāng)用戶登陸時(shí)，系統(tǒng)行為如圖4。

用戶登錄時(shí)訪問的是節(jié)點(diǎn)A機(jī)器，節(jié)點(diǎn)A機(jī)器在驗(yàn)證通過了用戶信息后，將用戶的信息放入分布式緩存集群中的某臺(tái)機(jī)器上，當(dāng)用戶登錄后訪問其他功能進(jìn)入節(jié)點(diǎn)B機(jī)器時(shí)，節(jié)點(diǎn)B即可從分布式緩存集群的機(jī)器上尋找用戶登錄信息。

總之，對(duì)于分布式緩存而言，需要解決的是節(jié)點(diǎn)A和節(jié)點(diǎn)B在操作同一用戶登錄信息時(shí)能分布式緩存集群的同一臺(tái)機(jī)器上操作。

總線服務(wù)層中包括接入服務(wù)、配置服務(wù)、統(tǒng)計(jì)分析服務(wù)，這些業(yè)務(wù)服務(wù)系統(tǒng)是相對(duì)獨(dú)立的，不存在一個(gè)統(tǒng)一的標(biāo)準(zhǔn)。這里采用MuleESB將它們通過各種適配技術(shù)連接到ESB上來。ESB服務(wù)層中有MuleESB、tomcat服務(wù)器以及weblogic應(yīng)用服務(wù)器。該層核心是ESB，它能夠?qū)崿F(xiàn)最大程度的應(yīng)用集成?？蛻魬?yīng)用層對(duì)請(qǐng)求用戶操作結(jié)算系統(tǒng)提供用戶界面。

3.2 業(yè)務(wù)邏輯設(shè)計(jì)

3.2.1 系統(tǒng)中Web服務(wù)查詢流程：

（1）服務(wù)查詢者構(gòu)建SOAP消息，發(fā)送給WebLogic應(yīng)用服務(wù)器。

（2）如果沒有得到服務(wù)器響應(yīng)，則連接失敗，調(diào)用結(jié)束。

（3）應(yīng)用服務(wù)器收到查詢請(qǐng)求后，在后臺(tái)數(shù)據(jù)源中查找相應(yīng)Web服務(wù)的信息。

（4）后臺(tái)數(shù)據(jù)源向應(yīng)用服務(wù)器返回相應(yīng)的查詢結(jié)果。

（5）應(yīng)用服務(wù)器將結(jié)果以SOAP消息形式，返回給服務(wù)查詢者。

3.2.2 系統(tǒng)中MuleESB消息流程：

（1）外部應(yīng)用程序服務(wù)發(fā)出請(qǐng)求消息后，消息接收器上的監(jiān)聽進(jìn)程監(jiān)聽到該消息，消息接收器根據(jù)業(yè)務(wù)流程器定義文件中定義的配置信息，獲取訪問點(diǎn)URL。

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

（3）消息接收器根據(jù)連接器描述符的具體配置快速定位到相應(yīng)的連接器。

（4）根據(jù)業(yè)務(wù)流程定義文件，如果訪問點(diǎn)URL上配置有消息轉(zhuǎn)換器，則轉(zhuǎn)5，否則轉(zhuǎn)6。

（5）連接器調(diào)用消息轉(zhuǎn)換器進(jìn)行消息轉(zhuǎn)換。

（6）消息分配器獲得轉(zhuǎn)換后的消息，將該消息發(fā)送給外部應(yīng)用程序服務(wù)接收或者消息路由器。

（7）流程結(jié)束。

4 結(jié)語

隨著國內(nèi)外眾多研究機(jī)構(gòu)、學(xué)者以及企業(yè)對(duì)CRM系統(tǒng)的研究的深入，關(guān)于CRM系統(tǒng)的研究已涌現(xiàn)出諸多成果。如學(xué)者李兵研究了CRM產(chǎn)品應(yīng)用集成技術(shù)；國外SAP、SIEBEL、IBM等IT企業(yè)推出了CRM的解決方案，ORACLE等企業(yè)已把CRM系統(tǒng)的應(yīng)用作為一個(gè)重要的發(fā)展方向。本論文討論了以下幾個(gè)問題：

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

（2）研究實(shí)現(xiàn)SOA平臺(tái)的流行框架：ESB。

（3）研究電信集團(tuán)CRM群集構(gòu)建系統(tǒng)的原理及功能架構(gòu)設(shè)計(jì)。

參考文獻(xiàn)

[1] 倪曉熔.電信企業(yè)ERP系統(tǒng)解決方案及應(yīng)用[J].電信

網(wǎng)技術(shù)，2005，30（5）.

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

[3] 賀新征.Oracle Weblogic Server 開發(fā)權(quán)威指南[M].北京：清華大學(xué)出版社，2011.

[4] 曾海穎.客戶關(guān)系管理中的數(shù)據(jù)挖掘[D].南京航空航天大學(xué)， 2003.

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

群集是在多個(gè)應(yīng)用服務(wù)器實(shí)例上同時(shí)運(yùn)行相同的應(yīng)用程序的行為，每個(gè)應(yīng)用服務(wù)器都知道群集中的其他應(yīng)用服務(wù)器。作為群集一部分的應(yīng)用服務(wù)器稱為節(jié)點(diǎn)。群集中的節(jié)點(diǎn)必須能夠互相通信，從而進(jìn)行有意義的操作，例如，復(fù)制狀態(tài)或提供故障轉(zhuǎn)移性能。由于群集離不開負(fù)載均衡，故先討論負(fù)載均衡技術(shù)。

2.1 負(fù)載均衡

負(fù)載均衡是通過多個(gè)應(yīng)用服務(wù)器實(shí)例均衡傳入負(fù)載或并行請(qǐng)求的一種方式，從而使應(yīng)用程序具有可擴(kuò)展性和高可用性。擴(kuò)展性是無須更改代碼，應(yīng)用程序就可以添加硬件處理更多用戶負(fù)載的能力。因?yàn)榭梢詫?duì)負(fù)載均衡器添加多個(gè)服務(wù)器，從而均衡負(fù)載增加應(yīng)用程序可以處理的流量，因此負(fù)載均衡有助于擴(kuò)展應(yīng)用程序。高可用性是在服務(wù)器出現(xiàn)故障的情況下繼續(xù)處理請(qǐng)求的能力。

2.2 群集的拓?fù)浜徒M成

群集由運(yùn)行在一臺(tái)計(jì)算機(jī)或多臺(tái)計(jì)算機(jī)上的節(jié)點(diǎn)組成，群集節(jié)點(diǎn)的構(gòu)造通常指的是群集的拓?fù)?。?dāng)一個(gè)群集的節(jié)點(diǎn)位于不同計(jì)算機(jī)上時(shí)，群集是水平的。節(jié)點(diǎn)位于相同計(jì)算機(jī)上時(shí)，群集是垂直的。許多群集既可以是水平的，也可以是垂直的，如圖2所示：

圖2左上角是運(yùn)行在服務(wù)器上的兩個(gè)應(yīng)用服務(wù)器實(shí)例，對(duì)這些實(shí)例進(jìn)行配置使其在相同的集群中運(yùn)行，并建立一個(gè)垂直集群，右方的水平集群由運(yùn)行在左方服務(wù)器上的一個(gè)應(yīng)用服務(wù)器實(shí)例和一個(gè)運(yùn)行在圖底部服務(wù)器上的應(yīng)用服務(wù)器實(shí)例構(gòu)成?；旌先杭部梢杂蛇\(yùn)行在相同計(jì)算機(jī)或不同計(jì)算機(jī)上的應(yīng)用服務(wù)器構(gòu)成。

2.2.1 垂直集群

（1）支撐高訪問量。Web應(yīng)用隨著訪問量的增長，通常其瓶頸會(huì)出現(xiàn)在CPU或者內(nèi)存上，網(wǎng)絡(luò)IO或磁盤IO出現(xiàn)瓶頸的幾率較低，在此僅分析當(dāng)增加CPU或內(nèi)存時(shí)，應(yīng)用如何做到線性增長。

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

一是鎖競(jìng)爭(zhēng)激烈。鎖競(jìng)爭(zhēng)激烈會(huì)造成多線程等待鎖，就算增加CPU，也不能讓線程得到更快處理，應(yīng)對(duì)策略是盡可能降低系統(tǒng)中鎖競(jìng)爭(zhēng)的現(xiàn)象，降低競(jìng)爭(zhēng)后，可以提升響應(yīng)速度也可以開啟更多線程支撐訪問量。

二是支撐并發(fā)請(qǐng)求的線程數(shù)固定。在Java應(yīng)用中，依靠啟動(dòng)多個(gè)線程來支撐高并發(fā)量，如啟動(dòng)的線程數(shù)是固定的，那么即使CPU增加，系統(tǒng)的服務(wù)能力也不會(huì)得到提升，因此最佳的方法是根據(jù)CPU數(shù)計(jì)算出一個(gè)合理的線程數(shù)。

三是單線程任務(wù)。對(duì)于單線程任務(wù)，增加CPU不會(huì)帶來任何的提升，此時(shí)可以考慮按照CPU數(shù)對(duì)任務(wù)進(jìn)行合理劃分，以能夠通過啟動(dòng)多個(gè)線程來并行地將任務(wù)分解成多個(gè)任務(wù)完成。

（3）增加內(nèi)存。要做到增加內(nèi)存后系統(tǒng)的服務(wù)能力線性增長，要求系統(tǒng)能夠隨著內(nèi)存的增加，響應(yīng)速度提升，主要關(guān)注以下兩點(diǎn)。

一是Cache的集合大小固定。系統(tǒng)中通常會(huì)借助Cache來提升性能，而為了避免內(nèi)存資源消耗過多，會(huì)限制用于Cache的集合的大小，如這個(gè)大小是固定的，那么即使增加了內(nèi)存，Cache的數(shù)據(jù)也不會(huì)增多。

二是JVM堆內(nèi)存是固定的。JVM堆通常是在啟動(dòng)參數(shù)中設(shè)置的，因此有些時(shí)候可能會(huì)出現(xiàn)增加了內(nèi)存，但JVM堆大小沒有調(diào)整。所以要避免GC造成CPU出現(xiàn)瓶頸。

2.2.2 水平集群。支撐高訪問量。對(duì)于水平集群而言，最佳情況是應(yīng)用是無狀態(tài)的，但系統(tǒng)很難做到完全沒有狀態(tài)，業(yè)界通常采用一種稱為SNA的體系來指導(dǎo)如何構(gòu)建無狀態(tài)的應(yīng)用，SNA架構(gòu)在實(shí)現(xiàn)時(shí)通常采用的方法是將有狀態(tài)的部分集中放入緩存或數(shù)據(jù)庫中，通常數(shù)據(jù)庫采用集中存儲(chǔ)的方式。對(duì)于java應(yīng)用而言，通?？刹扇〉姆椒ㄈ缦拢?/p>

（1）廣播同步。廣播同步通?；贛ulticast實(shí)現(xiàn)，當(dāng)用戶登錄時(shí)，系統(tǒng)的行為如圖3所示：

用戶登錄時(shí)，假設(shè)訪問為節(jié)點(diǎn)A的機(jī)器，A機(jī)器在驗(yàn)證用戶的身份后，如通過，則將用戶已登錄的信息廣播，廣播后節(jié)點(diǎn)B，節(jié)點(diǎn)C也就收到了此信息，因此之后用戶訪問到節(jié)點(diǎn)B，也不會(huì)要求重新登錄。

（2）分布式緩存。對(duì)于需要緩存的狀態(tài)數(shù)據(jù)增多的情況，可采取分布式緩存的方案來解決，分布式緩存是指由多臺(tái)機(jī)器來構(gòu)成一個(gè)緩存池，每臺(tái)機(jī)器上緩存一部分?jǐn)?shù)據(jù)，采用分布式緩存后，當(dāng)用戶登陸時(shí)，系統(tǒng)行為如圖4。

用戶登錄時(shí)訪問的是節(jié)點(diǎn)A機(jī)器，節(jié)點(diǎn)A機(jī)器在驗(yàn)證通過了用戶信息后，將用戶的信息放入分布式緩存集群中的某臺(tái)機(jī)器上，當(dāng)用戶登錄后訪問其他功能進(jìn)入節(jié)點(diǎn)B機(jī)器時(shí)，節(jié)點(diǎn)B即可從分布式緩存集群的機(jī)器上尋找用戶登錄信息。

總之，對(duì)于分布式緩存而言，需要解決的是節(jié)點(diǎn)A和節(jié)點(diǎn)B在操作同一用戶登錄信息時(shí)能分布式緩存集群的同一臺(tái)機(jī)器上操作。

總線服務(wù)層中包括接入服務(wù)、配置服務(wù)、統(tǒng)計(jì)分析服務(wù)，這些業(yè)務(wù)服務(wù)系統(tǒng)是相對(duì)獨(dú)立的，不存在一個(gè)統(tǒng)一的標(biāo)準(zhǔn)。這里采用MuleESB將它們通過各種適配技術(shù)連接到ESB上來。ESB服務(wù)層中有MuleESB、tomcat服務(wù)器以及weblogic應(yīng)用服務(wù)器。該層核心是ESB，它能夠?qū)崿F(xiàn)最大程度的應(yīng)用集成?？蛻魬?yīng)用層對(duì)請(qǐng)求用戶操作結(jié)算系統(tǒng)提供用戶界面。

3.2 業(yè)務(wù)邏輯設(shè)計(jì)

3.2.1 系統(tǒng)中Web服務(wù)查詢流程：

（1）服務(wù)查詢者構(gòu)建SOAP消息，發(fā)送給WebLogic應(yīng)用服務(wù)器。

（2）如果沒有得到服務(wù)器響應(yīng)，則連接失敗，調(diào)用結(jié)束。

（3）應(yīng)用服務(wù)器收到查詢請(qǐng)求后，在后臺(tái)數(shù)據(jù)源中查找相應(yīng)Web服務(wù)的信息。

（4）后臺(tái)數(shù)據(jù)源向應(yīng)用服務(wù)器返回相應(yīng)的查詢結(jié)果。

（5）應(yīng)用服務(wù)器將結(jié)果以SOAP消息形式，返回給服務(wù)查詢者。

3.2.2 系統(tǒng)中MuleESB消息流程：

（1）外部應(yīng)用程序服務(wù)發(fā)出請(qǐng)求消息后，消息接收器上的監(jiān)聽進(jìn)程監(jiān)聽到該消息，消息接收器根據(jù)業(yè)務(wù)流程器定義文件中定義的配置信息，獲取訪問點(diǎn)URL。

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

（3）消息接收器根據(jù)連接器描述符的具體配置快速定位到相應(yīng)的連接器。

（4）根據(jù)業(yè)務(wù)流程定義文件，如果訪問點(diǎn)URL上配置有消息轉(zhuǎn)換器，則轉(zhuǎn)5，否則轉(zhuǎn)6。

（5）連接器調(diào)用消息轉(zhuǎn)換器進(jìn)行消息轉(zhuǎn)換。

（6）消息分配器獲得轉(zhuǎn)換后的消息，將該消息發(fā)送給外部應(yīng)用程序服務(wù)接收或者消息路由器。

（7）流程結(jié)束。

4 結(jié)語

隨著國內(nèi)外眾多研究機(jī)構(gòu)、學(xué)者以及企業(yè)對(duì)CRM系統(tǒng)的研究的深入，關(guān)于CRM系統(tǒng)的研究已涌現(xiàn)出諸多成果。如學(xué)者李兵研究了CRM產(chǎn)品應(yīng)用集成技術(shù)；國外SAP、SIEBEL、IBM等IT企業(yè)推出了CRM的解決方案，ORACLE等企業(yè)已把CRM系統(tǒng)的應(yīng)用作為一個(gè)重要的發(fā)展方向。本論文討論了以下幾個(gè)問題：

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

（2）研究實(shí)現(xiàn)SOA平臺(tái)的流行框架：ESB。

（3）研究電信集團(tuán)CRM群集構(gòu)建系統(tǒng)的原理及功能架構(gòu)設(shè)計(jì)。

參考文獻(xiàn)

[1] 倪曉熔.電信企業(yè)ERP系統(tǒng)解決方案及應(yīng)用[J].電信

網(wǎng)技術(shù)，2005，30（5）.

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

[3] 賀新征.Oracle Weblogic Server 開發(fā)權(quán)威指南[M].北京：清華大學(xué)出版社，2011.

[4] 曾海穎.客戶關(guān)系管理中的數(shù)據(jù)挖掘[D].南京航空航天大學(xué)， 2003.

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