内部DSMP系统总体技术方案.docx

内部DSMP系统总体技术方案.docx

《内部DSMP系统总体技术方案.docx》由会员分享，可在线阅读，更多相关《内部DSMP系统总体技术方案.docx（19页珍藏版）》请在冰豆网上搜索。

内部DSMP系统总体技术方案

内部DSMP总体技术方案

拟制：

Carlinshu

日期：

2005-6-16

审核：

日期：

版本号：

XXXV1.0

腾讯科技（深圳）有限公司

修订日期

修订内容

协议版本

修订人

1背景

目前，腾讯业务是多承载、多支付、多定购方式的运行模式，各个业务部门都有各自的业务开通关闭系统、支付系统、移动接入系统，所有来源的开通/关闭操作都必须分发到不同部门的不同业务服务Server上，然后调用各自部门数据中心的开通/关闭实现业务的定购操作，各个数据中心Service通过准实时接口将计费数据同步到运营支持部的公司级BOSS系统。

目前的系统环境比较混乱，缺乏集中控制管理，为了做到部门职能清晰化、业务数据和计费数据分离、实时计费数据、统一消息转发、统一支付等集中管理控制，就需要开发内部DSMP系统，从而达到计费的长治久安、集中监控、集中统计、运营分析。

2概述

内部DSMP包含的子系统有：

公司级开通/关闭Service（以下简称开通关闭Service）、公共上行系统，公共下行系统、Provison服务系统、手机开通关闭平台、华为特殊指令处理平台。

基于内部DSMP系统的目的，其主要功能是：

能够控制所有来源的业务开通、关闭；

集中控制所有渠道的支付；

集中控制所有MO/MT消息的转发；

集中控制所有指令、业务代码的审批；

2.1范围

该文档主要描述开通关闭Service、公共上行系统、Provison服务系统、手机开通关闭平台、华为特殊指令处理平台的技术架构。

2.2引用标准

《内部DSMP总体方案.doc》

《2005年04月运营支持部内部DSMP项目计划.xls》

《增值BOSS数据库设计.doc》

《增值BOSS总体设计.doc》

《增值业务应用同步API接口.doc》

《个人帐户包月业务扣费规范.doc》

《增值帐务操作手册.doc》

《公共上下行系统监控统计需求.doc》

《内部DSMP手机平台需求.doc》

《统一开通关闭API.doc》

《LQ-MODE平台接口协议V2.1.doc》

《SMSMO接入系统概要设计说明书.doc》

《SMSMO接入系统需求规格说明书（内部版本）.doc》

《内部DSMP手机平台概要设计文档（3）.doc》

《下行系统概要设计_业务代码查询服务器.doc》

《下行系统业务代码屏蔽需求.doc》

《统一支付portal概要设计（草稿）.doc》

《统一支付portal个人帐户支付协议.doc》

《业务接入统一支付Portal指南.doc》

《BOSS和业务原始计费话单对帐规范（20040705）.doc》

《无线QQ计费话单出帐规范（2004-04-18修改）.doc》

《电信网通运营商规范.xls》

《无线QQ计费话单出帐规范（网通电信适用）.doc》

《Vnet离线支付工具使用说明.doc》

《vnet账单规范.doc》

《个人帐户批量扣款API使用说明书.doc》

《个人帐户批量扣款API使用说明书

（2）.doc》

《个人帐户批量扣款概要设计说明书.doc》

《Handle系统设计说明.doc》

《移动IM中心系统维护文档

（1）.doc》

《内部DSMP和反向同步Server接口协议3.doc》

《统一开通关闭server和Client协议.doc》

《统一开通关闭Service概要设计说明书.doc》

2.3术语和定义

名词

解释

2.4符号和缩略语

缩写

英文描述

中文描述

3总体架构设计

3.1设计原则

3.1.1产品关联性设计

●尽量保持各子模块的独立性

●在与其他产品进行交互时仅提供必须的接口，以减少复杂度和错误发生的可能性。

●在与其他产品交互的时候都通过一个中间进程进行，以降低产品之间的耦合性

●内部DSMP系统内部子系统主要通过TMPP协议，开通关闭协议进行数据交互。

●内部DSMP系统和外部系统（业务，客服，00000）通过开通关闭协议交互。

3.1.2产品依赖性设计

●尽可能重用公司内部已有的模块，以减少维护和开发的工作量。

如：

开通关闭协是在互联，互娱的内部数据中心的协议上修改而来。

●对于一些已有的产品，如果可以满足需求，直接整合到产品包中。

如：

内部DSMP中的下行系统，Provision已经在项目开始前已经完成，只需要修改就可以完成功能。

3.2设计目标

3.2.1路标规划

阶段

开始时间

完成时间

阶段目标和工作进度指标

慨要设计

2005年2月1日

2005年3月4日

●内部dsmp系统总体设计

●子模块概要设计

●公共上行系统编码修改完成

编码

2005年3月5日

2005年4月1日

●统一开通关闭service编码

●公共上行系统上线，割接所有地区，监控相关页面

编码，功能测试，系统测试

2005年4月2日

2005年4月30日

●统一开通关闭servcie测试

●业务部门的反向同步serverice测试

●手机开通关闭平台编码完成，测试

●Provision修改，测试

●手机开通渠道内部DSMP全流程测试。

●统一割接控制API在内部DSMP系统各模块中使用。

现网指定地区指定业务接入

2005年5月1日

2005年6月3日

●现网指定地区，指定业务特殊手机测试，并对现网测试问题修改。

●对BOSS数据和手机开通渠道的数据对比，做为割接基础。

●对指定地区的业务进行现网割接。

●完成割接参数提交文档，测试指导文档，割接文档。

现网指定地区指定业务接入

2005年6月4日

2005年6月30日

●对指定地区的业务进行现网割接。

●对外部地区的各种管理平台都进行覆盖。

全面割接

2005年7月

2005年10月

●进行对所有业务所有地区手机渠道全面割接

●对于portal的开通方式的接入。

3.3系统需求

3.3.1系统软件需求

●SlackwareLinux

●Vss版本管理系统

●Mysql3.23.51

●Apache1.3.29

3.3.2系统硬件需求

上行系统：

●DL380G4×4

●标配：

CPUP43.06G×2

●内存：

1GHPDDRRAM×6

●硬盘：

100G

开通关闭Service

●DL380G4×2

●标配：

CPUP43.06G×2

●内存：

1GHPDDRRAM×2

●硬盘：

100G

手机开通关闭平台

华为特殊指令透传处理平台

割接控制服务器

●DL380G4×3

●标配：

CPUP43.06G×2

●内存：

1GHPDDRRAM×2

●硬盘：

100G

3.3.3系统功能需求

Ø公司级开通/关闭Service：

负责所有腾讯业务的开通/关闭，设置BOSS计费数据，并调用各个业务部门的接口反向同步数据到各个业务部门；

Ø统一支付Portal：

负责所有非移动终端的定购支付请求，并调用公司级开通/关闭Service进行业务的开通/关闭；

Ø公共上行系统：

并且对于非DSMP地区以及透传指令部分，由定购/取消处理模块调用公司级开通关闭Service，对于需要二次确认的地区，此模块完成和用户的二次确认交互，将最终的定购信息传送给开通/关闭Service；

ØProvsion服务系统：

负责DSMP地区的开通/关闭操作，调用公司级开通/关闭Service；

内部DSMP得以应用之后，所有的开通/关闭都接入到公司级开通/关闭Service系统。

3.3.4系统性能需求

●DB方面：

内部DSMP系统操作的数据库是目前运营支持部已有的BOSS数据库，性能和容量上都能够满足，这部分在本系统中不做考虑。

●系统处理性能，开通关闭操作达到100条/秒，目前的统计来看，开通关闭业务的量在50条/秒左右。

●单条处理性能，单笔开通关闭的操作的时间<2s。

3.4系统总体架构

3.4.1系统物理架构

内部DSMP涉及的系统很多，物理连接上如下图：

3.4.2系统逻辑架构

内部DSMP逻辑分为三层：

●数据接入层：

具备的功能主要是接收各种方式的开通，关闭数据，并返回相应的处理结果。

主要包括手机开通渠道的接入，例如：

上行系统，Provison，华为特殊指令平台，手机处理平台。

Portal的接入，Vnet等非手机渠道的接入。

●数据处理层：

具备功能主要是对开通，关闭请求进行具体处理。

●用户数据层：

保存用户的开通，关闭数据。

4关键技术分析

4.1业务模型分析

4.1.1目标用户

涉及开通关闭操作的各种渠道，例如：

手机上行，provision，vnet,Esales等。

4.1.2用户入口

●使用开通关闭API连接统一开通关闭Service。

●直接使用开通关闭协议连接统一开通关闭service。

4.1.3收费策略

4.1.4产品依赖关系

内部DSMP系统和很多的系统需要交互

●上行系统，用户开通，关闭请求的提交。

●Portal，多种渠道的开通的交互。

●业务部分反向同步SERVER的交互。

4.1.5典型业务过程

一：

开通/关闭业务触发来源

ØWeb

Ø手机、小灵通

ØESales

Ø声讯

ØQQ客户端

二：

移动终端开通/关闭流程

非DSMP地区：

1）网关将用户的指令发送到Relay，relay转发给上行系统；

2）公共上行系统解析出消息是开通/关闭指控，则将消息转发给上行定购处理系统；

3）上行定购处理系统调用开通/关闭Service的接口进行操作；

4）开通关闭Service调用各个业务部门的反向同步Server接口，进行反向同步，反向同步Server将消息分发到不同的业务Server；

5）各个业务Server进行业务参数的解码（字符串协议），进行业务相关特性设置，调用各自部门的数据中心开通/关闭Service；

6）反向同步返回成功，公司级开通/关闭Service在BOSS中设置定购关系、支付关系；

DSMP地区：

1）网关将用户的指令发送到DSMP，DSMP调用腾讯Provision接口进行反向同步；

2）Provision进行一定的解码，调用公司级开通关闭接口；

3）开通关闭Service调用各个业务部门的接口，进行反向同步，反向同步Server将消息分发到不同的业务Server；

4）各个业务Server进行业务参数的解码（字符串协议），进行业务相关特性设置，调用各自部门的数据中心开通/关闭Service；

5）反向同步返回成功，公司级开通/关闭Service在BOSS中设置定购关系、支付关系；

三：

业务承载号码是QQ号码的处理

增值业务的承载号码都是QQ号码，当手机开通增值业务的时候：

1）开通指令未携带QQ号码

Ø开通关闭Service收到开通指令后，调用业务接口反向同步，反向同步Server将消息分发到不同的业务Server；

Ø业务Server发现没有QQ号码等业务附加信息，记录手机号码，发送下行消息提示用户输入QQ号码等附加信息；

Ø业务Server返回调用成功，开通关闭Service会先设置手机支付关系；

Ø用户回复QQ号码后，由于不带开通/关闭指令，上行系统会直接转发给业务Server；

Ø业务Server对QQ号码等附加信息进行解码后，通过反向同步Server调用开通/关闭Service的设置承载号码接口补充QQ号码；

2）开通指令携带了QQ号码

Ø开通关闭Service收到开通指令后，然后调用业务接口反向同步，反向同步Server将消息分发到不同的业务Server；

Ø业务Server对业务附加信息进行解码，发现已经包含QQ号码，则调用开通/关闭Service的设置承载号码接口补充QQ号码；

Ø开通关闭Service根据手机号码、QQ号码完成业务的定购。

备注：

无线产品部的业务承载号码都是手机号码、小灵通号码，不需要以上处理。

四：

二次确认

内部DSMP部署之后，二次确认的流程由内部DSMP负责完成，对于运营商已经上了类似DSMP设备的地区，运营商会进行二次确认，腾讯内部DSMP不需要处理这些地区的二次确认。

此特性由上行系统中的“定购/取消处理模块”完成，此模块需要进行的配置信息如下：

Ø分运营商配置需要进行二次确认的地区信息；

Ø分业务，配置不同业务的二次确认下发提示语；

Ø分业务，配置不同业务的定购成功提示语；

Ø分业务，配置不同业务，用户需要回复信息的格式，以便用户回复二次确认信息时，上行系统进行信息格式有效性校验；

Ø当用户回复二次确认信息时，需要分业务，配置不同业务的信息格式错误提示语；

Ø分业务，配置二次确认时用户回复的目的号码（即定购/取消处理模块发送下行消息时的主叫号码），上行系统需要将此目的号码带给定购/取消处理系统，定购/取消处理系统据此判断是用户回复的二次确认定购消息；

流程如图所示：

图6二次确认

备注：

1）对于联通在线，SPMS会将指令后面的内容去掉再传给上行系统，对于这种情况，业务Server应该下发提示消息要求用户补充业务信息，这样等于和用户进行了三次交互，用户感较差；

2）目前，有的业务为了避免3次交互，提示用户回复二次确认的消息里不加指令，而是一个特殊标志，对于这种情况，需要进行修改，一率要求用户二次确认时必须添加指令。

3）对于增值类业务，如果补充信息中含有QQ号码，应该通过如前3.2.4所述的方式将QQ回送给公司级开通/关闭Service。

4.2用户模型分析

4.2.1用户基础信息

用户数据来源于用户手机开通，关闭指令，目前支持100条/秒的并发处理能力。

4.2.2用户操作信息

用户开通峰值:

69个/秒

用户关闭峰值:

98个/秒

4.2.3用户流量信息

用户开通流量：

12.6Mb/min

用户关闭流量：

18Mb/min

4.3系统模型分析

4.3.1上行子系统

mo_recvd：

接受relayd的连接，把relay发过来的消息入预处理队列。

msg_router：

检测预处理队列（Preprocessqueue）中是否有未处理消息，如果有消息，则根据消息路由表的配置分发到特定的应用队列（AppQueue）；如果没有消息，进程进入睡眠状态。

msg_disp：

检测自己负责的AppQueue是否有消息，如果有消息则转发到指定的应用端口；如果没有消息，进程进入睡眠状态。

Admin：

监控进程。

Mo_recvd,msg_router,msg_disp会定期发送心跳包到控制内存区，admin通过共享内存命令区和配置区监控各个进程。

同时admin也接收用户的指令，启动、停止、查看系统。

Mo_recvd,msg_router,msg_disp三个子系统都会定期的读取共享内存命令，发现有发给自己的命令就执行。

4.3.2手机处理平台子系统

采用单进程，多线程的方式实现，主要功能如下：

1：

根据地区已经指令判断一个指令是否是合法的开通关闭指令。

2：

对已开通业务的指令进行透传。

3：

根据地区进行2次确认。

4：

根据处理结果，组合不同的提示消息发送相应的短信到用户。

4.3.3统一开通关闭service子系统

开通/关闭Service分为Client/API、消息分发模块（Dispatch）、消息处理模块（OCKer），在上图中，对于反向同步Server，Dispatch为Client端；对于其他实体，Dispatch作为Server端；

1）各个模块说明：

ØClient/API：

API提供短连接的调用，需要开通/关闭业务的系统调用API和Dispatch模块交互，完成业务的开通/关闭，每完成一次开通关闭流程，API会连接、断开一次。

对于需要长连接的系统，按照API和Dispatch之间的通讯协议进行交互即可；

Ø消息分发模块Dispatch：

收到API或客户端发出的开通/关闭请求后，根据号码将消息分发到对应的消息处理进程OCKerX进程，进行消息处理，同时将开通关闭类消息转发给业务部门的反向同步Server一份。

Ø消息处理模块OCKer：

此模块由可配置的多个Ker进程组成，每个Ker进程平均处理不同号段的消息（按照号码后两位分）；

2）内部模块交互流程

Ø外部系统调用API（或保持长连接）发送开通关闭请求到Dispatch；

ØDispatch根据号码分发到不同的OCKer进程处理，同时根据业务类型将消息转发一份给业务部门的反向同步Server，完成业务侧数据的设置；

ØDispatch以反向同步Server的处理结果为主，即反向同步Server处理完毕，Dispatch即返回响应给客户端，目的是保证对用户的响应时间不变。

如果OCKer的处理结果和反向同步Server的处理不一致，则Dispatch发送告警，并记录日志，后台程序定时对异常日志进行处理；

4.4性能容量分析

4.4.1上行子系统

存储要求

公式：

每秒记录条数*每条日志大小*消息日志种类*3600*24

计算结果：

150条/秒*400B*3*3600秒*24=14.5G

备注：

在预处理系统中已经有所有的日志，所以日志只保存30天。

带宽要求（内网）

备注：

150条/秒*400Betys*8Bit=0.5Mbps

带宽要求（外网）

备注：

不需要

机器要求

公式：

最大存储空间/每台的最大存储空间

计算结果：

14.5G*30/100G=4台G4

备注：

3台互为备份，1台为热备

4.4.2手机处理平台子系统

存储要求

公式：

每秒记录条数*每条日志大小*消息日志种类*3600*24

计算结果：

30条/秒*400B*3*3600秒*24=2.8G

备注：

日志只保存30天。

带宽要求（内网）

备注：

30条/秒*400Betys*8Bit=0.1Mbps

带宽要求（外网）

备注：

不需要

机器要求

公式：

最大存储空间/每台的最大存储空间

计算结果：

2.8*30/100G=1台G4

备注：

2台机器，通过DNS做实时备份和负荷分担

4.4.3开通关闭子系统

存储要求

公式：

每秒记录条数*每条日志大小*消息日志种类*3600*24

计算结果：

100条/秒*400B*2*3600秒*24=6.5G

备注：

日志只保存30天。

带宽要求（内网）

备注：

100条/秒*400Betys*8Bit=0.33Mbps

带宽要求（外网）

备注：

不需要

机器要求

公式：

最大存储空间/每台的最大存储空间

计算结果：

6.5*30/100G=2台G4

备注：

2台机器，通过DNS做实时备份和负荷分担

4.4.4总计

子系统名称

机器用途

存储要求

带宽要求（内网）

带宽要求（外网）

机器要求

上行子系统

Server

435G

0.5Mbps

可以忽略不计

4台G4

手机处理平台子系统

Server

84G

0.1Mbps

可以忽略不计

2台G4

开通关闭子系统

Server

195G

0.33Mbps

可以忽略不计

2台G4

合计：

714G

0.93Mbps

8台G4

4.5负载均衡分析

4.5.1负载均衡策略

内部DSMP系统内部模块通过DNS寻址来进行实时的热备和负载均衡。

4.5.2异地分布策略

暂时可以不考虑异地分布。

4.6容灾备份分析

内部DSMP系统中最主要的就是用户开通，关闭的日志和用户定购业务的状态数据。

对于用户上行的开通关闭指令和下行提示消息至少保存1年，目前在移动接入组的预处理系统中对用户的所有上行，下行进行了保存。

对于用户的定购，取消业务的流水数据在计费组的用户数据库中保存1年。

5部署方案

5.1上行子系统

机器IP

存放地点

备注

172.16.61.24

枢纽电信8楼VIP

部署上行消息处理系统

172.16.61.25

枢纽电信8楼VIP

部署上行消息处理系统

172.16.61.81

枢纽电信8楼VIP

部署上行消息处理系统

172.16.61.82

枢纽电信8楼VIP

部署上行消息处理系统（备份机器）

5.2手机处理平台子系统