分享
嘉宾
第十六期技术夜校分享嘉宾——Leo
他有多年的互联网开发经验
是短信平台负责人
短信基本概念
企业短信
企业短信是专门为集团客户推出的具有用户信息管理、信息发送、资料查询等功能的信息类业务。
普通的文本短信主要分为以下3种类型：
验证码短信：仅支持单一验证码变量的文本短信。适用于APP/网站注册、安全登录、支付认证、身份认证、密码找回、账号绑定等应用场景。
通知短信：支持多语意变量的通知类短信。适用于订单通知、支付通知、物流通知、会议通知、政府通知、生活服务类通知、跨境订单通知、跨境物流通知等应用场景。
营销类型短信：带有促销性质，引导性质的营销类短信。适用于新品宣传、会员关怀、商品促销、活动邀请、跨境营销等应用场景。
企业短信发送流程
企业短信的发送流程主要分为以下几个步骤：
☑ 通过短信管理后台申请创建短信模板
☑ 运营商对短信模板内容进行审核报备
☑ 应用服务开始调用短信服务发送接口
☑ 短信平台接收短信请求后进行处理
☑ 短信平台调用短信渠道商发送短信
☑ 渠道商发送短信到指定号码的手机
☑ 用户接收到短信后把回执状态返回
短信平台
短信平台是对接手机运营商，集成了短信服务和短信管理后台的基本功能，提供短信接口实现对指定手机短信批量发送或自定义发送的目的。
短信服务（Short Message Service）是指通过调用短信发送API，将指定短信内容发送给指定手机用户。用户收到的短信来自106开头的号码，短信的内容多用于企业向用户传递验证码、系统通知、会员服务等信息。
短信平台建立后，能够集中化管理短信服务，提供系统可用性、易用性，降低系统接入的难度和维护成本。
短信平台架构
针对公司短信服务的历史遗留问题和痛点 ，短信服务平台化升级提供了以下5个解决方案。
SMS服务拆分方案
将原有的短信服务拆分成3个服务 ，分别是：
• sms-admin ：作为管理后台的主要服务，集成短信配置中心，任务调度中心，数据分析中心
• sms-interfaces : 作为短信服务的核心服务，提供短信发送，批量发送，数据回调，上行回复，数据查询等主要核心接口
• sms-api ：作为短信服务轻量级jar包，对外暴露接口使用
解决问题：
▶ 解决的短信服务单一问题 ，重构优化短信服务，提高短信服务整体性能
▶ 新架构对短信平台后期扩展提供的完整spi，并接入了监控报警提升系统稳定性
▶ 更细维度的统计分析短信发送数据及回调数据，数据统计准确性高达99.9%
SMS-ADMIN架构方案
短信后台设计架构方案，主要分为以下几个模块：
• 短信管理模块：主要对短信签名，短信渠道商，短信模板进行统一管理
• 系统管理模块：主要集成了SSO和权限管理，系统操作日志和系统大盘
• 数据统计模块：主要包含短信发送记录，短信数据分析报表和用户上行回复
• 流控配置模块：主要包含手机号黑白名单管理，模板流控配置和用户防疲劳
• 任务调度模块：主要包含数据同步任务，清洗任务，数据统计分析脚本和模板同步脚本
解决问题：
▶ 提供可视化管理界面，统一管理短信配置，提供短信后台的可用性和易用性
▶ 提供多维度的数据分析报表，提供完整的短信发送链路追踪功能，为业务方赋能
▶ 提供多维度频控配置功能，引入用户防疲劳机制，作为兜底策略提升系统稳定性
SMS-INTERFACES架构方案
短信服务在原有的基础上进行架构升级，整体服务框架使用fusion框架，使用consul作为注册中心（dubbo协议的RPC调用方式使用的是Nacos作为服务注册中心），使用Tidb作为数据持久化存储方式，使用redis作为数据缓存，使用rocketMQ作为消息队列对请求进行异步处理，通过权重择优算法进行渠道商权重匹配，从而提高整体服务的稳定性和性能表现。整体服务架构及调用流程如下图：
解决问题：
▶ 重构整体服务，优化处理逻辑，解决短信幂等问题，核心接口RT均值从26ms下降到13ms
▶ 提供更多的短信功能，包括支持普通文本短信，富文本短信，提供更多扩展的spi
▶ 支持更多的渠道商接入，对渠道商的价格，到达率的感知力度提升，有助于渠道权重择优匹配
▶ 支持用户上行回复，串联上下游系统的短信链路，为数据链路追踪和问题排查提供了新的方式
历史数据迁移方案
为了解决短信数据的历史问题 ，短信平台化对短信数据做了一次整体改造和迁移，包含：
存储变更：从原有的MongoDB变更为TiDB存储 ，考虑到原有Mongodb是非关系式数据存储，存储的数据列不统一，造成脏数据较多，而且无法进行事务处理，由于短信数据量较大，于是我们选择了天然分布式的TiDB进行数据存储。
数据库设计：在原有基础上，新增约20张表 ，主要对短信签名配置，渠道管理，流控管理，数据分析统计等进行完善。
数据合并：
对原有的sms_record,sms_send_log,sms_report三张短信发送数据表进行合并，通过不同的发送状态枚举值进行短信状态区分，并且对短信计费数进行合并处理，减少冗余数据量，提升数据统计性能和准确率。
数据清洗：选择性同步2020年后的所有短信发送数据，通过数据清洗脚本，对合并后的数据进行渠道，模板，短信内容，签名等数据列补全，修正对应数据的枚举值，状态和计费字段。
解决问题：
▶ 解决历史数据脏乱，历史数据无法归档，数据查询性能差等问题
▶ 解决历史数据统计困难，缺少数据分析，财务对账困难等数据问题
▶ 为后台管理配置，数据统计分析，数据发送报表，流控配置等提供数据基础
无损灰度发布方案
由于短信平台是完全从0到1的一套新系统，在上线发布的时候，要做到对上游业务完全无感知，并且数据完全无损。所以我们提出了这套无损灰度发布方案。具体流程如下图：
流程说明：
◆ 上游业务发起短信请求，在通过网关或服务注册发现后流量转发到原有的短信服务（duapp-sms-service），duapp-sms-service使用的数据存储是mongoDB，下游对接的渠道商的A/B , A/B渠道商进行发送短信后回调数据依然调用回duapp-sms-service的回调接口，保证老服务写入的数据始终在mongoDB。
◆ 新服务（sms-interfaces）使用的数据存储是TiDB，新服务下游对接的渠道商是A/B/C, 关闭A/B的渠道开关，保证新服务sms-interfaces下游只有一个C渠道在使用，并且C渠道的回调配置到新服务，从而保证到达新服务的流量始终写入TiDB。
◆ 在新服务上线后，将老服务的流量转发至新服务，此时流量到达新服务以后就会走C渠道发送，并保证新渠道的流量永远写入TiDB, 而老服务的历史回调数据依然写入mongoDB，保证数据不会交叉。
◆ 通过DataX对数据进行同步，将mongoDB的数据同步到TiDB临时表，使用数据清洗脚本对同步数据进行清洗后合并到新表，在所有历史数据都回写完毕后，修改A/B回调地址到新服务，并打开渠道开关，完成服务流量100%转发。
解决问题：
▶ 解决新服务上线上数据同步的问题，保证数据准确性
▶ 解决新服务上线后，上游业务无感知切换到新服务的需求，降低服务切换风险
结尾
短信服务平台化实践已经取得了阶段性的成果，但未来还需要不断优化。未来在在短信功能边界划分、短信成本持续优化、短信数据报表通知、短信服务容器化等方面，还需要持续改善。希望短信服务平台未来能成为公司平台级产品应用，提供更多场景的短信发送功能。
【得物技术】
扫一扫关注公众号
