免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 4331 | 回复: 1
打印 上一主题 下一主题

[电信] 漫谈计费系统的开发 [复制链接]

论坛徽章:
0
跳转到指定楼层
1 [收藏(0)] [报告]
发表于 2011-03-13 21:45 |只看该作者 |倒序浏览
本文系作者原创,如需转载请注明来源,作者:姜涛,towerjt@gmail.com  tower.javaeye.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 去写东西,一旦出了错,调试起来的痛苦程度我相信用过的人都知道。

论坛徽章:
0
2 [报告]
发表于 2011-03-15 23:20 |只看该作者
顶!
------------------------------------------------
5 、计费系统与设计模式

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

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP