计费软控的实现理解

 

                 

                                             

 

 

 

 

 

 

1 消息接口

 

1.1 用户状态接口

数据流向：软控系统->省份控制节点

Request Get:http://xxxx:xx/rk/audit?ACC_NBR=18XXXXXXXX

 

Response:

{

"CODE":"0",                 ----0  查询成功   -1 号码不存在，号码格式错误  -2 软停状态不存在  -3 系统内部错误

"RT_STATUS":"0",            ---- 0  开机状态    1 软停状态

"UPDATE_TIME":"20200517143200"

}

 

1.2 软控请求消息

数据流向：省分控制节点->软控系统

待省分控制节点提供，包含信息用户号码、会话ID、归属地省分代码、拜访地省分代码和业务时间戳。

{

  "MSI": "13078782556",   //用户号码

"SESSION_ID":"d1-saegw06.km.yn.node.epc.mnc001.mcc460.3gppnetwork.org;1613787365;1106935783;460018787012068", //会话ID

  "LOCAL_PROV_CODE": "86",  //归属省

 "VISIT_PROV_CODE": "86",   //拜访地

  "DATETIME": "20210220151914" //业务时间

}

 

1.3 软控应答消息

数据流向：软控系统->省分控制节点

{

"CUSTINFOREQUEST": {

      "MSGHEADER": {

         "MSGTYPE": "RK",

            "RECORDTYPE": "021",

            "VERSION": "01"

      },

      "MSGBODY": {

            "MSISDN": "18688888888",

            "PROVINCE_CODE": "51",

            "OPERTIME": "20141225173810",

            "STATUS": "1"  0  开机    1  停机

        }

    }

}

1.4 开机通知消息

数据流向：信控中心->软控系统

 

1.5 计费因子消息

数据流向：软控系统->省分控制节点

{

"RGINFOREQUEST": {

      "MSGHEADER": {

         "MSGTYPE": "RK",

            "RECORDTYPE": "022",

            "VERSION": "01"

        },

    "MSGBODY": {

            "RATING_GROUP": "17001",

            "PROVINCE_CODE": "51",

            "OPERTIME": "20141225173810",

            "STATUS": "1"  0  新增    1  删除

        }

    }

}

 

 

 

 

2 设计说明

 

 

1.1.1 平台管理

1.1.1.1 实现描述

1. 停开机规则配置页面，支持停开机规则的新增、删除、修改和查询功能，后台提供停开机规则信息服务，业务涉及停开机判断规则表(CONDITION_JUDGE_RULE)；

2. 免费rg信息配置页面，支持新增和删除功能，后台提供rg信息服务，业务涉及RG表(RG_CODE)；

ü 新增rg，查询mysql的rg_code表是否存在rg，存在则不做操作，否则往kafka中写入rg新增消息。

ü 删除rg，查询mysql的rg_code表是否存在rg，存在则否则往kafka中写入rg删除消息。

ü 查询rg，根据查询条件查询返回mysql所有的rg，查询条件有rg+省分代码。

3. 紧急开机配置页面，支持单个用户紧急开机和批量用户紧急开机导入，查询紧急开机信息，后台提供紧急开机服务；

ü 单用户开机调用开机通知中的开机服务。

ü 批量开机对每个用户循环调用一次开机通知中的开机服务。

4. 信控用户配置页面，支持单个用户新增、修改、删除、分页查询(查询条件用户号码+省分组合条件)和批量导入，后台提供信控用户信息服务，业务涉及信控用户名单表(CREDIT_CONTOL_USER)；

5. 停机记录查询页面，支持停机记录查询和新增功能，查询条件为用户号码+日期+省分的组合条件，后台提停机信息服务，业务涉及用户操作状态表(USER_OPERATE_STATUS)；

6. 开机记录查询页面，支持开机记录查询和修改功能，查询条件为用户号码+日期+省分的组合条件，后台提供开机信息服务，业务涉及开机记录表(OPEN_RECORD)；

7. 路由规则配置页面，支持路由规则的新增、删除、修改和查询功能，后台提供路由信息服务，业务涉及路由规则表(ROUTE _RULE)；

 

1.1.2 信息同步                                   

1.1.2.1 实现描述

1. 使用数据传输服务组件DTS同步mysql到redis的数据。

2. 实时增量同步和全量同步两种方式，监听mysql的数据变化。

3. 业务主流程如下图：

                 

1.1.3 用户稽核           

1.1.3.1 实现描述

1. 稽核程序实现增量用户稽核和全量用户稽核两种模式，增量稽核扫描的是当天停机的用户记录，休眠时间可配置，全量稽核扫描的是全部停机的用户记录，每天零点启动执行一次。

2. 业务主流程入下图：

      

 

 

 

                               

 

1.1.4 产品稽核     

1.1.4.1 实现描述

1. 定时任务，每月1号零点开始启动处理一次业务。

2. 匹配稽核产品需要使用用户订购的主产品和用户归属省分进行比较。

3. 业务主流程如下图：

          

 

 

 

                     

1.1.5 软控消息接入                            

1.1.5.1 实现描述

1. 支持从多个kafka中读取消息，kafka信息可配置。

2. 解析消息中关键字段用户号码、拜访省份和归属省份，有效用户则使用拜访省分匹配信控用户表的信控节点。

3. 用户号码必须做标准化后再查询信控用户名单表，如果长度大于11位，直接截止后11位长度。

4. 支持消息写入目标MQ，MQ组信息可配置。

5. 匹配不到对应的MQ队列，则将消息丢弃并写告警日志。

6. 信控节点MQ按照承载用户量评估进行域规划，比如广东属于I域，天津、安徽、海南属于II域等。

7. 先按用户号码+表名匹配用户是否为有效信控用户，再按该用户归属省分+表名是否存在通配号码，是则为信控用户。

8. 路由分发单元，用于解析接收到的智能终端请求消息中的关键信息，比如用户号码信息等，根据路由规则找到路由节点，对于找不到路由信息的号码都统一路由到默认节点，此外，还用于解析应答消息中的关键信息，比如会话ID等，根据会话ID通过分布式高速缓存查询相关路由信息，将路由信息和请求消息内容保存到分布式高速缓存，路由信息用于后续的应答消息原路返回。

9. 业务主流程如下图：

    

 

 

 

                              

                           

1.1.6 消息路由

1.1.6.1 实现描述            

1. 监听kafka新（protobuf）旧（ogg）消息并解析，然后转化为mq消息，按表划分topic发送MQ消息，最后推送到数据下沉模块；

2. 转化mq消息条件：

ü kafka消息需支持转换器转化；

ü kafka消息内容的表必须是配置指定需要处理的表；（参考8.1.1 , 8.1.2）

ü 如果是ogg消息，kafka消息内容的scnId需大于等于配置对应的域对应表的scnId的值；

ü eg: 通过kafka消息内容schema的值找到对应配置的域，根据配置当前域查找消息内容的table对应的scnId，然后将配置查找到的scnId与解析消息内容的scnId的值做比较；

ü 如果是protobuf消息，kafka消息内容的timestamp需大于等于配置对应表的timestamp；

3. mq消息顺序问题：

ü 以user_id作为分区键发送顺序消息，保证同个用户的操作都在同个分区；

4. 业务主流程如下图：

          

 

 

 

 

1.1.7 实时信控

1.1.7.1 实现描述

1. 用户的信用度来源于用户表TF_F_USER，实时余额来源于用户实时结余表TF_O_LEAVERREALFEE，订购主产品来源于用户订购关系表TF_F_USER_PRODUCT，信用等级来源于用户表TF_F_USER。

2. 规则匹配优先级，省分+主产品 > 省分+通配主产品。

3. 解析消息中关键字段，用户号码和业务时间戳，使用归属省分匹配信控规则中的条件。

4. 用户号码必须做标准化后再查询用户表，如果长度大于11位，直接截止后11位长度。

5. 用户的可用余额 = 实时余额 + 信用度。

6. 确定用户停机前需要调用能力平台的实时余额查询能力，查询失败以本地数据为准。

7. 开机X时间内不能停机，X时间实现可配置。

8. X周期内停机数量达到N后，后续的所有停机操作都将暂停，直至手工发信号通知恢复，X和Y时间可配置。

9. 本地查询三户资料失败，则调用总部能力平台的用户资料三户返回能力查询用户的三户资料。

10. 业务主流程如下图：

              

 

 

 

                       

11. 数据模型设计如下图：

  

 

 

 

 

                  

1.1.8 实时鉴权

1.1.8.1 实现描述

1. 程序后端连接消息计费通信链路和kafka集群，所有请求包优先转发给消息计费链路，只有UT包才转发给kafka集群。

2. 接收到CCR时，转发完请求包需要在redis里保存会话记录，计费用户信息标准化后再保存，以便CCA可以通过会话ID找到用户号码信息，会话失效时间为2小时。

3. 接收到CCA时，需查询用户鉴权表，用户处于停机状态则将CCA的所有收费RG的返回码修改成4012，用户处于动态配额状态则将所有收费RG的配额修改成最新配额，删除会话表记录。

4. 查询redis的表信息失败，不做任何的修改报文动作，先保证请求可以正常返回。

5. 用户在白名单中且有效，该用户不动态配额、不软停机。

6. 配置项MSG_CLONE_FLAG = 0   0 不开启   1 开启

7. 业务主流程如下图：

 

 

                              

8. 数据模型设计如下图：

                    

 

 

 

1.1.9 短信触发

1.1.9.1 实现描述

1. 接收并处理cbss_svc生成的余额变更 kafka消息；

2. 过滤不需要发送低余额提醒的请求；

3. 无有效50544服务tf_f_user_svc消息,过滤；

4. 无用户信息bf_subscriber消息,过滤；

5. 在用户表(tf_f_user)得到用户信用额度后，重新计算得到用户实时余额（用户实际余额=用户余额+信用额度）及旧实时余额（旧实时余额=旧实时余额+信用额度）。

6. 用户余额跨阈值下发短信；

7. 当用户存在旧余额时:旧余额大于最大阈值;新余额大于等于最小阈值,小于最大阈值时;则下发当前规则的短信；

8. 当用户不存在旧余额时:新余额大于等于最小阈值,小于最大阈值时;则下发当前规则的短信；

9. 跨阈值请求,写短信下发表PRE_SMS_TO_SMSC_REAL。

10. 业务主流程如下图：

            

 

 

                 

 

1.1.10 短信下发

1.1.10.1 实现描述

1. 预警提醒短信统一模板化设计，模板中对于变动内容比如余额可以用F来代替，在获取到用户真实余额后再进行更替。

2. 短信下发支持重试功能，重试次数可配置，在短信下发失败后可以尝试重新下发N次。

3. 对于长短信(长度大于163个字节)需将短信进行拆分，每次下发短信的最大长度为163个字节，分批下发由第三方进行短信合并，比如短信中心。

4. 以下发成功的短信在数据库中保存3个月，对于3个月外的短信在月初统一进行运维删除。

5. 短信报文支持以SMPP+或SGIP+电信规范协议跟第三方进行通信。

6. 应用程序支持与第三方应用进行重连，在链路断开时可以尝试N次重连，链接成功则继续下发短信。

7. 应用程序在启动时需与第三方进行登录鉴权认证，认证通过后运行下发短信。

                                

1.1.11 失控容灾

1.1.11.1 实现描述

1. 定时通过http方式与第三方应用问询，确认第三方应用的正常运行，时间间隔可配置，暂建议为3秒一次。

2. 在确定第三应用为不健康状态时，平台将自动关闭软控功能，保证业务的正常使用。

3. 平台关闭软控功能包括即将软控和已经软控的状态用户。

4. 确认第三方不健康的策略可配置，比如连续1分钟内第三方应用的应答失败率是90%，连续2分钟内第三方应用的应答延时率是90%。

失控容灾自动触发后应写入告警短信、触发告警电话等方式通知运维人员进行介入处理，及时了解系统运行状况。

1.1.12 监控告警        

1.1.12.1 实现描述

1. 监控数据包括周期内的停机量、开机量、开机成功量、开机失败量、kafka接收到的请求量、kafka积压量、MQ接收到的请求量和MQ的积压量。

2. 数据模型设计如下图：