又来水文了...
但感觉没什么其他内容可写,就将之前做的一个消息平台稍微做点总结.
简单说说短信模块的实现,做的东西不复杂,权当总结了~.
需求
功能需求
功能需求比较直接.
需要提供一些短信和统计功能即可:
- 通知短信
- 验证码短信
- 语音短信
- 发送量统计
非功能需求
主要是以下几点
- 稳定的发送保证:
分为两部分,一个是服务本身的稳定性,另一个是短信服务提供商的稳定性.
服务本身稳定是自己需要实现的,可以通过微服务平台已经有的一些工具保证,这里不进行展开.而另一个是需要外部保证的,外部需要保证的东西永远是脆弱的,所以不能仅仅使用一家服务商,需要使用多家. - 方便扩展:
接着第一点,服务商可能会有更换的需求,需要保证能够方便接入下架服务商. - 资产保护:
短信相比邮件,微信通知等的一个不同是他花费比较高,一条的计价在3分左右,较长的短信会被拆为多条,如果不加限制进行保护很容易造成大量的资损.
技术选型
有了上面的需求之后就是选用什么技术了.
基础的web服务就使用公司现有的即可.
对于存储,因为涉及到发送信息和报告的记录,量可能会很大(其实上线之后也还好,3个月不到千万记录),统计时可能会按照某些发送内容统计,使用MySQL之类的可能会不太靠谱,选择使用ES.
对于安全,一定需要做手机号每日发送量和发送频率等的限制,这个用redis可以较为轻松解决.
最后一个简化版的架构图如下:
实现细节
上面都是这个服务战略上的一些东西,这里说一些战术上的.
接入多家服务商
需要有多家服务商的接入,一家服务商可能同时供应多个短信功能.
同时同一个短信功能需要轮流调用所有提供的服务商,并在一家失败后进行重试.
也需要支持灵活的配置,可以禁用掉一些服务商,也可以方便加入新的.
在实现上先定义了各个发送功能接口,例如:
interface NotiSmsSender {
SmsSubmitResult sendNoti(NotiRequest request);
}
interface VerifyCodeSmsSender {
SmsSubmitResult sendVerifyCode(VerifyCodeRequest request);
}
对应的服务商实现不同的接口,提供不同的服务,每个对应的实现都有一个id字段,用于之后的配置.
现在有了一坨sender,接下来要定义router,用来进行请求的分发.
router内含有sender列表,配置router内的sender就可以实现服务商的下线功能了.
大致流程如下:
实际实现中使用了Akka,各个sender是一个actor,router负责监督各个sender的健康情况,此外天然获得了超时时间的能力(底层使用了异步HttpClient,actor内部不会发生阻塞).
发送限制设置
关于手机号和ip的发送数量计数使用reids的incr配合时间戳相关的key就可以很简单完成,这里不累述这个.
发送限制的话首先要针对不同功能,因为不同功能的使用量是截然不同的,并且也有隔离的作用,一个功能超限不能影响其他功能.
其次,发送的限制需要分层级,当达到了全局最大限制后,就算没有超过单手机限制也不应该发出去了.
使用的层次是:
功能全局次数(次数) -> 单接入应用限制(次数/白名单/开关) -> 单手机/ip限制(次数/白名单/开关) -> 风控服务(开关)
最后次数要根据统计情况和业务更改做适当调整.
性能
这个服务很明显是IO密集的,就没什么计算,主要是调用各种外部服务,等IO返回.
所以对于这些各个用来做请求的线程池就可以配置稍微大一点,实际最主要的就是HTTP的连接池.但连接超时,读取超时也不适合设置过大.
实际测试也没多大问题,平日一天短信请求量也在几w左右,并没有太大的瓶颈.
其他的一些点和普通的web服务也大同小异了,没有什么特别的技巧.
其实之前一些文章也是在构建这个服务的时候写的,这段时间没写什么就当划水了,比如:
Akka实践一些总结
ES踩坑笔记
这个服务构建的时候根据需要用了些之前没有使用的组件,也算额外获得了一些回报吧~