计费系统与接口

teddylw1611616

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


前文《计费账务系统介绍》中提到，计费系统由多个部分组成，多个部分之间的串联肯定少不了接口。下面将大致介绍一下在计费系统中用到的接口形式，当然这些接口的方式并非计费系统所特有，其他的系统也会用到。但是在大数据量交换的系统里面，这些接口形式都是值得借鉴的。

1、    文件接口
从数据采集开始，文件接口实际上已经开始在计费系统里面存在了，所谓的文件接口无非就是通过轮询指定目录下的新增文件，然后获得数据的一种方式。文件接口需要注意的是，大数据的文件需要添加一个文件结束的标志，比方说，对方在传送一个1G的文件，你肯定不想在他传到500M的时候就把文件取走了，判断文件传送结束的方式有很多种，经常用到的方式是：对方在传送文件结束后，再传一个空的文件做标志，表示数据文件已经传送结束。数据文件和标志文件一般用相同的文件名，但是后缀不一样。

特别要说明的是，这种接口方式不单纯在采集的时候用，在计费的过程中，预处理之后给批价，批价之后给清单入库等等，都有厂家使用这种方式。

文件接口的好处是简单、做大数据量传送的时候可靠性比较高、效率比较有保证，而且除了ftp外，不需要其他系统软件的支持。

基于此，甚至于在一些需要交互的系统里面，也会使用这种接口方式：客户端发一个请求，请求的内容写到文件里面，放到指定的目录；服务端取走文件，完成业务，再将结果生成文件，放到指定的目录。这种方式貌似比较土，但是在实际应用过程之中效果还是很不错的。特别是在处理批量的请求时，只用交互一个文件就可以了。

2、    数据库接口
数据库接口这种方式，我最早是在一些交换厂商的实时接口里面见到。具体如下：接口的双方约定一个双方都可以访问的数据库，约定一些表。场景如下：

请求方把请求insert到请求表中；
应答方轮询指定表，发现有记录则取走，并把这条记录删除，或者移到历史表中；
应答方处理完请求后，把应答结果放到约定的表里面去；
请求方轮询结果表，收到记录后，删除记录，或者移到历史表。

这种接口方式要依赖一个数据库，比文件接口要复杂一些，但是对应用的开发来说，却是方便了不是，所以这种方式的应用也不少。

上面说的两种接口方式，都是基于轮询的方式，接口双方如果要获取信息，都是通过轮询指定区域的记录来完成。这里有一个问题就是：轮询总有一个时间差，在交互频繁的时候，这种时间差对交易的影响是很小的，但是如果在业务比较闲的时候，就有两个问题，一是请求得不到及时的处理；二是无请求的时候的空轮询会浪费系统资源。这两个问题的处理实际上也是有办法的——虽然会增加系统的复杂性，回头我会再写一篇来说说这个问题。

3、    消息接口
消息接口在计费系统中的使用也很多，特别是在实时计费大行其道的今天，一些厂家的计费系统已经完全的基于消息了。预处理之后的一条条话单，在各个子系统之间，通过消息进行传递、交互。使用的技术有Unix本身提供IPC机制，如FIFO，消息队列等，还有使用TCP或UDP的，当然，应该也会有使用成熟的消息中间件（如IBM MQ Series）的。

使用消息接口的方式，一个显著地特点就是处理的速度能够得到保证，同时不对系统进行轮询。而且在使用了相对成熟的消息传递机制后，可靠性也能够得到相应的保证。

4、    进程内数据传递
有些厂商的计费框架充分的运用了多线程的编程方式，各个子系统是同一个进程的不同线程，这样数据的传递都在进程内部进行，这种方式并不是很多见，原因是多线程在很长的时间里，在Unix系统上的移植性并不是很好，但是随着各个厂商对POSIX支持的日益完善，这种框架出现也就有了良好的基础了。