巴勃 浏览 556 2015-03-29 20:03:43 发表于： 阿里通信技术团队 >> 开发

Java核心技术Java架构  修改标签  标签历史

一、 引言

一直觉得阿里通信的计费系统做的很不错，想向大家介绍一下，特别是核心的计费模型和计费引擎。本来@道延同学来写更合适，因为主体设计是他做的，我们更多时候就打打酱油。但这哥们忙，我就代为捉刀了。

二、 我们解决什么问题

阿里通信是一家虚拟运营商，我们构建了一整套boss系统来支撑170用户的销售、订单生产、CRM、客服、计费、账务等等。其中计费系统关注的是用户消费行为的计算，包括：每一通电话、每一条短信、每一次数据上网产生的费用，以及固定账期（ 按日按月）的出账）。

阿里通信的资费相对还是比较简单的，具体感兴趣的同学可以参考

http://aliqin.tmall.com/phone_num_intro.htm

总结起来就是自动靠档，7、37、77、127几档，超出档期又没到上一档按1元叠加。如果不是靓号就没有保底(非优惠其实是7元保底)，如果是靓号会针对靓号等级有不同的保底。

我们的计费系统不但能满足现有的资费计算，同时还满足各运营商奇奇怪怪各式各样的计费需求（三大运营商现有的资费，我们都适配过）。

三、 计费应用架构

画一张丑陋的简图，说明一下我们的计费系统大致由哪些应用组成。

1) 采集：用户话单由基础运营商的交换机采集，基础运营商会把相应话单按照约定的格式放置在特定的目录。采集就是将话单从源头目录取到我们的OSS，供下一个流程处理。有关采集的设计和代码可见http://www.atatech.org/articles/31609

2) 预处理:根据约定格式，将各类原始话单转换成公共的bean，调用计费服务，触发计费。具体可见http://www.atatech.org/articles/32114

3) 资料上发：用户资料（账户、用户、用户订购、群组、用户状态）、信用度、账本等信息的源头在CRM和账管。当发生变更，通过资料上发应用转换为计费需要的资料。

4) 计费服务：这是计费的核心引擎。包括：话单分析、算费、累账、控制、话单入库等子过程。后续在计费引擎中会重点介绍。

5) 日月账：每天或每月定时调度发起的全量用户计费操作。

6) 计费查询：提供外部方查询当前用户的话费总额、累计量、免费资源、余额等。

7) 运维监控：提供关键指标数据的生成供alimontor展示，提供重出账、错单重处理、外部话单导入等等运维手段。

四、 计费模型

按领域划分，包括：

1) 产品域：产品模型是计费的核心，后面重点介绍

2) 资料域：账户、用户、用户订购、账户用户关系、群组关系、停开机信息、信用度等；

这些信息都是计费相关的，这些实例信息与话单信息一起，通过产品信息确定最终的计费费率。

3) 接口域：分为上行接口和下行接口。

上行是指CRM或账管发生变化，需要同步到计费系统。主要是用户资料和账本的同步，变更资料域的内容。

下行是指信控告警、话单激活的信息需要下发给账管做后续处理。

4) 详账单域：包括免费资源、累计量、详单、账单、出账控制、账本、上次信控结果等。其中免费资源、累计量、详单、账单都是计费的结果。账本、账单、上次信控结果以及资料中的信用度决定了如何进行信控处理。

5) 应用配置域

除产品信息外应用相关的一些配置

6) 运维管理

运维日志、监控指标等数据

五、 产品模型

产品模型是计费的基础，怎么计费就靠它了，因此单独展开讲讲。

无图无，先看一下产品模型图

简单起见，画的是概念模型，具体的物理实现为了编程上考虑有些小的出入。

1) 服务：用户在运营商享受的服务，简单来说就是：语音、短信、数据等等。

2) 计费事件：触发发生具体计费的条件。对于话单触发的计费来说，不同的话单要素组合组成了不同的计费事件。

举例来说：语音话单的批价，主要有以下话单要素：接入类型(直拨/IP电话...)、对端类型（移动、联通、电信…）、呼叫类型（主叫、被叫、各种呼转…）、漫游类型（本地、省内、国内、国际…）、长途类型（本地、省内、国内、国际…）,按照具体的业务计费场景，对话单要素排列组合形成不同的计费事件，比如：国内语音主叫、国际语音主叫、国内被叫…

3) 科目：通俗讲就是收费的类别，科目是有层级关系的，多个子科目可以合成一个上级科目。

4) 费率：计费规则的载体。

5) 费率曲线：具体的明细计费规则。一个费率可以包含1到多个费率曲线明细。计费规则按类型可以分为费用计算或者是资源量计算规则。资源量计算估计大家理解容易模糊，举个例子：国内语音计费的资源单位是分钟，一通电话125秒，计费资源量计算是3个单元。

6) 产品包：对外包装的可供用户订购的一个整体，与CRM系统的策划模型做相关映射。

7) 产品：产品包细分就是产品，产品是服务的实例化，根据类型我们区分为计费产品、固费产品、优惠产品、免费资源产品。计费产品主要用于标准话单批价，固费产品用于周期费用计算（比如套餐月租费）、优惠产品用于优惠计算、免费资源产品用于免费资源规则消耗。

8) 累计量、免费资源：科目按照一定的规则合并成累积量科目。

免费资源给大家举个例子：某移动XX套餐，用户一个月可享受国内语音100分钟，那么在系统中100分钟就是国内语音免费资源量，用户发生国内语音通话，会消耗具体的免费资源量。

累积量科目与免费资源之间存在着一定的消耗关系。

产品模型决定了系统是如何进行计费的。再来统一捋一捋：

计费话单->话单要素->计费事件

用户订购->产品包->产品

产品（如果没有配置，缺省是服务）、计费事件->费率、科目

费率决定了如何计费，通过费率明细计算费用

科目决定了费用或资源量如何分类，将计费结果承载在具体科目上.

免费资源、优惠产品的计费规则处理为了简便，在具体实现上没有使用通用的费率模型，做了一定的特殊简化处理，有关的模型在上面的概念模型中没有提及，但道理是想通的。

六、 计费引擎

上面简单介绍了计费模型，下面重点介绍一下围绕计费模型如何实现计费引擎。

整个计费引擎设计的特点：流程化驱动，构造了公共的DRBEAN对象作为不同流程节点传输的数据模型；几个核心组件都是插件式，基于配置可替换。

计费流程按顺序分为以下几个步骤

1) 业务分析

具体由业务分析组件完成，针对不同运营商不同业务有不同的实现，这可以算是整个计费处理中最复杂的模块了。主要功能是将预处理传递过来的话单结合用户资料进行计费前分析，组装好相关计费条件供后续计费使用。包括：话单合法性校验、呼叫类型分析、运营商分析、主被叫号码的规整（如：0086，86等等规整） 、其它计费要素分析（如：长途、漫游等等，话单类型不同要素不同）、过滤话单解析（如:3秒超短话单不计费）、用户计费号码设置、构建计费事件、用户资料分析（用户、账户、用户订购，其中用户订购分解成用户计费产品、用户优惠、用户免费资源、用户固费产品）。

2) 算费

• 批价

根据业务分析确定的计费事件和计费产品路由具体费率包。对于没有配置计费产品的，根据计费事件和服务路由最终费率包。一个费率包可以包含多个费率明细，对于阶梯计费，一个阶梯就可以配置成一条费率明细。对于批价，包括费用的批价和资源量的批价。

费率曲线表的设计我觉得能满足大部分的计费需求，主要字段：

开始值、结束值、基本费用、批价单元、批价费率、尾部单元、尾部费率、尾部取整.

同时，为了支持个性化的需求，对于配置难以实现的计费方式，提供了根据表达式、java代码、字节码生成等多种方式的个性化计费实现。

• 累积量处理

对上一个过程形成的资源量，按照业务分析阶段形成的科目和累积量关系累加到具体的累积量科目上。

• 免费资源处理

有关免费资源的概念在上面有过简单介绍，也就是用户订购了某个套餐，在账期内可以免费享受的具体类型资源量。

计费累计量与免费资源之间存在着关系。免费资源处理就是将批价产生的本次累积量根据相应规则拿用户剩余免费资源做抵扣。

3) 累账

• 计算账单

批价结果是形成用户本次通信的详单。而计算账单这个过程，则是将本次详单与用户当月账期的账单进行合并，最终体现的是用户当前实时账单。账单科目是详单科目的聚合，多个详单科目合并成一个账单科目。

这个过程还是比较容易理解的。

• 实时固费

固费全称固定费用或则叫周期费，更通俗的叫月租费。

传统运营商的套餐费、功能费（如：彩铃、来电显示…）都属于这个范畴。举例来说彩铃5元/月，一般来说有以下收费规则：整月（当月订购就收5元）、上下半月（上下半月各收2.5元）、按天摊分、首月不算、尾月不算等等。

每次话单计费的时候都会触发实时固费计算，以便能实时体现用户账单中具体的固费，整个计费过程与话单批价类似。

阿里通信的固费就只有亲卡套餐费一种，根据用户本月累计量分不同档，具体通过特殊资费的表达式完成。

• 实时优惠

在这个阶段，如果用户有优惠则进行实时优惠处理。优惠涉及优惠后科目，优惠触发条件和具体优惠计算规则通过表达式完成，优惠的类型有打折、减免、封顶、保底、赠送等等。

4) 控制

每一次计费处理之后都会触发一系列控制动作，最著名的就是信控。

系统中根据账户余额+信用度-历史欠费-实时话单表达式的结果，结合该账户对应的信控阀值，判断后续信控处理动作。低额提醒，欠费停机、充值复机等等都是信控的结果。

除了信控处理外，还包括首条话单激活、数据流量封顶关数据功能等等控制处理。

具体就不一一展开了。

5) 入库

数据库写操作。

一次计费过程中涉及累计量、免费资源、账单等更新（其中累积量、账单当月第一次是插入），详单插入。

传统运营商的计费系统累计量、免费资源、账单都是保存在商用或自我研发的MDB中，我们没有采用MDB。

七、 总结

写到这，阿里通信计费系统大概样貌介绍完毕了。

说个背景，我们的新系统上线前计费业务是由BOSS厂商提供的老系统支持的，当时用了120台虚机，很多地方还是单点，三天两头出故障。我们系统上线后主机只有10多台，一直运行的很平稳，且整个系统扩展性很不错，从这点来说参与这个项目建设还是蛮有成就感的。下载本文