中国移动（深圳）有限公司 | 肖中卿 郑锡涛 付兵兰

新一代计费清算系统引入SOA，打破原有封闭式架构，实现计费清算服务可复用，通过构建统一服务接入框架，降低遗留系统接入新架构的接入成本，为计费清算系统集中化运营运维提供了技术保障。

近年来，互联网尤其是移动互联网的迅猛发展给传统电信业带来了极大挑战，业界正式进入无边界竞争时代。作为业务支撑系统核心的计费清算系统也日益不能满足大数据、大业务量的支撑要求，迫切需要进行变革升级。

深圳公司承担着全集团漫游清算业务的集中清结算处理，并对国际运营商提供漫游清算服务。随着业务的迅速扩张，深圳公司形成了三套清算系统，十多条业务线的运营规模，每条业务线均独立建设，这种粗放的烟囱式建设，虽然快速地满足了一段时期内的业务需求，然而随着系统的增多，系统间依赖越来越多，越来越复杂，同时由于封闭式的架构，造成已有资源复用难度大，运营运维成本高昂。在此背景下，要求新一代计费清算系统架构，具备以下能力：

1.集中化支撑能力。提供统一的公共基础平台和通用业务能力，对原有独立建设的清算业务线进行融合，降低建设与维护成本。

2.分布式云化能力。从传统集中计算架构向分布式云化架构演进，降低总体成本，提升并发处理能力，适应大数据时代流量经营要求。

3.标准化，集中化运营。打造以客户感知为中心的界面，改善客户体验，通过产品模型构建，实现产品灵活组合，促进标准化，具备个性化定制能力。

4.开放共享能力。从封闭系统向“生态系统”的共享开放平台转型，整合价值链，提升协同能力。

针对以上服务化、分布式云化的要求，采用SOA技术并结合云计算技术进行架构规划与设计是可选方案之一。

图1 新一代计费清算系统应用架构

系统架构

新一代计费清算系统架构规划过程中，采用TOGAF方法论对现有计费清算系统基线架构进行梳理，并对目标业务架构、应用架构、数据架构技术架构进行规划。

根据业务架构规划，按照CBM方法论，结合TMF的eTom模型及集团NGBOSS模型，将业务域划分为服务支撑域、产品运营域、客户运营域、运营分析域与运营管理域，相应了为了满足对业务架构的支撑，应用架构划分为服务支撑平台、产品运营平台、客户运营平台、数据分析平台、运营管理平台，如图1所示。

图2 数据清算一级流程

服务支撑平台：服务支撑平台提供可重用的基础计费清算服务，为产品运营提供可选的计费清算服务，并保证所提供服务满足服务质量的要求。

产品运营平台：产品运营平台以产品为中心组织产品、服务、资源等相关业务过程和业务能力，实现清算服务能力的产品化交付，并实现业务的产品化运营。

客户运营平台：客户运营平台以客户为中心组织营销、服务、收入相关的业务过程和业务能力，将计费清算产品推广到客户端，实现面向客户的运营，快速响应客户请求，以提升客户满意度和贡献度。

运营管理平台：面向运营管理人员，实现对服务支撑、产品运营、客户运营进行管理、评价和改进，实现计费清算流程的运营和管理，为运营管理人员提供统一的管控视图。

数据分析平台：基于基础运营数据为客户或管理者提供经营分析、运营分析和管理决策，提供统一、专业、智能的分析能力。

图3 文件预处理子流程

系统设计与实现

新一代计费清算系统SOA架构，采用Oracle SOA Suite 11g进行具体落地实施。本节将从流程、服务、组件的实现不同层面对整体SOA架构的设计与实现进行详细描述。

设计原则

由于SOA架构与传统架构在架构理念和风格上都有不同，需要在实施前期明确相应的设计原则，结合SOA设计理论与具体实践，我们总结的新架构需要遵循的设计原则包括：

1.服务无状态原则。在无特别需求的情况下，服务不能长期保存当次服务请求的中间处理状态信息，是服务状态无关。

2.服务可重用性原则。服务须尽量设计为可重用服务，可重用服务接口设计不能包含特定服务消费者的假设。

3.服务标准化原则。要求对服务的规约进行标准化，保持统一的设计风格。

4.服务松耦合原则。消费者不与具体实现相耦合，服务规约不与具体服务实现相耦合。

5.服务抽象原则。服务规约仅仅暴露消费者需要的信息。

消息定义规范

新一代计费清算系统各平台遵循SOA规范，采用XML格式进行消息编码，采用xsd格式进行消息定义。消息文本采用UTF-8进行编码。统一的消息定义包括消息头和消息体，消息头定义各平台均需要遵守的消息字段。

请求消息头详细定义。包含流程上下文协调ID，服务请求编号，服务消费者，业务流水号，业务受理时间，事务性标志，事务ID，客户代码，产品代码，服务名称，服务调用方法名称，平台编号，认证授权码，消息过期时间，消息生存期。

响应消息头与请求消息头内容基本相同，只是在请求消息头基础上，新增了响应代码和详细相应信息。具体包含流程上下文协调ID，服务请求编号，服务消费者，业务流水号，事务标志，事务ID，客户代码，产品代码，服务名称，服务调用方法名称，平台编号，认证授权码，响应消息创建时间，消息过期时间，消息生存期，响应代码，详细响应信息。

BPEL流程层设计与实现

新一代计费清算系统采用BPEL（Business Process Execution Language）进行流程设计，具体过程遵循SOMA方法论的建模、设计与实现过程。以计费清算核心的数据清算流程为例，一级BPEL流程如图2所示。

数据清算总流程包括文件上传、文件预处理、下发传输三个子流程。其中文件预处理子流程为数据清算核心流程，其主要过程如下图3所示（实际流程更复杂，限于篇幅，此处为简化流程）。

文件预处理具体过程如下：

1.接受处理请求，调用文件状态服务，判断文件是否已经在处理或已经处理，如果文件已处理则流程结束，对文件进行备份。

2.调用账期日服务，获取并更新账期日。

3.发起话单校验服务，如果校验不通过则流程处理结束。

4.发起查重校验服务，如果校验不通过，则查重回退，流程结束。

5.发起结果发布服务，如果结果发布不通过，则结果发布回退，流程结束。

6.发起异步入库调用，进行异步入库。

BPEL流程开发采用Oracle JDeveloper Studio工具，数据清算总流程实现的是one-way流程，并可以对外暴露为一个webservice服务，供DataClearingService（数据清算总流程封装服务）在收到目录检测输出消息时进行调用。

整个流程分为3个部分：receiveInput、ICTransfer、PremainProcess。

1.receiveInput：流程调用的起始节点，接受从DataClearingService输入的消息，消息类型为DirDetectOutput（目录检测服务的输出消息）。

2.ICTransfer：异步调用ICTransferProcessService（上发传输流程封装服务），进行上发传输流程；在Receive节点设置超时机制，目前超时时间设置为900秒。

3.PremainProcess：以one-way的方式调用预处理流程的封装服务。预处理流程实现的是异步流程，并可以对外暴露为一个webservice服务。

图4 新一代架构与传统架构系统调度性能对比

OSB服务层设计与实现

OSB（Oracle Service Bus）服务层在整个SOA核心架构中承担服务封装、消息流转换与预处理、协议转换等功能。支持多协议、多渠道的通讯方式及异构系统间交互。OSB层中服务封装主要有两种类型的服务，一种是业务服务(Business Service)，另外一种是代理服务（Proxy Service）。业务服务会直接绑定具体的服务组件地址，比如JMS的URI或者WebServices的URI；代理服务主要负责消息格式转换、消息路由与异常处理。代理服务是OSB服务层对外暴露的接口。在新一代计费清算架构中同时使用到了同步服务与异步服务，一般来说对于响应时间短的服务设计为同步服务，响应时间长的设计为异步服务。

同步服务由一个代理服务和一个业务服务组成。代理服务会通过路由方式调用业务服务。服务调用通过代理服务，路由到业务服务，业务服务可通过配置输入、输出队列与具体的业务组件进行交互，代理服务同步等待业务服务的处理返回。

异步服务相比同步服务的特点在于，调用者发起调用之后不阻塞等待，调用结果通过反向回调通知到调用方。请求代理服务接收到请求后调用请求业务服务，请求业务服务与业务组件通过JMS队列进行驱动交互。业务组件处理完业务逻辑后将处理结果以消息方式回写到响应队列，响应代理服务通过监听响应队列的方式由消息负责驱动进行业务服务的回调。

OSB层中异步服务由两个代理服务和两个业务服务组成。代理服务中包括请求代理服务和响应代理服务。请求代理服务负责请求消息的格式转换、请求日志记录与路由并调用请求业务服务；响应代理服务负责响应消息的格式转换、请求日志记录与路由并调用响应业务服务。

图5 新一代架构与传统架构调度性能对比

组件层设计与实现

由于服务支撑平台涉及遗留C++系统组件的集成，综合考虑各种封装方式，采用队列方式能方便系统迁移改造。整个服务支撑平台包括如下三类队列：事件通知队列，用于记录处理事件的队列，主要消费者为订阅了事件主题的外部或内部组件（事件观察器）；处理队列，业务服务处理的核心处理队列，包括输入（请求）队列、响应（输出）队列；异常队列，为消息处理异常情况下，对消息的备份，支持人工介入处理。在具体进行SOA新架构迁移中，新一代计费清算架构在设计之初即考虑构建统一的服务接入框架，将具体SOA技术进行屏蔽，尽量降低架构迁移的工作量。服务接入框架实现的主要功能包括：1.JMS消息队列读写。构建统一的JMS队列访问机制，保证消息存取的事务性。2.消息解析与生成。对获取的消息统一解析为业务实体，并将处理结果组装为返回消息，这样具体服务组件只需对业务实体进行处理，无需关心具体消息结构。3.通用消息处理机制。框架封装了统一的消息处理流程，包括异常消息处理、消息处理日志。4.统一数据层访问。框架对清算话单访问提供多种数据层访问机制，当前支持包括本地文件系统、分布式缓存、分布式文件系统。

服务框架的构建使得具体的服务迁移工作量大大降低，也保证了遗留组件迁入SOA架构的质量。

系统实施效果

新一代计费清算系统已经部署并行，通过采集原有生产系统与并行环境进行性能指标对比，显示计费清算服务以及计费服务处理性能上，新一代计费清算架构都有明显的提升。

系统调度性能

相比原有传统架构，采用单机进程调度，依赖于数据库读写速度。新一代清算架构，采用SOA消息调度，支持分布式调度，且消息走内存和网络方式，不与数据库交互，效率提升约46%。

系统平均处理性能

由于调度性能的提升以及降低了数据库IO的读写以及部分处理环节的优化，HPUX部署方式下，整体平均处理性能由原有的609TPS，提升到877TPS，提升44%，云计算部署方式下，性能提升到1209TPS，提升99%。

新一代计费清算系统引入SOA，打破原有封闭式架构，实现计费清算服务可复用，通过构建统一服务接入框架，降低遗留系统接入新架构的接入成本，为计费清算系统集中化运营运维提供了技术保障；整体架构实现分布化，对原有组件进行X86化改造，具备部署云计算平台的能力，使得系统架构具备横向扩展能力，相比原有架构，系统在性能、可靠性、可扩展性方面都有较大提升。当然，整体架构还有很多问题待完善解决，这些问题将在后续项目中逐步得到完善和彻底解决。