Github : github.com/makemyownli...

短信服务 platform-sms 0.5.0 发布，新的版本做了非常多的优化和改进。

1、支持发送任意时间延时短信；

2、优化三方渠道适配器加载逻辑；

3、支持 Docker 部署。

4、优化线程模型。

写这个项目的初心很简单：做一个简单易用 的教学型项目，帮助工程师快速提升技术认知。

这篇文章，我们聊聊短信服务中那些有趣的设计模式，希望对大家有所启发。

1 适配器模式

笔者曾经在科大讯飞教育部门，维护过一款短信服务，过程是相当痛苦。因为业务代码和渠道发送短信代码耦合度太高，为了将短信渠道从阿里云迁移到亿美短信，花费了大量的时间和精力。

所以，笔者在设计 platform-sms 时，考虑到两点：逻辑独立 和资源隔离。

逻辑独立：独立的模块内编写各自的发送短信的逻辑，彼此之间互不影响。
资源隔离：通过类加载器加载需要的类，不会有包冲突等问题。

因此，笔者参考了开源项目 canal adapter 的设计方式。

部署目录来看，短信平台将三方渠道的相关逻辑独立在单独的文件夹 plugin 中。

服务端启动后，需要将插件加载到服务端容器中，加载完成之后，服务端可以根据渠道编号获取适配器（aliyun、tencent、emay）对象进行发送短信，申请短信模版等操作。

下图是适配器核心模块。

模块定义了 OuterAdapter 接口，一个完成的适配器需要实现如下的接口：

在阿里云、腾讯云各自的模块内实现 OuterAdapter 接口，并配置好接口限定名文件。

觉得神奇吧，这就是适配器模式的优雅！

2 线程模型

对于一个合理的系统来讲，一定要配置合理的线程模型 , 不同的线程用于不同的场景。

发送一条即时短信需要两种线程协同处理，tomcat 线程负责创建短信记录，即时短信处理线程池负责发送短信。

假如即时短信处理线程池在发送短信时断电，重试线程可以起到部分容错的功能。

3 延时消息

延时消息是非常有趣的功能，最新的版本支持任意时间的延时短信。

springboot controller 接收到发送短信请求后，通过「发送短信处理器」将请求存储到记录表。

Redis 有容量限制，我们不必将所有的数据存储在 Redis 里。处理延迟消息时，我们将短信数据做了冷热划分。

热数据：延时短信并不需要马上发送，而是延时单线程从延时队列中获取元素，获取到元素已经到了发送时间点了，则调用分发器发送短信。延时短信处理线程池会异步（相对延时服务单线程来讲）的执行发送短信。

冷数据：定时任务加载下个自然小时的短信记录，load 到 Redis 延时队列里。

4 缓存实用技巧

1、本地缓存 + Redis PubSub 缓存同步

当客户端调用发送短信请求时，每次都需要鉴权，为了提升系统性能，应用信息都是从本地缓存中获取，然后判断客户端的请求是否合法。

应用信息 就是存储在 ConcurrentHashMap 中，通过定时任务刷新缓存 。

为了保存缓存与数据库同步，我们采用 Pub/Sub 的方案。

下图，当我们启动两个短信平台应用，在短信平台 web 控制台修改应用信息时，我们发现两个应用的本地内存都发生变化了。

2、模板页面列表缓存教学

为了帮助大家学习列表缓存的技巧，笔者特意在模板页面做了教学演示。

我们使用列表缓存方案：查询对象ID列表，只缓存每个对象条目。

SmsTemplateService 接口定义一个新的查询模板列表的方法 queryTemplates2。

上图展示了模板条目缓存结果，性能相比直接从数据库查询得到显著的提升，平均性能提升 5 倍。

5 多种部署方式

短信平台可以支持多种部署方式：前后端分离 、前后端合并 、Docker 。

项目中我们通过使用 maven 多种插件技巧，同时依赖 springboot 的特性，实现生成前后端合并包，并提供了 windows、linux 一键启动 / 停止脚本等。

为了便于大家学习如何制作 Docker 镜像，笔者贴心的将 Docker 打包命令、以及启动容器的命令注释写到 Dockerfile 文件。

下图是我们启动短信服务 Docerk 容器的效果，非常简单。

6 未来规划

短信服务 platform-sms 代码中还有非常多的技巧，比如：

优雅的创建单线程、多线程
参考 RocketMQ 的通讯模块，实现了适配器的分发器
Redis 实现分布式锁
定制 SDK 与服务端通讯协议

笔者也会继续优化 platform-sms ，规划列表：

控制台实现批量发送短信
更加灵活易用的绑定模板
限流配置（接口、应用、手机多个维度）