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

1、内部DSMP系统总体技术方案内部DSMP总体技术方案拟制：Carlinshu日期：2005-6-16审核：日期：版本号：XXX V1.0 腾讯科技（深圳）有限公司修订日期修订内容协议版本修订人1 背景目前，腾讯业务是多承载、多支付、多定购方式的运行模式，各个业务部门都有各自的业务开通关闭系统、支付系统、移动接入系统，所有来源的开通/关闭操作都必须分发到不同部门的不同业务服务Server上，然后调用各自部门数据中心的开通/关闭实现业务的定购操作，各个数据中心Service通过准实时接口将计费数据同步到运营支持部的公司级BOSS系统。 目前的系统环境比较混乱，缺乏集中控制管理，为了做到部门职能清晰

2、化、业务数据和计费数据分离、实时计费数据、统一消息转发、统一支付等集中管理控制，就需要开发内部DSMP系统，从而达到计费的长治久安、集中监控、集中统计、运营分析。2 概述内部DSMP包含的子系统有：公司级开通/关闭Service（以下简称开通关闭Service）、公共上行系统，公共下行系统、Provison服务系统、手机开通关闭平台、华为特殊指令处理平台。基于内部DSMP系统的目的，其主要功能是：能够控制所有来源的业务开通、关闭；集中控制所有渠道的支付；集中控制所有MO/MT消息的转发；集中控制所有指令、业务代码的审批；2.1 范围该文档主要描述开通关闭Service、公共上行系统、Provi

3、son服务系统、手机开通关闭平台、华为特殊指令处理平台的技术架构。2.2 引用标准内部DSMP总体方案.doc2005年04月运营支持部内部DSMP项目计划.xls增值BOSS数据库设计.doc增值BOSS总体设计.doc增值业务应用同步API接口.doc个人帐户包月业务扣费规范.doc增值帐务操作手册.doc公共上下行系统监控统计需求.doc内部DSMP手机平台需求.doc统一开通关闭API.docLQ-MODE平台接口协议V2.1.docSMS MO接入系统概要设计说明书.docSMS MO接入系统需求规格说明书(内部版本).doc内部DSMP手机平台概要设计文档(3).doc下行系统概要

4、设计_业务代码查询服务器.doc下行系统业务代码屏蔽需求.doc统一支付portal概要设计（草稿）.doc统一支付portal个人帐户支付协议.doc业务接入统一支付Portal指南.docBOSS和业务原始计费话单对帐规范(20040705).doc无线QQ计费话单出帐规范(2004-04-18修改).doc电信网通运营商规范.xls无线QQ计费话单出帐规范(网通电信适用).docVnet离线支付工具使用说明.docvnet账单规范.doc个人帐户批量扣款API使用说明书.doc个人帐户批量扣款API使用说明书(2).doc个人帐户批量扣款概要设计说明书.docHandle系统设计说明.d

5、oc移动IM中心系统维护文档(1).doc内部DSMP和反向同步Server接口协议3.doc统一开通关闭server和Client协议.doc统一开通关闭Service概要设计说明书.doc2.3 术语和定义名词解释2.4 符号和缩略语缩写英文描述中文描述3 总体架构设计3.1 设计原则3.1.1 产品关联性设计 尽量保持各子模块的独立性 在与其他产品进行交互时仅提供必须的接口，以减少复杂度和错误发生的可能性。 在与其他产品交互的时候都通过一个中间进程进行，以降低产品之间的耦合性 内部DSMP系统内部子系统主要通过TMPP协议，开通关闭协议进行数据交互。 内部DSMP系统和外部系统（业务，客

6、服，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

7、编码 公共上行系统上线，割接所有地区，监控相关页面编码，功能测试，系统测试2005年4月2日2005年4月30日 统一开通关闭servcie测试 业务部门的反向同步serverice测试 手机开通关闭平台编码完成，测试 Provision修改，测试 手机开通渠道内部DSMP全流程测试。 统一割接控制API在内部DSMP系统各模块中使用。现网指定地区指定业务接入2005年5月1日2005年6月3日 现网指定地区，指定业务特殊手机测试，并对现网测试问题修改。 对BOSS数据和手机开通渠道的数据对比，做为割接基础。 对指定地区的业务进行现网割接。 完成割接参数提交文档，测试指导文档，割接文档。现网指

8、定地区指定业务接入2005年6月4日2005年6月30日 对指定地区的业务进行现网割接。 对外部地区的各种管理平台都进行覆盖。全面割接2005年7月2005年10月 进行对所有业务所有地区手机渠道全面割接 对于portal的开通方式的接入。3.3 系统需求3.3.1 系统软件需求 Slackware Linux Vss版本管理系统 Mysql 3.23.51 Apache 1.3.293.3.2 系统硬件需求上行系统： DL380G4 4 标配：CPU P4 3.06G2 内存：1G HPDDRRAM6 硬盘：100G开通关闭Service DL380G4 2 标配：CPU P4 3.06G2

9、 内存：1G HPDDRRAM2 硬盘：100G手机开通关闭平台华为特殊指令透传处理平台割接控制服务器 DL380G4 3 标配：CPU P4 3.06G2 内存：1G HPDDRRAM2 硬盘：100G3.3.3 系统功能需求 公司级开通/关闭Service：负责所有腾讯业务的开通/关闭，设置BOSS计费数据，并调用各个业务部门的接口反向同步数据到各个业务部门； 统一支付Portal：负责所有非移动终端的定购支付请求，并调用公司级开通/关闭Service进行业务的开通/关闭； 公共上行系统：并且对于非DSMP地区以及透传指令部分，由定购/取消处理模块调用公司级开通关闭Service，对于需要

10、二次确认的地区，此模块完成和用户的二次确认交互，将最终的定购信息传送给开通/关闭Service； Provsion服务系统：负责DSMP地区的开通/关闭操作，调用公司级开通/关闭Service；内部DSMP得以应用之后，所有的开通/关闭都接入到公司级开通/关闭Service系统。3.3.4 系统性能需求 DB方面：内部DSMP系统操作的数据库是目前运营支持部已有的BOSS数据库，性能和容量上都能够满足，这部分在本系统中不做考虑。 系统处理性能，开通关闭操作达到100条/秒，目前的统计来看，开通关闭业务的量在50条/秒左右。 单条处理性能，单笔开通关闭的操作的时间2s。3.4 系统总体架构3.4

11、.1 系统物理架构 内部DSMP涉及的系统很多，物理连接上如下图：3.4.2 系统逻辑架构内部DSMP逻辑分为三层： 数据接入层：具备的功能主要是接收各种方式的开通，关闭数据，并返回相应的处理结果。主要包括手机开通渠道的接入，例如：上行系统，Provison，华为特殊指令平台，手机处理平台。Portal的接入，Vnet等非手机渠道的接入。 数据处理层：具备功能主要是对开通，关闭请求进行具体处理。 用户数据层：保存用户的开通，关闭数据。4 关键技术分析4.1 业务模型分析4.1.1 目标用户涉及开通关闭操作的各种渠道，例如：手机上行，provision，vnet, Esales等。4.1.2 用

12、户入口 使用开通关闭API连接统一开通关闭Service。 直接使用开通关闭协议连接统一开通关闭service。4.1.3 收费策略4.1.4 产品依赖关系内部DSMP系统和很多的系统需要交互 上行系统，用户开通，关闭请求的提交。 Portal，多种渠道的开通的交互。 业务部分反向同步SERVER的交互。4.1.5 典型业务过程一：开通/关闭业务触发来源 Web 手机、小灵通 ESales 声讯 QQ客户端二：移动终端开通/关闭流程非DSMP地区：1) 网关将用户的指令发送到Relay，relay转发给上行系统；2) 公共上行系统解析出消息是开通/关闭指控，则将消息转发给上行定购处理系统； 3

13、) 上行定购处理系统调用开通/关闭Service的接口进行操作；4) 开通关闭Service调用各个业务部门的反向同步Server接口，进行反向同步，反向同步Server将消息分发到不同的业务Server；5) 各个业务Server进行业务参数的解码（字符串协议），进行业务相关特性设置，调用各自部门的数据中心开通/关闭Service；6) 反向同步返回成功，公司级开通/关闭Service在BOSS中设置定购关系、支付关系；DSMP地区：1) 网关将用户的指令发送到DSMP，DSMP调用腾讯Provision接口进行反向同步；2) Provision进行一定的解码，调用公司级开通关闭接口；3)

14、开通关闭Service调用各个业务部门的接口，进行反向同步，反向同步Server将消息分发到不同的业务Server；4) 各个业务Server进行业务参数的解码（字符串协议），进行业务相关特性设置，调用各自部门的数据中心开通/关闭Service；5) 反向同步返回成功，公司级开通/关闭Service在BOSS中设置定购关系、支付关系；三：业务承载号码是QQ号码的处理增值业务的承载号码都是QQ号码，当手机开通增值业务的时候：1) 开通指令未携带QQ号码 开通关闭Service收到开通指令后，调用业务接口反向同步，反向同步Server将消息分发到不同的业务Server； 业务Server发现没有Q

15、Q号码等业务附加信息，记录手机号码，发送下行消息提示用户输入QQ号码等附加信息； 业务Server返回调用成功，开通关闭Service会先设置手机支付关系； 用户回复QQ号码后，由于不带开通/关闭指令，上行系统会直接转发给业务Server； 业务Server对QQ号码等附加信息进行解码后，通过反向同步Server调用开通/关闭Service的设置承载号码接口补充QQ号码；2) 开通指令携带了QQ号码 开通关闭Service收到开通指令后，然后调用业务接口反向同步，反向同步Server将消息分发到不同的业务Server； 业务Server对业务附加信息进行解码，发现已经包含QQ号码，则调用开通/

16、关闭Service的设置承载号码接口补充QQ号码； 开通关闭Service根据手机号码、QQ号码完成业务的定购。备注：无线产品部的业务承载号码都是手机号码、小灵通号码，不需要以上处理。四：二次确认 内部DSMP部署之后，二次确认的流程由内部DSMP负责完成，对于运营商已经上了类似DSMP设备的地区，运营商会进行二次确认，腾讯内部DSMP不需要处理这些地区的二次确认。 此特性由上行系统中的 “定购/取消处理模块”完成，此模块需要进行的配置信息如下： 分运营商配置需要进行二次确认的地区信息； 分业务，配置不同业务的二次确认下发提示语； 分业务，配置不同业务的定购成功提示语； 分业务，配置不同业务，

17、用户需要回复信息的格式，以便用户回复二次确认信息时，上行系统进行信息格式有效性校验； 当用户回复二次确认信息时，需要分业务，配置不同业务的信息格式错误 提示语； 分业务，配置二次确认时用户回复的目的号码（即定购/取消处理模块发送下行消息时的主叫号码），上行系统需要将此目的号码带给定购/取消处理系统，定购/取消处理系统据此判断是用户回复的二次确认定购消息；流程如图所示：图6 二次确认备注：1) 对于联通在线，SPMS会将指令后面的内容去掉再传给上行系统，对于这种情况，业务Server应该下发提示消息要求用户补充业务信息，这样等于和用户进行了三次交互，用户感较差；2) 目前，有的业务为了避免3次交

18、互，提示用户回复二次确认的消息里不加指令，而是一个特殊标志，对于这种情况，需要进行修改，一率要求用户二次确认时必须添加指令。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： 接受

19、relayd的连接，把relay发过来的消息入预处理队列。msg_router：检测预处理队列(Preprocess queue)中是否有未处理消息，如果有消息，则根据消息路由表的配置分发到特定的应用队列(AppQueue)；如果没有消息，进程进入睡眠状态。msg_disp：检测自己负责的AppQueue是否有消息，如果有消息则转发到指定的应用端口；如果没有消息，进程进入睡眠状态。Admin：监控进程。Mo_recvd,msg_router,msg_disp会定期发送心跳包到控制内存区，admin通过共享内存命令区和配置区监控各个进程。同时admin也接收用户的指令，启动、停止、查看系统。Mo

20、_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端；对于其他

21、实体，Dispatch作为Server端；1) 各个模块说明： Client/API：API提供短连接的调用，需要开通/关闭业务的系统调用API和Dispatch模块交互，完成业务的开通/关闭，每完成一次开通关闭流程，API会连接、断开一次。对于需要长连接的系统，按照API和Dispatch之间的通讯协议进行交互即可； 消息分发模块Dispatch：收到API或客户端发出的开通/关闭请求后，根据号码将消息分发到对应的消息处理进程OCKerX进程，进行消息处理，同时将开通关闭类消息转发给业务部门的反向同步Server一份。 消息处理模块OCKer：此模块由可配置的多个Ker进程组成，每个Ker进

22、程平均处理不同号段的消息（按照号码后两位分）；2) 内部模块交互流程 外部系统调用API（或保持长连接）发送开通关闭请求到Dispatch； Dispatch根据号码分发到不同的OCKer进程处理，同时根据业务类型将消息转发一份给业务部门的反向同步Server，完成业务侧数据的设置； Dispatch以反向同步Server的处理结果为主，即反向同步Server处理完毕，Dispatch即返回响应给客户端，目的是保证对用户的响应时间不变。如果OCKer的处理结果和反向同步Server的处理不一致，则Dispatch发送告警，并记录日志，后台程序定时对异常日志进行处理；4.4 性能容量分析4.4.

23、1 上行子系统存储要求公式：每秒记录条数*每条日志大小*消息日志种类*3600*24计算结果：150条/秒 * 400B*3*3600秒*24 = 14.5G备注：在预处理系统中已经有所有的日志，所以日志只保存30天。带宽要求（内网）备注：150条/秒*400Betys*8Bit=0.5 Mbps带宽要求（外网）备注：不需要机器要求公式：最大存储空间 / 每台的最大存储空间计算结果：14.5G*30 / 100G = 4台G4备注：3台互为备份，1台为热备4.4.2 手机处理平台子系统存储要求公式：每秒记录条数*每条日志大小*消息日志种类*3600*24计算结果：30条/秒 * 400B*3*

24、3600秒*24 = 2.8G备注：日志只保存30天。带宽要求（内网）备注：30条/秒*400Betys*8Bit=0.1 Mbps带宽要求（外网）备注：不需要机器要求公式：最大存储空间 / 每台的最大存储空间计算结果：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.33 Mbps带宽要求（外网）备注

25、：不需要机器要求公式：最大存储空间 / 每台的最大存储空间计算结果：6.5*30 / 100G = 2台G4备注：2台机器，通过DNS做实时备份和负荷分担4.4.4 总计子系统名称机器用途存储要求带宽要求（内网）带宽要求（外网）机器要求上行子系统Server435G0.5 Mbps可以忽略不计4台G4手机处理平台子系统Server84G0.1 Mbps可以忽略不计2台G4开通关闭子系统Server195G0.33 Mbps可以忽略不计2台G4合计：714G0.93 Mbps8台G44.5 负载均衡分析4.5.1 负载均衡策略内部DSMP系统内部模块通过DNS寻址来进行实时的热备和负载均衡。4.

26、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 手机处理平台子系统