分布式架构在电信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-），男（壮族），广西柳州人，中国电信股份有限公司上海企业信息化运营中心工程师，硕士，研究方向：软件工程。