短信平台就该这么设计，稳的一批！

花了三个月的时间，我手写了个迷你版的短信平台服务platform-sms，今天开源出来 Beta 版本。

写这个开源项目的初心其实很简单："帮助初中级研发工程师入门架构设计，提升他们的技术认知"。

2018年，作为架构师，我参与一个短信平台的重构。发送短信的场景包括还款业务、CRM、促销业务等。

不同的技术团队都是使用客户端模式发送短信，但并不统一，大概分为四种 ：

• 使用阿里云提供的短信 SDK 发送短信 。

• 根据亿美提供的样例直接发送短信 。

• 使用绿城提供的短信 SDK 发送短信。

• 架构团队短信 SDK ，类似于 SMS4J的设计方式，支持亿美、绿城短信发送 。

客户端的模式在多团队协作场景中，缺点还是很明显：

• 维护成本

  假如运营不再使用某一个短信渠道，那么很多团队将会收到影响，不得不配合重新修改配置，重新上线，耗费的时间成本很高。

• 无法支持高级功能

  客户端实现某些功能比较麻烦，比如：客户端因为偶发情况（网络原因）通过三方渠道发送短信超时，此时需要将短信发送到备份渠道，从而确保短信发送的成功率。

因此，多团队协作的场景中，短信服务的模式应该是服务端模式。

 

我参考了腾讯云的短信服务的设计思路 ：

1. 模仿腾讯云的 SDK 设计，提供简单易用的发送短信方法 （单发，群发，营销单发，营销群发，模板单发，模板群发） ；

2. 设计短信服务 API 端，接收发短信请求，发送短信信息到消息队列；

3. worker 服务消费消息，按照负载均衡的算法，调用不同渠道商的短信接口；

4. 控制台可以查看短信发送记录，配置渠道商信息、模版信息等。

短信平台研发完成之后，满足了当时的业务需求，因为短信的管理也归于统一，提升了业务接入短信服务的效率，所以各个技术团队也比较认可。

随着经验的累积，我见过了不少公司的短信服务，核心问题不外乎两点：

1. 短信服务与业务服务边界问题。

   为了满足业务服务需求