聊聊如何在Java應用中發送短信
很多業務場景里，我們都需要發送短信，比如登陸驗證碼、告警、營銷通知、節日祝福等等。
這篇文章，我們聊聊 Java 應用中如何優雅的發送短信。
圖片
一客戶端/服務端兩種模式
Java 應用中發送短信通常需要使用短信服務提供商提供的短信 API 。
我們經常使用的短信渠道有：阿里云、騰訊云、華為云、億美等。
發送短信模式分為兩種：
1、客戶端模式
客戶端模式是指應用系統直接調用短信服務提供商提供的短信 API 發送短信。
圖片
2、服務端模式
服務端模式是獨立創建一個短信平臺服務，應用系統直接使用短信平臺服務提供的 SDK 發送短信。
圖片
核心流程如下：
- 前端調用應用服務接口發送短信 ;
- 應用服務收到短信請求后，調用 SDK 方法根據模版發送短信；
- 短信平臺服務收到請求，根據路由算法選擇配置的渠道（比如阿里云、騰訊云）發送短信；
- 短信成功發送到用戶手機 。
二客戶端模式
1、使用三方短信渠道 SDK
客戶端模式是非常簡單的模式，很多短信服務提供商會提供成熟的 SDK ，業務系統只需要添加 SDK 依賴以及相關配置，就可以調用 SDK 提供的方法發送短信。
我們以阿里云短信服務為例， 調用 API 發送短信的全流程如下所示：
圖片
使用 SDK 示例如下：
圖片
國內云廠商阿里云、騰訊云、華為云的短信服務，都需要依次申請簽名，申請模版，審核通過之后才能發送短信。
2、封裝多個三方渠道接口
雖然使用三方短信渠道 SDK 非常簡單，但是在實際項目中，可能會存在多個三方渠道，也就是說：可能有的短信是通過騰訊云發送，有的是通過阿里云發送。這樣就需要在工程中配置不同渠道的 SDK 依賴。
但這種方式會有兩個明顯的問題 ：
- 不同渠道的發送短信代碼不一致，業務代碼偏混亂。
- 工程中引入到 SDK 包比較多，不同的 SDK 依賴并不相同，可能存在沖突問題 。
為了解決這個問題，有一種方法是擯棄三方渠道 SDK ，自己實現 SDK 的發送短信方法，這樣可以統一發送短信代碼，易于管理。
筆者發現一個開源項目 SMS4J，該項目為短信聚合框架，旨在集成多家短信服務，解決接入多個短信 SDK 的繁瑣流程。
下面我們展示在 SpringBoot 環境如何集成。
- maven 引入
<dependency>
<groupId>org.dromara.sms4j</groupId>
<artifactId>sms4j-spring-boot-starter</artifactId>
<version>3.0.2</version>
</dependency>- 設置配置文件
sms:
alibaba:
#阿里云的accessKey
accessKeyId: 您的accessKey
#阿里云的accessKeySecret
accessKeySecret: 您的accessKeySecret
#短信簽名
signature: 測試簽名
#模板ID 用于發送固定模板短信使用
templateId: SMS_215125134
#模板變量 上述模板的變量
templateName: code
#請求地址 默認為dysmsapi.aliyuncs.com 如無特殊改變可以不用設置
requestUrl: dysmsapi.aliyuncs.com
huawei:
#華為短信appKey
appKey: 5N6fvXXXX920HaWhVXXXXXX7fYa
#華為短信appSecret
app-secret: Wujt7EYzZTBXXXXXXEhSP6XXXX
#短信簽名
signature: 華為短信測試
#通道號
sender: 8823040504797
#模板ID 如果使用自定義模板發送方法可不設定
template-id: acXXXXXXXXc274b2a8263479b954c1ab5
#華為回調地址，如不需要可不設置或為空
statusCallBack:
#華為分配的app請求地址
url: https://XXXXX.cn-north-4.XXXXXXXX.com:443
zhutong:
#助通短信
#助通終端用戶管理的用戶名 username 必填；非登錄賬號密碼，請登錄后臺管理地址進行查看：http://mix2.zthysms.com/login
accessKeyId: tushu1122XXX
#助通終端用戶管理的用戶名 passwrod 必填；
accessKeySecret: UbXXX4SL
#短信簽名，可選；可選的時候，只能使用自定義短信不能使用模板短信； 具體在這里查看審核過的短信簽名：https://mix2.zthysms.com/index.html#/SignatureManagement
signature: 上海千XXXX- 方法使用
@RestController
@RequestMapping("/test/")
public class DemoController {
// 測試發送固定模板短信
@RequestMapping("/")
public void doLogin(String username, String password) {
//阿里云向此手機號發送短信
SmsFactory.createSmsBlend(SupplierType.ALIBABA).
sendMessage("18888888888","123456");
//華為短信向此手機號發送短信
SmsFactory.createSmsBlend(SupplierType.HUAWEI).
sendMessage("16666666666","000000");
}
}客戶端模式是簡單實用的模式，我們可以直接引入三方渠道的 SDK 發送短信，但當存在多種渠道短信時，可能代碼會比較混亂。
雖然我們可以封裝多個三方渠道接口來解決問題，但研發成本還是比較高的。
另外，當研發小組分散，發送短信各自自成體系時，當某一個渠道由于某種原因被棄用時，大部分研發小組都可能會受影響。
三服務端模式
服務端模式是獨立創建一個短信平臺服務，應用服務直接使用短信平臺提供的 SDK 發送短信。
短信平臺的設計有如下要點：
1、應用管理
短信平臺為每一個接入的應用分配單獨的 appKey 和 appSecret ，每一個應用可以配置獨立的限流策略。
2、精簡的 SDK 提供按照模版單發/群發的功能
public SmsSenderResult sendSmsByTemplateId(
String mobile,
String templateId,
Map<String, String> templateParam);3、簽名、模版管理
每個應用服務涉及到的簽名、模版的管理都中心化 ，我們可以讓一個模板綁定多個渠道。
當某條短信通過渠道 A 發送失敗時，可以通過另一個渠道 B 發送，如此可以達到高可用的效果。
4、多渠道適配
服務端要加載多個渠道的 SDK ，那么可能導致依賴沖突，可以采取 SPI 機制加載渠道插件。
5、擴展功能
我們可以根據業務需求靈活定制短信平臺的功能，比如批量發送、延遲發送、路由策略、靈活的接口限流等。
服務端的設計可以非常靈活，筆者曾經重構過一個短信平臺服務，架構圖如下：
圖片
- 模仿騰訊云的 SDK 設計，提供簡單易用的短信接口；
- 設計短信服務 API 端，接收發短信請求，發送短信信息到消息隊列；
- worker 服務消費消息，按照負載均衡的算法，調用不同渠道商的短信接口；
- Dashboard 可以配置渠道、管理應用、查看短信發送記錄等。
