短信服务 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 ，规划列表：
- 控制台实现批量发送短信
- 更加灵活易用的绑定模板
- 限流配置（接口、应用、手机多个维度）