漫谈计费系统的开发
本文系作者原创，如需转载请注明来源，作者：姜涛，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去写东西，一旦出了错，调试起来的痛苦程度我相信用过的人都知道。
?
7 楼 tower 2009-06-05 neu_gefei 写道在做CRM，感觉还是计费系统对开发人员的要求更高一些。毕竟安全性和稳定性要求比CRM要高很多。不好这么说，都是电信级的。
8 楼 lottons 2009-06-05 tower 写道ihad 写道刚进这一行，C不行，分到CRM线。前辈有时间介绍点电信CRM的东西。
电信的CRM实际上跟其他系统的CRM差别不大，业务有点不一样而已，比较麻烦的是数据模型。
要怎么看了，就理论上大家都是CRM吗，不过要是想要把电信的CRM做好其他系统的CRM还是有很大差异的。可以到网上找找中国电信的规范看看。
我现在在研究siebel，其实很多东西还是存在很大差异的。 9 楼 xiaolin0105 2009-06-05 有电信计费系统是用java写的。而且所有业务逻辑都放在app层。
solaris+oracle+jboss+ejb2。 scale的非常好。
业务这种东西，还是不要用pl/sql写。 10 楼 tower 2009-06-05 xiaolin0105 写道有电信计费系统是用java写的。而且所有业务逻辑都放在app层。
solaris+oracle+jboss+ejb2。 scale的非常好。
业务这种东西，还是不要用pl/sql写。
能说说是哪个厂商的产品，在哪个省用吗？很感兴趣
11 楼 xiaolin0105 2009-06-06 tower 写道xiaolin0105 写道有电信计费系统是用java写的。而且所有业务逻辑都放在app层。
solaris+oracle+jboss+ejb2。 scale的非常好。
业务这种东西，还是不要用pl/sql写。
能说说是哪个厂商的产品，在哪个省用吗？很感兴趣
是爱立信的IPX，在全球范围内使用，做电信运营商和内容供应商之间的计费和消息业务，整合了500家运营商和4000多家内容供应商。
比如你人在美国，通过手机上德国的网站定了个飞机票，那么就可以跨国计费了。作为内容供应商，就不用考虑怎样和国外当地电信运营商整合以及法律，税务和计费的问题了，IPX都帮忙搞定了。 12 楼 leadyu 2009-06-06 tower 写道xiaolin0105 写道有电信计费系统是用java写的。而且所有业务逻辑都放在app层。
solaris+oracle+jboss+ejb2。 scale的非常好。
业务这种东西，还是不要用pl/sql写。
能说说是哪个厂商的产品，在哪个省用吗？很感兴趣
在线计费没见过java写的，后付费的还是有地 13 楼 xiaolin0105 2009-06-06 leadyu 写道tower 写道xiaolin0105 写道有电信计费系统是用java写的。而且所有业务逻辑都放在app层。
solaris+oracle+jboss+ejb2。 scale的非常好。
业务这种东西，还是不要用pl/sql写。
能说说是哪个厂商的产品，在哪个省用吗？很感兴趣
在线计费没见过java写的，后付费的还是有地
online billing也是IPX的提供的服务里的一种。 14 楼 lottons 2009-06-08 呵呵，可以参考SOA的概念，把业务全部做成一个一个的服务。服务完全可以分布式部署，最后通过map服务器进行整合处理，用java的好处就可以在这一点上体现出来。
我觉得其实分布式计算在这种大型系统上应用是最合适的，大量的廉价服务器的性能要好过单一的大型服务器。而且使用分布式的好处就是可以很方便的扩展，现在业界的架构都是以分布式为基础的。
java在分布式上要由于c++ 15 楼 anky_end 2009-06-08 计费用c是历史问题，何况国外电信业务和中国可比性不强，我们一个省的业务比的上国外一个国家的业务了 16 楼 tower 2009-06-08 lottons 写道
呵呵，可以参考SOA的概念，把业务全部做成一个一个的服务。服务完全可以分布式部署，最后通过map服务器进行整合处理，用java的好处就可以在这一点上体现出来。 我觉得其实分布式计算在这种大型系统上应用是最合适的，大量的廉价服务器的性能要好过单一的大型服务器。而且使用分布式的好处就是可以很方便的扩展，现在业界的架构都是以分布式为基础的。 java在分布式上要由于c++
计费不会搞很多廉价服务器的，原因大致有二：
1、IT管理水平到不了这个程度
2、中国移动不差钱 17 楼 roadray 2009-07-17 lottons 写道呵呵，可以参考SOA的概念，把业务全部做成一个一个的服务。服务完全可以分布式部署，最后通过map服务器进行整合处理，用java的好处就可以在这一点上体现出来。
我觉得其实分布式计算在这种大型系统上应用是最合适的，大量的廉价服务器的性能要好过单一的大型服务器。而且使用分布式的好处就是可以很方便的扩展，现在业界的架构都是以分布式为基础的。
java在分布式上要由于c++
用廉价服务器,出了问题得移动的领导扛不住 18 楼 gainfirst 2009-07-20 everlasting_188 写道写的不错，java在电信中还不是核心的，因为性能要求（相对于c++处理大规模的数据来说），历史遗留问题，许多地方都不能用。
不对吧，电信中C和C++也只是计费系统中和OCS在用，像VC，10000号，服务开通，资源系统，渠道系统，代理商，经营分析以及CRM，ODS都是用java来实现的，电信中的核心系统应该是CRM，融合计费系统和结算，从这三个系统来看，java和C++/C所占的比列，还是java要高的。毕竟整个CRM都是用java，融合计费系统中的报表系统，销账和缴费前台以及综合查询都是用的是java，如果再算上OSS，那java的比重就更大啦，C/C++也只是在计费控制，销账等具体强调效率的时用的，总体来看电信的整个BOSS系统，java比重更大些。说到中间件，电信各个省份确实是weblogic，websphere和Tuxedo这三个的天下，Tuxedo就不说了，计费系统一般都是，weblogic和websphere相比，显然前者更具有优势，市场份额有增大趋势，后者应用的省份主要是是南方电信一些早期的省份，像江苏，四川，浙江，贵州，云南等，后者主要是体现在北方电信，比如最近割接的天津，内蒙，新疆，山东。中间的一些省份比如青海，陕西，安徽，宁夏等虽然用的也是webSphere，但是主要是前期的其他南方省份的影响（代码移植，代码部署和南方的统一）。但是还是阻挡不了weblogic一通天下的趋势，主要weblogic比webSpher部署起来更快捷，也更稳定吧（感觉），另外如果在本机上部署系统那就更麻烦啦，你如果用WSAD开发调试起来你就会发现那个慢的一塌糊涂，比eclipse可就差远啦（我们公司配置的电脑目前都是内存2G，主频2.2左右 ），所以现在其他省份也在计划将websphere换成weblogic，估计以后基本上都会用weblogic（计费的前台操作java的部署也都用的是weblogic） 19 楼 lottons 2009-07-24 gainfirst 写道everlasting_188 写道写的不错，java在电信中还不是核心的，因为性能要求（相对于c++处理大规模的数据来说），历史遗留问题，许多地方都不能用。
不对吧，电信中C和C++也只是计费系统中和OCS在用，像VC，10000号，服务开通，资源系统，渠道系统，代理商，经营分析以及CRM，ODS都是用java来实现的，电信中的核心系统应该是CRM，融合计费系统和结算，从这三个系统来看，java和C++/C所占的比列，还是java要高的。毕竟整个CRM都是用java，融合计费系统中的报表系统，销账和缴费前台以及综合查询都是用的是java，如果再算上OSS，那java的比重就更大啦，C/C++也只是在计费控制，销账等具体强调效率的时用的，总体来看电信的整个BOSS系统，java比重更大些。说到中间件，电信各个省份确实是weblogic，websphere和Tuxedo这三个的天下，Tuxedo就不说了，计费系统一般都是，weblogic和websphere相比，显然前者更具有优势，市场份额有增大趋势，后者应用的省份主要是是南方电信一些早期的省份，像江苏，四川，浙江，贵州，云南等，后者主要是体现在北方电信，比如最近割接的天津，内蒙，新疆，山东。中间的一些省份比如青海，陕西，安徽，宁夏等虽然用的也是webSphere，但是主要是前期的其他南方省份的影响（代码移植，代码部署和南方的统一）。但是还是阻挡不了weblogic一通天下的趋势，主要weblogic比webSpher部署起来更快捷，也更稳定吧（感觉），另外如果在本机上部署系统那就更麻烦啦，你如果用WSAD开发调试起来你就会发现那个慢的一塌糊涂，比eclipse可就差远啦（我们公司配置的电脑目前都是内存2G，主频2.2左右 ），所以现在其他省份也在计划将websphere换成weblogic，估计以后基本上都会用weblogic（计费的前台操作java的部署也都用的是weblogic）
楼上的是联创的吧，在哪个部门啊？CRM还是服务开通？ 20 楼 tower 2009-07-27 大家最好不要在帖子里面讨论谁谁是哪个公司的，如果感兴趣可以私聊，一点建议 21 楼 gainfirst 2009-07-27 tower 写道大家最好不要在帖子里面讨论谁谁是哪个公司的，如果感兴趣可以私聊，一点建议
强烈赞同，o(∩_∩)o...哈哈，tower说的对。其实我从tower中还是收益不少的。 22 楼 lottons 2009-07-29 roadray 写道lottons 写道呵呵，可以参考SOA的概念，把业务全部做成一个一个的服务。服务完全可以分布式部署，最后通过map服务器进行整合处理，用java的好处就可以在这一点上体现出来。
我觉得其实分布式计算在这种大型系统上应用是最合适的，大量的廉价服务器的性能要好过单一的大型服务器。而且使用分布式的好处就是可以很方便的扩展，现在业界的架构都是以分布式为基础的。
java在分布式上要由于c++
用廉价服务器,出了问题得移动的领导扛不住
难道用了soa的架构，部署服务就一定得用廉价服务器？这个是谁规定的？SOA架构主要体现在对服务的应用及整合上，这个概念用在电信行业是很合适的，看看电信网中各种网元设备，难道这些就不是服务？难道这些网元设备使用的就是高档服务器？建议去实际机房看看这些网元设备。
其实对我来说，计费系统和其他的网元设备一样都是提供一种服务的。将计费系统的服务和其他增值服务以及网元（智能网服务）进行整合是电信运营系统的大势所趋。
还有一点，就是这个不是差钱不差钱的问题，系统的部署有时候还要考虑地域，负载等一些列问题。各个系统的建设等级，如省级CRM或计费系统，地市级CRM或计费系统等等。这些系统在部署的时候难道不是在对外提供服务？这些服务也是需要进行整合的，难道它们就一定是部署在廉价的服务器上？不要混淆了我的意思。 23 楼 bird_wang 2009-07-30 拜读了。
现在我也在一个做计费的公司里面，当初本想做开发的，后来被分配到实践那块去了，现在感觉除了学业务还是学业务，有时候都感觉自己很虚，想着要是以后跳槽了怎么办，一点技术都不会，真的像作者说的除了PL/SQL还是PL/SQL，呵 24 楼 bigtreefxs 2009-09-03 对PL/SQL 不太熟悉，
使用C++操作oracle....噩梦的开始。
OCI接口不是一般的难用
相比之下，cli就好用多了～～ 25 楼 tower 2009-09-04 bigtreefxs 写道对PL/SQL 不太熟悉，
使用C++操作oracle....噩梦的开始。
OCI接口不是一般的难用
相比之下，cli就好用多了～～
OCCI相对就简单很多了，可以试试。 26 楼 transist 2009-11-24 bird_wang 写道拜读了。
现在我也在一个做计费的公司里面，当初本想做开发的，后来被分配到实践那块去了，现在感觉除了学业务还是学业务，有时候都感觉自己很虚，想着要是以后跳槽了怎么办，一点技术都不会，真的像作者说的除了PL/SQL还是PL/SQL，呵
感觉在国内做应用软件开发的，业务积累的门槛比技术更高。
技术你可以自己学，业务需要工作单位给你这个实践平台。
计算机开发为什么门槛低，只因很多不同专业的都可以自学，这个行业开放性又强。其他行业其实只要有入门机会，不会比计算机开发复杂。