如果你来设计运营商的流量计费系统

周末看了一天的直播课程，流量用超了，套餐外的流量又很贵，把账户余额也直接扣到负十几块，停机了。这期间，看到这系统有几个问题：

1. 套餐内流量用完没有预警提示；

2. 流量用超了很多之后，才扣钱，导致用户余额不足而直接停机；

3. 直接停机之后没法联网，如果没有其他网络就没法充值；

4. 运营商的账单经常查询不到（直到写这个文章的时候，电信的账单依然查询不到，至少有三四天了）；

5. ……

这个系统确实不容易，但是在运营商日进斗金的营收下，这么多年了系统还这么难用，在运营商里面搞技术的好意思说自己是搞技术的吗？（或者他们这些系统都是外包给别人开发，技术……他们不需要。垄断赚钱多舒服，要啥技术）

吐槽归吐槽，如果系统给你来设计，你会怎么设计？

系统目标

抛开那些具体的业务逻辑，这个系统应该具备以下目标：

1. 预警要及时：套餐内流量或余额用到一定阈值应该有预警；

2. 扣费要及时：避免余额直接都负数，造成停机，导致用户充值不了；

3. 查询要及时：历史账单和当月消费明细应该满足近实时的查询。

解决这三个“及时”，我上周所遇到的问题，也就解决的。

运营商的计费扣费特点

运营商的计费是有特点的：

1. 用户量巨大，手机人手一台；

2. 用户几乎都是实时在线，关机的情况很少，每时每刻都可能产生消费；

3. 用户几乎都是实时在线，但是大多数用户的大部分时间几乎都是静止的（不会产生扣费，流量可能只是极少的消耗）

扣费和流量系统架构设计

以下仅为自己的想法，运营商实际的系统是怎么样的不清楚，架构应该会更加复杂。不过从他们系统呈现出的问题而言，他们系统在架构上可能就是有问题的。看那些互联网大厂，他们也是高并发大流量系统，但是他们却搞出来了很多能造福整个行业的基础基础（数据库操作系统大数据等，为开源贡献不少），但是运营商在这技术进步方面几乎毫无建树，白白浪费了这么好的场景。

以流量计费为例：

对于用户来说，是直接访问了某个目标服务，实际上是先经过了运营商的基站，才到目标服务的，运营商也是基于此收“过路费”的。

用户访问到达基站的时候，基站就得判断是否应该放行。而这是否放行的依据应该是来自缓存（肯定不可能在这里查数据库），因此这个状态的更新是否及时就很关键，如果更新延迟很多，那就可能导致账户余额扣成负数。

每隔一段时间（例如每分钟）基站应该就会上报用户在这个时间段消耗了多少流量（基站应该是可以隔一段时间上报一次的），这个数据应该会推送到区域的流量MQ服务器里，这个MQ服务器应该是区域化的，例如广州可能有3kw的用户量可以形成一个区域，广州所有的基站数据都上报到区域的服务器上，因为基站每分钟（假设）上报一次，那么它的并发量平均就是3kw/60 = 50万QPS（实际上数据可能是不平均的，乘以2吧，100万QPS），这对于MQ来说并不多。

100万QPS虽然不多，但是如果100万的计费扣费那计费服务器的压力也还是不小的（因为计费操作通常是耗时耗资源的事务性操作）。不过这还是可以进一步优化的，因为这100万的QPS大部分的流量变化其实是很小的，完全可以进一步进行汇总，达到一定量才进行计费。因此，可以增加一个累积服务，就是达到一定量之后再进行一次计费，这平均降低到原来的1/10应该没什么问题，不过要注意，这可能会有明显的波峰波谷。

累积服务合并计费请求之后，对需要计费的请求再统一发送到计费MQ中。接下来就计费服务，这里完成计费扣费事务。在这里需要判断是否需要告警，如果满足告警的条件，就将告警信息推送到告警MQ里，由告警服务推送到用户的短信或者微信中。在计费服务中，还应该计算当前用户是否还可以进行请求，并把状态推送到缓存中，由基站使用。

为了能实现用户能够比较实时的查看账单信息，扣费记录还应该被推送到MPP数据库中（这里应该也是先推送到MQ，再从MQ消费到MPP）。

备用流量

为了避免扣费到负数而导致用户停机，在产品上用户应该可以设置一个备用流量，例如在用户停机之前可以设置50M的备用流量，在断网之后，用户可以启用该流量来进行充值等。不至于停机之后，出现完全没法操作这种非常不好的体验问题（充值需要先有流量，而需要有流量就得先充值）。（这个实现应该不难，成本也不高，只是不知道运营商的产品经理在想什么）

---------------------------

20220926地铁上