课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
随着互联网的不断发展,用户之间进行信息传递的方法和渠道也是越来越多了,而今天我们就一起来了解一下,关于短信通信服务的构建都有哪些主要组成部分。
非功能需求
主要是以下几点
稳定的发送保证:
分为两部分,一个是服务本身的稳定性,另一个是短信服务提供商的稳定性.
服务本身稳定是自己需要实现的,可以通过微服务平台已经有的一些工具保证,这里不进行展开.而另一个是需要外部保证的,外部需要保证的东西永远是脆弱的,所以不能仅仅使用一家服务商,需要使用多家.
方便扩展:
接着一点,服务商可能会有更换的需求,需要保证能够方便接入下架服务商.
资产保护:
短信相比邮件,微信通知等的一个不同是他花费比较高,一条的计价在3分左右,较长的短信会被拆为多条,如果不加限制进行保护很容易造成大量的资损.
技术选型
有了上面的需求之后就是选用什么技术了.
基础的web服务就使用公司现有的即可.
对于存储,因为涉及到发送信息和报告的记录,量可能会很大(其实上线之后也还好,3个月不到千万记录),统计时可能会按照某些发送内容统计,使用MySQL之类的可能会不太靠谱,选择使用ES.
对于安全,一定需要做手机号每日发送量和发送频率等的限制,这个用redis可以较为轻松解决.
接入多家服务商
需要有多家服务商的接入,一家服务商可能同时供应多个短信功能.
同时同一个短信功能需要轮流调用所有提供的服务商,并在一家失败后进行重试.
也需要支持灵活的配置,可以禁用掉一些服务商,也可以方便加入新的。
发送限制设置
关于手机号和ip的发送数量计数使用reids的incr配合时间戳相关的key就可以很简单完成,这里不累述这个.
发送限制的话先要针对不同功能,因为不同功能的使用量是截然不同的,并且也有隔离的作用,一个功能超限不能影响其他功能.
其次,发送的限制需要分层级,当达到了全局大限制后,就算没有超过单手机限制也不应该发出去了.
使用的层次是:
功能全局次数(次数)->单接入应用限制(次数/白名单/开关)->单手机/ip限制(次数/白名单/开关)->风控服务(开关)
后次数要根据统计情况和业务更改做适当调整.
性能
这个服务很明显是IO密集的,就没什么计算,主要是调用各种外部服务,等IO返回.
所以对于这些各个用来做请求的线程池就可以配置稍微大一点,实际主要的就是HTTP的连接池.但连接超时,读取超时也不适合设置过大.
实际测试也没多大问题,平日一天短信请求量也在几w左右,并没有太大的瓶颈.
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。