运营商计费系统详解:它们由哪些主要模块组成以及如何运行

用户在计费系统里只看到一行字:“某日将扣费多少”。但在内部,它是运营商最关键的系统:让人入网,计量使用量,计算金额,并对财务负责到每一分钱。运营商可以承受网站故障,而计费故障意味着数千用户要么断网,要么免费上网。我们来看看这个行业内称为自动计费系统的东西由什么组成。

用户在计费系统中的路径

用户的路由器建立连接时,运营商的设备会询问计费系统:是否放行,给多少速度。这种对话的经典语言是 RADIUS,答案取决于余额和套餐。接着网络发送计数器:通过了多少字节,会话持续多久。计费系统把它们转换为费用,在扣费日结算周期。后台付款方向相反:资金到账,解除封锁,恢复速度,全程无需人工。

现代计费系统的模块

核心周围通常还有相关模块:线缆和端口的技术台账、扣费通知、覆盖地图集成。运营商越大,计费系统就越像一套积木,每个模块都可替换。

成品软件、SaaS 还是自研

小型网络从成品系统开始:装到自己的服务器上,录入套餐就能用。优点是可控和一次性付费,缺点是更新和备份都要自己负责。云端系统按账号收费并承担运维:对几千用户的网络,这往往比一名管理员的工资便宜。自研适合模式特殊的运营商:虚拟运营商、按天计费的服务商、计费本身就是产品的服务。这是最贵的路,但不受他人架构限制。

选择时看什么

• 对您设备的支持。授权和计数器收集必须能配合您具体型号的交换机和 BRAS,“大体支持”是不够的。
• 封锁速度。从余额归零到实际断网之间有多久:几小时的差距就是白送的流量。
• 重新计算。追溯换套餐、退款、承诺付款:成品系统最常在这些场景出错。
• 开放 API。后台、网站和手机应用如果能基于 API 构建,而不是困在别人的模板里,寿命会更长。
• 负载余量。在一千用户时运行流畅的系统,到五万用户的集中扣费日可能会卡死。

迁移是另一笔开支。离开旧系统会牵扯余额历史、未结周期和承诺付款。好的承包商先清点这些遗留问题,差的先演示漂亮的后台。请安排两套系统至少并行一个计费周期:用真实用户核对费用,能发现任何测试都看不到的问题。

实施中的典型错误

• 先建网再做计费。先把网络建好,再加上计费。正确的顺序相反:授权和统计方案决定设备选择。
• 套餐“照搬邻居”。系统支持灵活套餐,却只录入三行。之后每次促销都变成人工重算。
• 一台服务器包办一切。数据库、RADIUS 和后台放在一台机器上,到第一个集中扣费日就撑不住了。至少提前把数据库分出去。
• 没有测试环境。更新直接上线,第一次资费错误的代价就超过测试环境一辈子的费用。
• 备份不验证恢复。备份做了好几年,第一次恢复却在故障时才尝试。每季度必须演练一次恢复。

这些错误的共同点是:把计费看作程序,而它其实是一个流程。用户的钱不断从中流过,所以应该像对待收银台一样对待它,而不是像对待网站。

如果您要为增长中的网络选择系统,不要只看功能列表,请问两个问题:它如何撑过扣费日,迁移时把数据导出来有多容易。其余功能都可以追加,这两点却由架构决定。关于相关基础设施我们另有文章:网络中的服务器类型概览能帮您理清计费系统在其中的位置。