Page 19 - 网络电信2019年1/2月刊下

运 营 商 专 栏
图2 策略控制计费情况下网元与OCS系统的交互方式示意
表1 OCS系统的流量话单交易数
如果再算上智能管道业务区分内容差异化计费的场景，按
每次上网连接仅5项应用内容估算，交易数上浮将为30%，在线
交易数将达到70亿以上，折算到每天将达到2.2亿交易数。
如果再考虑5G网络的放号和物联网等频繁连接应用的产
生，交易数量还会不断上升，而且会出现突发的业务量，急需
可以平滑扩容的应用方案。
四、可行的应对方案建议
1、方案一
总体思路为：应用与存储剥离，继续使用Oracle、TT，以
客户ID为索引区分应用服务器。如图3所示。
图3 方案一示意图
30
（1）CBP应用节点的数据按照客户ID分段定义拆分规则，
每个CBP上的内存数据库只加载其中一部分客户ID相关的数据；
（2）DCCProxy中保存了客户ID的路由信息，支持按照DCC
消息请求号码找到客户ID并路由到对应的CBP节点。
（3）BMP保存了客户ID路由信息，对资料接口、充值接
口、帐务接口等外部请求能够路由到相应的CBP节点上的应用来
处理。
（4）每个应用节点之间两两备份，以便出现异常后可由备
份应用接管处理。
（5）当应用服务器或MDB处理能力不够时，可以方便地修
改客户ID分段拆分规则，将一部分的客户段挪到其他服务器或
平滑扩容机器支撑。
（6）支持群类业务等可能跨数据库应用的处理，跨库成员
通过应用访问所在的MDB获取相关的信息进行处理。
（7）资料更改引起的客户路由信息发生变更时，支持把该
客户相关数据自动迁移到新的CBP节点上。
2、方案二
总体思路为：将应用与存储剥离，放弃Oracle、TT，改
用分布式数据存放，关键信息分库分表、利用缓存加快访问效
率。如图4所示。
图4 方案二示意图
当用户规模和交易量逐步增加，所有应用访问同一共享数
据库将导致性能低下，采用Oracle数据库集群成本过高，因此
建议采用MySQL+x86方式实现清量级的分库分表处理，分布式数
据层解决应用对数据的透明读写，应用先读缓存，无法命中再
访问数据层，写的时候也先写缓存，缓存通过数据层异步方式
写入DB。
（1）用客户ID分库将无法解决大帐户问题，因此本方案建
议按设备ID分段定义拆分规则，同时将累积量、余额与用户资
料分开独立存放。
（2）DCCProxy中保存了设备ID的路由信息，支持按照DCC
消息请求号码根据算法路由到对应的CBP节点；BMP也要保存了
设备ID路由信息，对资料接口、充值接口、帐务接口等外部请
求能够路由到相应的CBP节点上的应用来处理（处理同图3）；
每个应用节点之间两两备份，以便出现异常后可由备份应用接
管处理。
（3）增加分布式数据层，应用侧不需要了解数据存放物理
网络电信 二零一九年一、二月