计费账务系统介绍

本文原创作品，如需转载请注明来源，作者：姜涛， towerjt@gmail.com

 

对于一个BOSS系统而言，计费账务系统自然是一个相当重要的组成部分，在整个BOSS系统中，最有别于别的行业的部分应该也就是计费账务系统了，或者应该更强调的说是计费系统。
一般来说，计费系统分为：采集、预处理、剃重、批价、详单入库、账单入库这几个部分。

采集系统负责从业务网元获取各种业务的服务使用记录，很多情况下，我们都叫他们做CDR（call detail record），即使很多业务比方说是短信，并不是通话，我们也习惯上叫这些记录做CDR或者是详单。
采集的方式有很多，主要看网元的提供方式，对于电信运营商而言，核心的业务是语音、短信和GPRS，而语音和短信的话单一般都是由交换机或者是短信平台提供文件，在这种情况下，一般都是采集系统用ftp的方式来获取这些话单文件。这里不涉及什么高深的技术，大部分情况就是FTP，然后就是采集完后把已经采集过的话单文件移到备份目录。
这里需要提出一点的是交换机出话单的策略，为了更快的输出话单，交换机一般有两种输出策略，第一种是按时间，第二种是按文件大小。前者的意思是多长时间输出一个话单文件，后者的意思是当话单文件达到多大，就输出一个。自然，为了尽快的输出话单，忙时应该用第二种策略；而闲时的话，则使用的是第一种策略。
一个完整的话单包含的元素有发话时间、结束时间、主叫、被叫、发话地点等等。这里最要命的就是结束时间，一个完整的话单必须有结束时间，所以对于一个一直没有挂断的通话记录，传统的计费系统是无法对这条记录进行批价的，这也就是为什么会出现当你的卡上剩下1块钱，只要你不挂断电话，你可能可以打很长时间，很长时间！但是注意的是，我说的是“可能”，因为你知道这个秘密，运营商也不傻，他们会想办法处理这个问题，至于怎么处理，我以后会慢慢写。

预处理系统实际上是一个和交换厂商密切相关的领域。它需要做的是把各个交换机的话单格式转换成一个统一的话单格式，你需要把这些交换机的话单格式都搞清楚，如此而已，幸好厂商不多，因为这里没有什么标准可言，所以垄断有时候也有点好处。预处理系统还有一个重要的功能是话单合并，因为交换机会对长话单进行分段处理，比方说你通话超过30分钟，交换机会30分钟出一条话单，对于预处理系统则需要把这些话单进行合并。

剃重，很多情况下，剃重会归并到预处理系统里面，但是也有把他单独拿出来说的。从字面上来说，就是把重复的话单提出掉。话单出现重复的原因主要是交换机的原因，交换机有时候会出现一个通话记录产生两条一样的话单的情况，至于原因，我不是很清楚，呵呵。
剃重是一门很复杂的技术。但是剃重的条件实际上很简单，就是同一时间的同一个人不能做两件同样的事情，就是说你不能在同时给同一个人打两个电话。为什么说剃重是一门很复杂的技术呢，关键是涉及的话单量，你看看中国移动09年一季度的财报，一天净赚2.8亿！对于大部分省的移动运营商而言，一个月的话单都是亿为单位的，每天也是千万级。在这种海量的数据里面去迅速定位两个重复的记录，的确不是那么简单的事情。可以总结出的两种剃重技术，库外剃重和库内剃重，这主要看具体实现的方式是不是依赖数据库的唯一索引，如果依赖，则一般叫做库内剃重，反之如果是通过自建数据结构来处理叫库外剃重。

批价系统，很多情况下，我们会经常听说一批和二批这两个词，这两个词的叫法有很多种含义，说法也比较拗口，简单举个例子，如果你使用了一个套餐，包200分钟的市话主叫，超出之后每分钟2毛钱，这时你打了个4分钟的市话，一批出来是8毛；二批发现如果在200分钟内的话，则批成0。还有一种说法是一批先批成标准资费，即每分钟4毛，4分钟1块6，然后再批成0，或者是8毛。总是一批和二批的说法有这么几种，不过，随着系统的发展，一批和二批之间的界限实际上已经越来越模糊了，越来越多的计费系统都是通过一次性的批价来得出最终的结果，这是一个发展趋势。批价系统是计费系统里面最复杂的部分，一个计费系统好不好，可能更多的是通过批价系统来衡量。
衡量一个批价系统好不好，作为一个电信级的系统，首先当然是系统安全性要高，回退、重批等功能需要具备；其次就是要灵活。众所周知的是移动的套餐之多，多得到了令人发指的情况，多得到了很多运营部门的人都搞不完全清楚。如此多的套餐支持，而且美其名曰要迅速对市场部门需求做出响应，所以批价系统要尽量快的应对运营商提出的各种套餐需求。在支持这个套餐的过程中，其实运营商是不关心你每次会不会要改代码的，即使是口头上说说，只要你每次改的快，他们也不在乎的，这似乎和很多人鼓吹的并不一样，他们总会说是运营商要求要提高计费系统的可配置化。实际上是谁希望提高系统的可配置化呢？是集成商，集成商希望每次改套餐不要动代码，由现场维护人员改改配置，就能搞定，这样研发和测试就要省很多的事情。做计费系统的人都知道，运营商会要求现场有很多维护人员，至少是10个，甚至更多，他们可以给维护费，只要你支持他的需求，出错能兜得住，他不会管你是怎么实现的，是改代码还是修改配置？他们才不管。
关于批价系统说的比较多，大家还可以看看我的另外一篇文字《将lua嵌入C++中用来做计费系统的批价》

详单入库和剃重一个道理，关键是性能，大量的数据入库必然对性能的要求很高。一般的做法也可以分为两种，库内和库外。其中库外存储详单现在越来越少了，虽然他的优点很明显，占用资源少，速度快，但同时缺点也同样十分明显，就是查询和管理不方便，越来越多的开发商放弃了库外详单存储。而借助oracle的分区技术，库内详单存储基本上成为大部分开发商的首选方案。

详单入库之后就是合并账单了，因为账单的特殊性，他的update操作特别多，基于性能的考虑很多开发商选择了内存数据库来存储。以前很多的开发商都是自己基于Unix的共享内存技术来管理存储当月或者上月的账单，但是最近几年随着Altibase和TimesTen的流行，越来越多的开发商也开始放弃自己开发的东西，转而使用成熟的商用解决方案。一旦使用Altibase和TimesTen之后，账单的入库对于开发人员来说也就没多少技术含量了。

以上是一个对计费系统的简单介绍，有不对之处请大家多多指正。