1、统一短信平台概要设计说明书2012 年 2 月目录1. 引言 .31.1 编写目的 .31.2 项目风险 .32. 设计概述 32.1 限制和约束 .32.2 设计原则和设计要求 .33. 系统逻辑设计 43.1 系统结构设计 .43.1.1 通道层 53.1.2 通道管理层 53.1.3 平台运营管理层 53.1.1 接口层 53.2 使用技术说明 .54. 数据库设计 64.1 数据库接口 .64.2 短彩信数据流 .64.3 短信、彩信归档的设计 .74.4 计费统计设计 .75. 网络方案设计 71. 引言本文档说明了短信平台的设计理念、软件架构。1.1 编写目的1.2 项目风险2.
2、设计概述本节描述现有开发条件和需要实现的目标，说明进行概要设计时应该遵循的设计原则和必须采用的设计方法。2.1 限制和约束 技术条件：系统使用数据库作为数据缓冲池，并大量使用队列。 开发环境：Linux 系统、Java、Oracle开发及系统运行初期需要服务器一台 DELL R710 配置（ 2u，12G 内存）价格 2 万元左右，在业务量增大时考虑系统扩容，系统扩容时现有程序不需要变动只需要迁移数据及系统部署。 时间限制：项目在 2 个月内完成，绝对不超过 3 个月。其中系统开发为 1 个月，半个月功能测试及调整，半个月系统性能优化；即可上线试运行。2.2 设计原则和设计要求短信平台运行于
3、Linux 操作系统，使用 Java 开发，数据库为 Oracle。平台使用 SSH 架构。设计中遵循了如下原则 分层设计，将平台分为 3 层a) 通道层：该层负责对通道进行管理、为整个系统的服务层，负责短信、彩信的发送、接收，保证系统可以高效、及时、准确的处理短彩信b) 业务逻辑层：本层为业务层，用于实现各种业务需求，对通道层进行控制、向通道层提供数据。c) 接口层：外部系统通过本层提供的接口与短信平台进行交互 模块独立原则在实现模块的时候，应保证模块的独立性，尽量使模块在物理上、逻辑上是独立的 面向接口编程原则为减少模块间的依赖，需采用面向接口的编程方法，减少模块之间的耦合 数据库设计原则
4、以数据库为中心，短信平台中的数据交换以数据库为交换媒介，辅助的交换方式为SOCKET。需要建立的模型必须建立，避免复用数据模型引起混乱 效率优先原则，要保证效率可以达标。 易操作性原则 ： 系统应方便用户使用。 安全性和保密原则：接口层部分要考虑安全性和保密，Web 界面的操作也要考虑此问题。 易维护性要求：系统管理员可以在 Web 界面完成全部维护的操作，尽量避免进入到操作系统进行维护。3. 系统逻辑设计3.1 系统结构设计平台按照通道层、多通道管理层、平台运营管理层、接口层，四个层次进行设计，如下图所示。其中接口层、平台运营管理层、多通道管理层在同一个 Web 服务器内。3.1.1 通道层
5、通道层由多个通道实例构成，每个通道是一个进程，接受通道管理层的管理，并定期向通道管理层报告通道状态。3.1.2 通道管理层通道管理层部署于 Web 服务器内，管理员可以通过 Web 界面对通道进行维护。3.1.3 平台运营管理层本层为短信平台的业务逻辑层，管理员和普通用户通过 Web 界面与系统进行交互3.1.1 接口层接口层为业务系统提供服务，目前有数据库接口、HTTP 接口、WebService 接口、SOCKET 接口。3.2 使用技术说明 规则引擎为实现短彩信规则的灵活配置、高效为短信选择通道，使用 Drools 规则引擎 Spring：简化系统配置、为系统解耦。 Hibernate：
6、数据持久层工具4. 数据库设计4.1 数据库接口为简化外部系统接入短信的步骤，短信平台提供数据库接口发送短信接口表上行短信接口表4.2 短彩信数据流本节说明整个系统中短彩信数据流。说明： 短信平台的业务逻辑包括运营商识别、违禁词过滤、黑名单过滤、优先级处理、通道规则、短信分页等，经过此过程，短信平台将短信发送请求处理成为统一的格式插入到 SEND 表。 短信引擎发送的短信依靠到 SEND 表榨取来取得。 彩信的流程与短信类似，但是为了减少彩信所占空间，专门设计了一个发送内容表，保存彩信内容相同彩信的内容。彩信内容以 XML 保存。4.3 短信、彩信归档的设计已发短信、彩信会在发送表（SEND、MMS_SEND）表中保存，系统于次日凌晨将发送失败、已返回状态报告的短信转移至发送历史表，发送历史表每日创建一个。发送统计依赖于发送历史表。4.4 计费统计设计计费统计以统计归档表中发送短信数据为基本依据，考虑到短信发送数量巨大，为提高统计效率，对数据使用重组策略，系统将定期对两天之前的发送数据做统计，将统计数据保存，部分统计数据将以这些数据作为统计依据。考虑到有可能调整数据，系统提供重新统计功能，重新对发送数据做统计。5. 网络方案设计平台网络拓扑图
