漫谈计费系统的开发

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

 

BOSS 的计费系统的介绍写了两篇，《计费账务系统介绍》和《 OCS 的前世今生》，主要是介绍系统的，下面将针对计费系统中的一些开发技术做一点介绍。其实，其中的一些技术已经有所提到。

再三强调的是，写这篇文章只是一家之言，没有任何褒贬哪种技术的意思。写这几篇文章的初衷只是为了总结和交流。

 

1 、硬件和操作系统：

计费系统因为其系统的特殊性，所以一般都是基于 Unix 的。现在中国移动的计费主机应该是以 IBM 和 Sun 为主，对应的操作系统是 AIX 和 Solaris 。以笔者的经验来看，其实这两种机器在伯仲之间，听很多人人云亦云的说 Sun 的机器慢，我觉得是比较片面的，或许也是 IBM 的销售比较强势吧。

 

2 、数据库：

可笑的是，这个领域似乎已经没什么选择了，厂商基本都扎堆在 Oracle 上，甚至整个 BOSS 系统在基础软件的选择上也没什么选择的余地，基本都是 WTO 。 W 指的是 weblogic 和 websphere ， T 指的是 Tuxedo ， O 指的是 Oracle 。计费系统如果用到内存数据库的话，也就是 Altibase 和 TimesTen 两家了。以前可能会有很多厂商会在这块有一些自己的解决方案，但是可以预见的是，随着 TimesTen 的介入，这块自留地会在不远的将来彻底消失。

如果某个省主机用的是 Sun 的话，可能他的所有东西现在都是用 Oracle 公司的了。

厂商用 oracle 的原因首先是 oracle 的分区技术在清单存储和剃重里扮演着十分重要的作用，其次就是 oracle 的 PL/SQL 实在是好用的令人发指。在厂商积累了大量 PL/SQL 的业务代码后，哪怕是 IBM 说免费给你用 db2 也没几个敢用了（这是真事）。

 

3 、开发语言：

在这个领域，应该还是 C 和 C++ 的天下。从目前来看， Java 在这里还是没有使用的场合。原因有很多，这个话题放出去，也被讨论的很多。用 C 语言的原因，站得住脚的说法就是效率，而且 C 语言跟底层打交道比较方便。 Unix 提供了很成熟的 IPC 支持，都是用 C 语言来调用，这是 Java 不具备的。还有一个原因应该是历史的原因吧，这个和大型金融系统是一样的，大量的历史代码都是 C 或者是 C++ 写的，要全改的话，基本也是不可能的。

其实我一直在考虑如何把 Java 语言介入到计费系统里面去，因为 Java 语言的优势在计费系统里面不在于跨平台，而是在于他语言的安全性。以我的经验来看，在日常的计费系统中，除了业务流程错误外，大量的错误是因为数组越界、内存泄漏之类的问题引起的。而这两类的问题， Java 语言有着先天的优势和企业级的监控措施。

但是，把 Java 引入计费系统还有一个很大的障碍，就是 Oracle 的 PL/SQL ，这个语言在计费系统中使用得非常广泛，我见过很多计费厂商的产品，除了框架是用 C 或者是 C++ 写的外，其他的实现基本都是用 PL/SQL 来做。

当然，还有一种语言不得不说，那就是脚本语言。目前这里更多的是实验性质的，我在这方面做了一些尝试，与自己写一个简单的脚本引擎（有不少厂商这样做）相比，我更倾向于使用成熟的脚本语言，在试过 tcl 、 perl 和 python 之后，我认为 lua 可能更合适，也就此写了一篇文章《将 lua 嵌入 C++ 用来做计费系统的批价》。

 

4 、业务 or 技术

相比其他行业的软件，电信行业的软件更加重视的是系统的稳定，以及对业务的支持。不见得先进的概念能在这里发挥多大的用处。因为这里面太复杂了，厂商能做的就是用最简单最成熟的技术来解决问题。毋庸讳言，在这里，开发人员对业务的理解比技术更加重要。笔者曾经和一个互联网界的人士聊天的时候，他就抛出，“你们做计费的除了写点 SQL 还会什么”的言论来，虽然有所偏激，但是很多情况下的确是这样的，很多做计费的开发人员基本就是 PL/SQL 打天下，有些人甚至连简单的文件处理都要导到数据库里面来处理。不过我相信，随着 3G 系统的建设，对计费人员的素质的要求会越来越高，做计费的兄弟们要加油啊。

 

5 、计费系统与设计模式

在设计模式风行的那段时间，我一直在审视我们手头散着臭味的代码，但是冷静下来，我会很自豪的说我也有自己的模式，那就是 KISS ，我不会为了一些可能永远也用不着的“灵活和漂亮”去把我的程序搞得超级复杂，一个父类一个子类的堆出 N 多无用的代码。特别是我看了 libevent 、 Berkeley DB 这些项目的代码后，我更坚定了我的信念。 KISS ，反对为模式而模式！我认为在实际工作中，比较合适的方式应该是用 C 语言开发出底层的功能，再为了使用的方便，用 C++ 进行简单的封装。反正我是不敢用 boost 和 ACE 去写东西，一旦出了错，调试起来的痛苦程度我相信用过的人都知道。

 

写的不错，java在电信中还不是核心的，因为性能要求（相对于c++处理大规模的数据来说），历史遗留问题，许多地方都不能用。

比较有价值，是亲身经历，经验之谈。

刚进这一行，C不行，分到CRM线。前辈有时间介绍点电信CRM的东西。

电信的CRM实际上跟其他系统的CRM差别不大，业务有点不一样而已，比较麻烦的是数据模型。

曾经参与开发过一个电信行业的大客户CRM。。其实就是一套BOSS的营业系统拿出来改了改就叫CRM了。。BI方面的东西基本没有。。（个案，仅供参考）

在做CRM，感觉还是计费系统对开发人员的要求更高一些。毕竟安全性和稳定性要求比CRM要高很多。

不好这么说，都是电信级的。

要怎么看了，就理论上大家都是CRM吗，不过要是想要把电信的CRM做好其他系统的CRM还是有很大差异的。可以到网上找找中国电信的规范看看。
我现在在研究siebel，其实很多东西还是存在很大差异的。

有电信计费系统是用java写的。而且所有业务逻辑都放在app层。
solaris+oracle+jboss+ejb2。 scale的非常好。

业务这种东西，还是不要用pl/sql写。