内部DSMP系统总体技术方案.docx
《内部DSMP系统总体技术方案.docx》由会员分享，可在线阅读，更多相关《内部DSMP系统总体技术方案.docx（21页珍藏版）》请在冰豆网上搜索。
内部DSMP系统总体技术方案
内部总体技术方案
拟制：
Carlinshu
日期：
审核：
日期：
版本号：
腾讯科技（深圳）有限公司
修订日期
修订内容
协议版本
修订人
背景
概述
范围
引用标准
术语和定义
符号和缩略语
总体架构设计
设计原则
产品关联性设计原则
产品依赖性设计原则
设计目标
路标规划
系统需求
系统软件需求
系统硬件需求
系统功能需求
系统性能需求
系统总体架构
系统物理架构
系统逻辑架构
关键技术分析
业务模型分析
目标用户
用户入口
收费策略
产品依赖关系
典型业务过程
用户模型分析
用户基础信息
用户操作信息
用户流量信息
系统模型分析
性能容量分析
总计
负载均衡分析
负载均衡策略
异地分布策略
容灾备份分析
部署方案
风险分析及规避措施
硬件故障
软件故障
备选方案
1背景
目前，腾讯业务是多承载、多支付、多定购方式的运行模式，各个业务部门都有各自的业务开通关闭系统、支付系统、移动接入系统，所有来源的开通关闭操作都必须分发到不同部门的不同业务服务上，然后调用各自部门数据中心的开通关闭实现业务的定购操作，各个数据中心vice通过准实时接口将计费数据同步到运营支持部的公司级系统。
目前的系统环境比较混乱，缺乏集中控制管理，为了做到部门职能清晰化、业务数据和计费数据分离、实时计费数据、统一消息转发、统一支付等集中管理控制，就需要开发内部系统，从而达到计费的长治久安、集中监控、集中统计、运营分析。
2概述
内部包含的子系统有：
公司级开通关闭vice（以下简称开通关闭vice）、公共上行系统，公共下行系统、服务系统、手机开通关闭平台、华为特殊指令处理平台。
基于内部系统的目的，其主要功能是：
能够控制所有来源的业务开通、关闭；
集中控制所有渠道的支付；
集中控制所有消息的转发；
集中控制所有指令、业务代码的审批；
2.1范围
该文档主要描述开通关闭vice、公共上行系统、服务系统、手机开通关闭平台、华为特殊指令处理平台的技术架构。
2.2引用标准
《内部总体方案》
《00年月运营支持部内部项目计划ls》
《增值数据库设计》
《增值总体设计》
《增值业务应用同步接口》
《个人帐户包月业务扣费规范》
《增值帐务操作手册》
《公共上下行系统监控统计需求》
《内部手机平台需求》
《统一开通关闭》
《LQ平台接口协议》
《接入系统概要设计说明书》
《接入系统需求规格说明书（内部版本）》
《内部手机平台概要设计文档（）》
《下行系统概要设计业务代码查询服务器》
《下行系统业务代码屏蔽需求》
《统一支付概要设计（草稿）》
《统一支付个人帐户支付协议》
《业务接入统一支付指南》
《和业务原始计费话单对帐规范（2004）》
《无线QQ计费话单出帐规范（2004-04-18修改）》
《电信网通运营商规范ls》
《无线QQ计费话单出帐规范（网通电信适用）》
《离线支付工具使用说明》
《账单规范》
《个人帐户批量扣款使用说明书》
《个人帐户批量扣款使用说明书（）》
《个人帐户批量扣款概要设计说明书》
《系统设计说明》
《移动中心系统维护文档（）》
《内部和反向同步接口协议》
《统一开通关闭和协议》
《统一开通关闭vice概要设计说明书》
2.3术语和定义
名词
解释
2.4符号和缩略语
缩写
英文描述
中文描述
3总体架构设计
3.1设计原则
3.1.1产品关联性设计
●尽量保持各子模块的独立性
●在与其他产品进行交互时仅提供必须的接口，以减少复杂度和错误发生的可能性。
●在与其他产品交互的时候都通过一个中间进程进行，以降低产品之间的耦合性
●内部系统内部子系统主要通过协议，开通关闭协议进行数据交互。
●内部系统和外部系统（业务，客服，）通过开通关闭协议交互。
3.1.2产品依赖性设计
●尽可能重用公司内部已有的模块，以减少维护和开发的工作量。
如：
开通关闭协是在互联，互娱的内部数据中心的协议上修改而来。
●对于一些已有的产品，如果可以满足需求，直接整合到产品包中。
如：
内部中的下行系统，已经在项目开始前已经完成，只需要修改就可以完成功能。
3.2设计目标
3.2.1路标规划
阶段
开始时间
完成时间
阶段目标和工作进度指标
慨要设计
年月日
年月日
●内部系统总体设计
●子模块概要设计
●公共上行系统编码修改完成
编码
年月日
年月日
●统一开通关闭vice编码
●公共上行系统上线，割接所有地区，监控相关页面
编码，功能测试，系统测试
年月日
年月日
●统一开通关闭测试
●业务部门的反向同步erice测试
●手机开通关闭平台编码完成，测试
●修改，测试
●手机开通渠道内部全流程测试。
●统一割接控制在内部系统各模块中使用。
现网指定地区指定业务接入
年月日
年月日
●现网指定地区，指定业务特殊手机测试，并对现网测试问题修改。
●对数据和手机开通渠道的数据对比，做为割接基础。
●对指定地区的业务进行现网割接。
●完成割接参数提交文档，测试指导文档，割接文档。
现网指定地区指定业务接入
年月日
年月日
●对指定地区的业务进行现网割接。
●对外部地区的各种管理平台都进行覆盖。
全面割接
年月
年月
●进行对所有业务所有地区手机渠道全面割接
●对于的开通方式的接入。
3.3系统需求
3.3.1系统软件需求
●ckLin
●版本管理系统
●ysq3.23.51
●1.3.29
3.3.2系统硬件需求
上行系统：
●380G×
●标配：
3.06G×
●内存：
1G×
●硬盘：
开通关闭vice
●380G×
●标配：
3.06G×
●内存：
1G×
●硬盘：
手机开通关闭平台
华为特殊指令透传处理平台
割接控制服务器
●380G×
●标配：
3.06G×
●内存：
1G×
●硬盘：
3.3.3系统功能需求
Ø公司级开通关闭vice：
负责所有腾讯业务的开通关闭，设置计费数据，并调用各个业务部门的接口反向同步数据到各个业务部门；
Ø统一支付：
负责所有非移动终端的定购支付请求，并调用公司级开通关闭vice进行业务的开通关闭；
Ø公共上行系统：
并且对于非地区以及透传指令部分，由定购取消处理模块调用公司级开通关闭vice，对于需要二次确认的地区，此模块完成和用户的二次确认交互，将最终的定购信息传送给开通关闭vice；
Ø服务系统：
负责地区的开通关闭操作，调用公司级开通关闭vice；
内部得以应用之后，所有的开通关闭都接入到公司级开通关闭vice系统。
3.3.4系统性能需求
●方面：
内部系统操作的数据库是目前运营支持部已有的数据库，性能和容量上都能够满足，这部分在本系统中不做考虑。
●系统处理性能，开通关闭操作达到条秒，目前的统计来看，开通关闭业务的量在条秒左右。
●单条处理性能，单笔开通关闭的操作的时间<。
3.4系统总体架构
3.4.1系统物理架构
内部涉及的系统很多，物理连接上如下图：
3.4.2系统逻辑架构
内部逻辑分为三层：
●数据接入层：
具备的功能主要是接收各种方式的开通，关闭数据，并返回相应的处理结果。
主要包括手机开通渠道的接入，例如：
上行系统，，华为特殊指令平台，手机处理平台。
的接入，等非手机渠道的接入。
●数据处理层：
具备功能主要是对开通，关闭请求进行具体处理。
●用户数据层：
保存用户的开通，关闭数据。
4关键技术分析
4.1业务模型分析
4.1.1目标用户
涉及开通关闭操作的各种渠道，例如：
手机上行，，,等。
4.1.2用户入口
●使用开通关闭连接统一开通关闭vice。
●直接使用开通关闭协议连接统一开通关闭vice。
4.1.3收费策略
4.1.4产品依赖关系
内部系统和很多的系统需要交互
●上行系统，用户开通，关闭请求的提交。
●，多种渠道的开通的交互。
●业务部分反向同步的交互。
4.1.5典型业务过程
一：
开通关闭业务触发来源
Ø
Ø手机、小灵通
Ø
Ø声讯
ØQQ客户端
二：
移动终端开通关闭流程
非地区：
1）网关将用户的指令发送到，转发给上行系统；
2）公共上行系统解析出消息是开通关闭指控，则将消息转发给上行定购处理系统；
3）上行定购处理系统调用开通关闭vice的接口进行操作；
4）开通关闭vice调用各个业务部门的反向同步接口，进行反向同步，反向同步将消息分发到不同的业务；
5）各个业务进行业务参数的解码（字符串协议），进行业务相关特性设置，调用各自部门的数据中心开通关闭vice；
6）反向同步返回成功，公司级开通关闭vice在中设置定购关系、支付关系；
地区：
1）网关将用户的指令发送到，调用腾讯接口进行反向同步；
2）进行一定的解码，调用公司级开通关闭接口；
3）开通关闭vice调用各个业务部门的接口，进行反向同步，反向同步将消息分发到不同的业务；
4）各个业务进行业务参数的解码（字符串协议），进行业务相关特性设置，调用各自部门的数据中心开通关闭vice；
5）反向同步返回成功，公司级开通关闭vice在中设置定购关系、支付关系；
三：
业务承载号码是QQ号码的处理
增值业务的承载号码都是QQ号码，当手机开通增值业务的时候：
1）开通指令未携带QQ号码
Ø开通关闭vice收到开通指令后，调用业务接口反向同步，反向同步将消息分发到不同的业务；
Ø业务发现没有QQ号码等业务附加信息，记录手机号码，发送下行消息提示用户输入QQ号码等附加信息；
Ø业务返回调用成功，开通关闭vice会先设置手机支付关系；
Ø用户回复QQ号码后，由于不带开通关闭指令，上行系统会直接转发给业务；
Ø业务对QQ号码等附加信息进行解码后，通过反向同步调用开通关闭vice的设置承载号码接口补充QQ号码；
2）开通指令携带了QQ号码
Ø开通关闭vice收到开通指令后，然后调用业务接口反向同步，反向同步将消息分发到不同的业务；
Ø业务对业务附加信息进行解码，发现已经包含QQ号码，则调用开通关闭vice的设置承载号码接口补充QQ号码；
Ø开通关闭vice根据手机号码、QQ号码完成业务的定购。
备注：
无线产品部的业务承载号码都是手机号码、小灵通号码，不需要以上处理。
四：
二次确认
内部部署之后，二次确认的流程由内部负责完成，对于运营商已经上了类似设备的地区，运营商会进行二次确认，腾讯内部不需要处理这些地区的二次确认。
此特性由上行系统中的“定购取消处理模块”完成，此模块需要进行的配置信息如下：
Ø分运营商配置需要进行二次确认的地区信息；
Ø分业务，配置不同业务的二次确认下发提示语；
Ø分业务，配置不同业务的定购成功提示语；
Ø分业务，配置不同业务，用户需要回复信息的格式，以便用户回复二次确认信息时，上行系统进行信息格式有效性校验；
Ø当用户回复二次确认信息时，需要分业务，配置不同业务的信息格式错误提示语；
Ø分业务，配置二次确认时用户回复的目的号码（即定购取消处理模块发送下行消息时的主叫号码），上行系统需要将此目的号码带给定购取消处理系统，定购取消处理系统据此判断是用户回复的二次确认定购消息；
流程如图所示：
图二次确认
备注：
1）对于联通在线，SP会将指令后面的内容去掉再传给上行系统，对于这种情况，业务应该下发提示消息要求用户补充业务信息，这样等于和用户进行了三次交互，用户感较差；
2）目前，有的业务为了避免次交互，提示用户回复二次确认的消息里不加指令，而是一个特殊标志，对于这种情况，需要进行修改，一率要求用户二次确认时必须添加指令。
3）对于增值类业务，如果补充信息中含有QQ号码，应该通过如前所述的方式将QQ回送给公司级开通关闭vice。
4.2用户模型分析
4.2.1用户基础信息
用户数据来源于用户手机开通，关闭指令，目前支持条秒的并发处理能力。
4.2.2用户操作信息
用户开通峰值:
个秒
用户关闭峰值:
个秒
4.2.3用户流量信息
用户开通流量：
12
用户关闭流量：
4.3系统模型分析
4.3.1上行子系统
：
接受的连接，把发过来的消息入预处理队列。
：
检测预处理队列（roc）中是否有未处理消息，如果有消息，则根据消息路由表的配置分发到特定的应用队列（）；如果没有消息，进程进入睡眠状态。
sp：
检测自己负责的是否有消息，如果有消息则转发到指定的应用端口；如果没有消息，进程进入睡眠状态。
：
监控进程。
sp会定期发送心跳包到控制内存区，通过共享内存命令区和配置区监控各个进程。
同时也接收用户的指令，启动、停止、查看系统。
sp三个子系统都会定期的读取共享内存命令，发现有发给自己的命令就执行。
4.3.2手机处理平台子系统
采用单进程，多线程的方式实现，主要功能如下：
：
根据地区已经指令判断一个指令是否是合法的开通关闭指令。
：
对已开通业务的指令进行透传。
：
根据地区进行次确认。
：
根据处理结果，组合不同的提示消息发送相应的短信到用户。
4.3.3统一开通关闭vice子系统
开通关闭vice分为、消息分发模块（sp）、消息处理模块（CK），在上图中，对于反向同步，sp为端；对于其他实体，sp作为端；
）各个模块说明：
Ø：
提供短连接的调用，需要开通关闭业务的系统调用和sp模块交互，完成业务的开通关闭，每完成一次开通关闭流程，会连接、断开一次。
对于需要长连接的系统，按照和sp之间的通讯协议进行交互即可；
Ø消息分发模块sp：
收到或客户端发出的开通关闭请求后，根据号码将消息分发到对应的消息处理进程CK进程，进行消息处理，同时将开通关闭类消息转发给业务部门的反向同步一份。
Ø消息处理模块CK：
此模块由可配置的多个进程组成，每个进程平均处理不同号段的消息（按照号码后两位分）；
）内部模块交互流程
Ø外部系统调用（或保持长连接）发送开通关闭请求到sp；
Øsp根据号码分发到不同的CK进程处理，同时根据业务类型将消息转发一份给业务部门的反向同步，完成业务侧数据的设置；
Øsp以反向同步的处理结果为主，即反向同步处理完毕，sp即返回响应给客户端，目的是保证对用户的响应时间不变。
如果CK的处理结果和反向同步的处理不一致，则sp发送告警，并记录日志，后台程序定时对异常日志进行处理；
4.4性能容量分析
4.4.1上行子系统
存储要求
公式：
每秒记录条数*每条日志大小*消息日志种类**
计算结果：
条秒***秒*
备注：
在预处理系统中已经有所有的日志，所以日志只保存天。
带宽要求（内网）
备注：
条秒**
带宽要求（外网）
备注：
不需要
机器要求
公式：
最大存储空间每台的最大存储空间
计算结果：
*台
备注：
台互为备份，台为热备
4.4.2手机处理平台子系统
存储要求
公式：
每秒记录条数*每条日志大小*消息日志种类**
计算结果：
条秒***秒*
备注：
日志只保存天。
带宽要求（内网）
备注：
条秒**
带宽要求（外网）
备注：
不需要
机器要求
公式：
最大存储空间每台的最大存储空间
计算结果：
*台
备注：
台机器，通过做实时备份和负荷分担
4.4.3开通关闭子系统
存储要求
公式：
每秒记录条数*每条日志大小*消息日志种类**
计算结果：
条秒***秒*
备注：
日志只保存天。
带宽要求（内网）
备注：
条秒**
带宽要求（外网）
备注：
不需要
机器要求
公式：
最大存储空间每台的最大存储空间
计算结果：
*台
备注：
台机器，通过做实时备份和负荷分担
4.4.4总计
子系统名称
机器用途
存储要求
带宽要求（内网）
带宽要求（外网）
机器要求
上行子系统
可以忽略不计
台
手机处理平台子系统
可以忽略不计
台
开通关闭子系统
可以忽略不计
台
合计：
台
4.5负载均衡分析
4.5.1负载均衡策略
内部系统内部模块通过寻址来进行实时的热备和负载均衡。
4.5.2异地分布策略
暂时可以不考虑异地分布。
4.6容灾备份分析
内部系统中最主要的就是用户开通，关闭的日志和用户定购业务的状态数据。
对于用户上行的开通关闭指令和下行提示消息至少保存年，目前在移动接入组的预处理系统中对用户的所有上行，下行进行了保存。
对于用户的定购，取消业务的流水数据在计费组的用户数据库中保存年。
5部署方案
5.1上行子系统
机器
存放地点
备注
枢纽电信楼
部署上行消息处理系统
枢纽电信楼
部署上行消息处理系统
枢纽电信楼
部署上行消息处理系统
枢纽电信楼
部署上行消息处理系统（备份机器）
5.2手机处理平台子系统
机器
存放地点
备注
.21
枢纽电信楼
部署手机处理平台，割接控制，华为处理平台。
枢纽电信楼
部署手机处理平台，割接控制，华为处理平台。
5.3开通关闭处理子系统
机器
存放地点
备注
枢纽电信楼
部署手开通关闭vice
枢纽电信楼
部署手开通关闭vice
6风险分析及规避措施
总的来讲，风险可以分成硬件故障和软件故障两大类。
硬件的故障包括机器的故障、磁盘故障等。
软件的故障包括数据库失效等等。
6.1硬件故障
针对不同的硬件故障，提供不同的应对策略。
6.1.1机器、磁盘故障
对于机器或者磁盘故障的应对方式有两种：
主动方式：
对运行一些重要应用的机器提供寻址，双机热备，负荷分担。
当其中一台失效的时候，由另一台接管其工作。
采用这种方式，可以把故障的处理时间降到分钟。
在另一台机器接管工作之后，再对故障机器进行检查，根据具体情况或更换、或修理。
在失效机器恢复正常之后，失效机器以备机的身份重新开始服务。
被动方式：
对于运行不重要应用的机器提供快速更换服务。
快速更换服务指的是机器上的应用和配置都已准备好，当出现故障，需要更换其它机器时，只要对该服务器稍作修改就可以代替故障机器。
采用第一个方式，关键系统采用双机热备的方式，保证系统正常工作。
6.2软件故障
6.2.1数据库
内部系统操作的的数据服务器使用ysq，数据采用双机热备，每天对当天的数据进行打包备份，每周进行一次全量的备份。
当出现问题时可以从备份的数据中及时恢复。
7备选方案
无
升级会员 