前言

文本已收录至我的GitHub仓库，欢迎Star：github.com/bin39232820…

种一棵树最好的时间是十年前，其次是现在

Tips

开源项目推荐系列是，小六六平时不是会逛逛开源平台嘛！然后就想着把一些项目分享给到大家，给大家说说我对这个开源项目的一些看法，当然，在写的过程中，也可以让自己的知识面更广，希望能给大家带来不一样的东西。

短信网关

为啥要用短信网关

随着企业业务扩张、应用成倍的增加、短信规模化使用，传统短信平台的接入方式和单一的信息发送功能，已经不能完全满足现代企业管理的需求，所以统一入口、减少对接成本、同时兼顾多种短信业务、简单易行的操作与维护、高稳定、高可靠的移动信息化应用成为短信平台发展趋势。

• 服务越来越多，每个服务都有可能发送短信，是否每个服务都需要对接一遍？
• 多应用对接短信，如何做到短信发送服务高效、稳定？
• 短信通道出现异常时，如何快速切换通道？
• 切换通道时，如何做到应用服务无感知？
• 如何统计各服务短信发送情况，以便进行后续营销分析？

本项目（集信达短信平台）的核心在于保证短信高效、准确的送达、简单易操作的对接方式。通过对服务的解耦、通讯方式的升级来提升系统的吞吐量。同时在多通道的加持下，通过智能动态的通道评级、选举、降级、热插拔，增强了系统的健壮性，摆脱对单一通道的依赖。并且提供多种对接方式，满足企业内部的各种需求。

平台架构

集信达短信平台的整体架构如下：

主要有以下几个服务

• pd-sms-api 给业务用
• pd-sms-manage 后台管理
• pd-sms-server 真正发送短信

业务架构

通过上面的业务架构可以看到，短信接收服务（pd-sms-api）提供3种方式供业务系统调用：

• HTTP接口
• TCP
• SDK形式

短信接收服务通过资质验证（可开关）、短信内容校验后将短信信息发送到对应中间件中（Redis、MySQL）。

短信发送方式分为两种类型：

• 定时发送短信：将短信内容存储到MySQL数据库中，由短信发送服务通过定时任务获取并发送
• 普通短信：将短信内容推送到Redis队列中，由短信发送服务异步接收并发送

项目结构

集信达短信平台，项目整体工程结构和模块功能如下：

pd-sms-backend           # 集信达 短信平台父工程
   ├── pd-sms-entity      # 短信平台实体
   ├── pd-sms-manage      # 系统管理服务
   ├── pa-sms-api        # 短信接收服务，应用系统调用接口、发送短信
   ├── pd-sms-server      # 短信发送服务，调用短信通道、发送短信
   └── pd-sms-sdk        # 短信SDK，应用系统引入、发送短信

集信达短信服务有三个：后台管理服务，短信接收服务，短信发送服务：

业务方调用处理流程

调用方式：

• 业务统调用短信接收服务提供的接口，由短信接收服务将信息保存到消息缓冲区（Mysql、Redis）
• 调用方式：HTTP、TCP(Netty)、SDK

处理流程：

短信接收服务接收到应用系统请求后，会进行相关的校验处理，校验通过则将信息保存到消息缓存区，具体处理流程如下：

短信发送服务的发送过程

相关功能：

• 和具体的短信通道对接（例如：阿里云短信、梦网短信等），发送短信
• 短信定时发送
• 短信实时发送
• 服务注册，保证短信发送服务高可用
• 通道自动选举、降级

处理过程：

项目亮点

架构的设计

架构的设计和耦合性还是很好的，代码的风格也很优雅，代码通俗易懂，我随机截取一个类给大家看看

短信发送服务核心类

• ServerRegister：服务注册器，用于将短信发送服务注册到Redis中，定时服务上报，定时服务检查
• ConfigServiceImpl：通道配置器，用于查询可用通道（阿里短信、华为短信等），通道选举、降级
• AbstractSmsService：短信发送器抽象父类，子类需要和具体的短信通道对接来完成发送短信的工作
• SmsConnectLoader：通道实例加载器，根据通道配置，初始化每个通道的Bean对象
• SmsFactory：短信发送工厂，获取具体的通道实例Bean对象（例如AliyunSmsService）来发送短信， 如果发送出现异常，触发通道选举和通道降级策略
• SendTimingSmsImpl：定时短信业务处理器，具体负责定时短信的发送
• SendSmsJob：短信发送定时任务，用于定时短信的发送，调用SendTimingSmsImpl发送定时短信
• GeneralSmsListener、HighSmsListener：短信接收器，Redis队列的消费者，监听队列中的消息，如果有消息则调用SmsFactory发送实时短信
• HighServerReceiver：通道消息监听器，通过Redis的发布订阅模式监听通道相关消息，调用SmsConnectLoader初始化通道和更新通道
• SubscriberConfig：订阅发布模式的容器配置，创建消息监听容器，并将HighServerReceiver加入容器中

服务注册器

大家知道这个是干嘛的吧？哈哈往下看，保证让你觉得有点东西

其实这块的概念和我们服务的注册于发现其实差不多的，但是作用确是不同，为啥这里我们要服务注册呢？原因如下

短信发送服务支持分布式集群部署，可以是多个实例，实例越多，发送短信的能力越强。但是对于通道选举、持久化通道等操作，只能有一个服务实例执行，其他服务实例通过redis的广播机制获得通道变化。

如果要实现这一功能，需要将所有短信发送服务实例注册到某个地方，当前实现是将所有服务实例注册到Redis中。并且为了能够监控每个服务实例运行状态，需要每个服务实例定时上报并且定时进行服务检查。

业务逻辑

• 服务注册，项目启动时将当前服务实例id注册到redis
• 服务上报，每三分钟报告一次，并传入当前时间戳
• 服务检查，每十分钟检查一次服务列表，清空超过五分钟没有报告的服务

通道实例加载器

通道实例加载器对应的为SmsConnectLoader类。

短信发送服务存在多个通道（例如阿里云短信、梦网短信等），这些通道是通过后台管理系统设置的，包括通道的名称、签名、模板、连接方式等信息。当短信发送服务启动时，或者后台管理系统设置通道时，将会初始化短信通道。

通道实例加载器的作用就是根据通道配置，初始化每个通道的Bean对象（例如AliyunSmsService、MengWangSmsService等）。

真正发送流程

/**
 * 短信发送工厂
     1. 获取构建好的短信通道
     2. 调用通道方法，发送短信
     3. 如果发送出现异常，触发通道选举和通道降级策略
     4. 当通道选举被触发时：smsConnectLoader.buildNewConnect()
     5. 当通道降级被触发时：smsConnectLoader.changeNewConnectMessage()
     6. 记录短信发送日志
 */

采用do while的模式，直到遍历所有的通道把短信成功发送

异步通道降级选举

再真正下发短信的流程中

在一次真正向第三方发送短信的时候，如果发送失败，就会走进到这个重新排序通道逻辑，判断是否需要重排序

在这逻辑中有2个很关键的点

• 固定阈值 (具体数值)
• 固定因子 (按比例)

里面呢？有2个核心逻辑

• 降级
• 选举

异步通道选举流程

通道选择，只能再一台通道中选举，所以用分布式锁。

listForNewConnect 选择策略

* 通道选举，选举策略：
* 1、剔除掉第一级通道
* 2、查询最近一小时内通道发送短信数量，按数量排序通道
* 3、如果最近一小时没有发送短信，按最后发送成功排序

具体的逻辑还是有点东西的，哈哈。大家自己去看源码吧

结束

我觉得，这个项目的设计，技术，架构都是非常不错的，而且又全是crud,对于个人的帮助还是很不错的，如果有时间大家花点时间去吃透它，对于之后的架构设计，面试等都有很大的帮助，并且这个项目很小，代码量也少，花的时间也不多，我是非常推进的拉。好了，就到这了 我是小六六 三天打鱼，两天晒网。