背景
验证码、用户运营、拉新促活、活动营销等需要多手段消息触达到用户，并对触达效果进行分析多次触达。
现有问题：
1.市场上多个通道平台不统一，运营效率不高；
2.数据散落在不同系统中，很难站在全局角度管控用户接受的消息，用户体验差。
3.现有数据需要从系统内流出到其他平台，有数据泄露的风险。
通过建设一个可视化平台来对短信、微信、邮件、app推送等触达方式进行管理，这个平台主要管理内容的模版、管理消息的触达规则、记录发送记录。这个平台处于现在各个系统与外部短信等消息平台之间，各个系统与管理平台交互，然后由管理平台统一触发外部消息平台发送消息，以及进行数据交互。
收益
- 内容模板严格统一，内容随时修改
- 统一维护发送规则，管控用户消息接收的频率和体验
- 展现客户全生命周期消息记录
- 多通道组合数据分析，管控营销成本
术语
|
|
说明 |
|---|---|
| 业务系统 | 业务后台、场景、前置、CRM中之一，视自身情况而定 |
| 消息触达平台 | 目前要建设的平台 |
| 短信系统 | 营销平台组成-短信系统 |
| 短信平台 | 外部短信通道等（创蓝等） |
| 微信系统 | 暂无 |
| 微信平台 | 暂无 |
| 邮件系统 | 暂无 |
| 邮件平台 | 暂无 |
| 推送系统 | 暂无 |
| 推送平台 | 暂无 |
| 产品线 | 唯一productID的产品。目前有快审、贷款管家、贷款超市、蚂蚁有赚、核心服务等 |
| 业务事件 | 根据产品线定义业务触发事件 |
| 消息类型 | 通过发送者的目的来区分，有通知和营销两种。细分有验证码、业务通知、会员服务、营销四种 |
| 模板 |
触发发送消息（短信、微信、邮件等）的模板，具有唯一性，不同角色在编辑模板时，模板会存在如下状态：编辑中、启用、停用 模板会关联产品线和业务事件，调用方通过事件发送对应模板 |
| 模板版本 |
同一个模板被启用过之后，有可能已经被使用过了，如果变更了内容重新建新模板不便于统计分析，运营同学效率也不高 所以引入版本概念，相当于数据快照，每个发出的内容都可以回溯、分析 |
| 模板参数 | 模板内可以动态关联参数，调用方调用接口的时候传递动态内容替换 |
| 调用方 |
不同的系统不同的事件通过调用营销平台系统来触发短信，每个系统称为调用方。 目前有：快审、贷款管家、贷款超市、蚂蚁有赚、核心服务等 |
| 通道 | 消息推送所走的平台（短信通道、个推平台等） |
| 通道策略 | 对业务使用通道能力的管控和调配 |
| 用户策略 | 对用户接收消息的策略和管控 |
| 任务管理 | 对生成的推送任务调度、执行、跟踪、记录 |
| 数据统计监控 | 对消息推送结果的查询、汇总、分析 |
设计目标
平台服务性能
- 短信调用接口响应时间：<200ms
- 短信调用接口并发：≥100qps
- 后台管理服务响应时间：<2s
数据量预测（1年）
- 短信调用记录数：365*100000 ≈ 36500000
- 短信调用记录存储：365*100000*439字节 ≈ 15G（439字节基于数据库表结构得出，见数据库设计）
平台服务安全性
- 触发接口：密钥签名校验 + 产品线鉴权
平台服务稳定性
-
短信调用接口：接入方请求量进行流量控制（定期对调用方提供的预估峰值进行配置）
消息触达时效
- 延迟：依赖于运营商、平台商
组织分析
根据现有信贷业务调用公司短信服务现状，可以分析出使用短信系统组织角色如下
|
角色 |
职能 |
|---|---|
|
业务人员
|
系统的接入方及使用者
|
|
法务人员（预留）
|
模板文案审核方（预留）
|
|
系统管理员
|
系统的维护方
|
业务分析
无论是短信、邮件、微信、还是app推送等，这类消息触达业务做得共性的事情都是：
- 由谁
- 把那个内容
- 用哪种媒介
- 用哪种业务策略
- 发送给谁
- 发送后的结果怎么样
媒介不同，数据处理有一定的差异性。底层通道接入方式和推送能力有一定差异，上层的流程管控不受影响。
需求分析
顶层数据流图
依赖的外部系统如下:
|
系统 |
服务 |
|---|---|
| 第三方短信服务平台 |
|
| 邮件服务器 | 收发邮件 |
| 第三方app推送平台 |
app消息推送 |
| ... | 其他 |
0层数据流图
整个系统可以包括：产品管理、事件管理、调用管理、通道管理、参数管理、模板管理、用户策略管理、通道策略管理、任务管理、数据统计、系统监控等11个更细的数据加工处理
1层数据流图
进一步细化数据流处理，识别出数据流的输入、输出及数据加工如下
数据加工举例
- 输入：模板信息（模板名称，模板ID，短信类型，调用方，...）
- 输出：存储至模板表及模板版本表
- 逻辑：将模板信息存储至模板表，模板启用时更新模板版本表（最新版本更新为启用状态，上一版本更新为停用）
其他数据加工：暂略.
总体设计
设计的重点主要有
- 保证平台对外服务的高可用性、安全性以及稳定性
- 宽表数据打通
- 任务调度
- 通道容错
- 灵活的策略配置
- 平台服务的扩容方案
- 平台管理的易用性
总体功能结构
我们通过系统合理的功能划分来实现系统的易用性.
依据顶层及0层数据流图，整体系统可以划分如下：
系统物理构成
|
项目
|
部署机器
|
是否新购
|
机器配置
|
|---|---|---|---|
| 消息推送 | ali-hb2-sms01 | 是 | 4核16G |
| 管理后台 | ali-hb2-liebao228 | 否 |
|
| mysql | ali-hb2-rds01 | 否 |
|
| redis | ali-hb2-sms01 | 与消息推送同一机器 |
|
平台服务部署方案
消息推送业务的请求峰值和请求量是非常高的，同时随着业务营销活动，存在峰值波动非常陡的情况，为了不影响其他服务将其独立部署。
后台部署在228。
新购一台4核16G机器部署服务，优化qps得出理想的处理能力。
mysql用现有的阿里云rds,如果读写影响线上业务则单独部署。
由于验证码服务是阻塞用户流程的，延时要求非常高的服务所以优先处理队列，资源允许的情况下单独部署验证服务。
扩容与容错
触达系统在对外提供服务时，主要的瓶颈在平台服务集群的并发能力以及第三方平台通道的并发能力.
平台服务
- 对请求qps、请求时长、HTTP状态码进行监控，根据具体情况进行相应扩容.
单个实例<50qps是线下压测理论值，实际qps要根据调用接口线上实际运行情况进行评估得到经验值，前期可以根据理论值给出保守值，然后评估所需实例数，后期根据经验值进行扩容评估.
第三方平台
- 提供的通道的qps是有上限的，需要对触达服务的请求进行日志的记录，当超过通道的阀值（≥理论值*80%）则进行提前预警，然后跟进原因排查，评估是否需要扩容
- 提供的第三方平台服务的请求时长可能会存在超时，需要对请求时长进行日志记录，当单位时间内超时的请求数量超过阀值（≥10qps）则进行提前预警，然后跟进原因排查，评估是否需要更换平台
- 提供的通道是HTTP服务，需要对非200的错误码进行监控，同时程序中要进行容错，进行适当的重试或更换通道
数据库设计
主要实体属性描述
|
实体 |
属性/数据源 |
|---|---|
| 产品线 |
|
| 调用方 |
|
| 模板参数 |
|
| 模板 |
|
| 模板版本 |
|
| 调用记录 |
|
| 短信通道 |
|
数据库表设计
详细设计
以下主要说明总体设计中的一些关键设计
模板设置流程详细设计
todo
平台服务降级详细设计
todo
发送消息详细设计
todo
消息状态回调详细设计
todo
统计报表与个人查询详细设计
todo
消息批量发送任务详细设计
todo
统计监控详细设计
todo
通道配置详细设计
todo
敏感词模块详细设计
todo
