Java开源项目消息推送平台发送一条短信

Posted 2022-12-05 Java3y

我是3y，一年CRUD经验用十年的markdown程序员👨🏻‍💻常年被誉为优质八股文选手

austin项目实现的第一个渠道：：从发送短信开始

01、短信介绍

在项目介绍的时候，已经定义了austin项目的核心功能：发送消息

我认为，短信是在一整个消息推送平台里最重要的一个消息类型了（毕竟关联了很多重要的业务场景），想想我们日常使用APP时的场景：

• 验证码：登录注册、支付等等重要场景
• 通知类：用户订单信息、重要信息通知用户、重要信息通知商家等等场景
• 营销类：运营在特定时间内发送营销短信，影响业务的KPI指标完成（不过这个相对就没那么重要）
• …

（试想下，如果系统挂了10分钟，会怎么样）

发送短信在消息推送平台里比较容易实现的一种消息类型了，我会在这篇文章中让你体会发送消息如果要做得比较好也并没有那么的简单和容易，以及能够体会到为什么我在介绍austin项目的时候需要引入那么多的中间件。

（一切从一条短信开始）

02、发送短信必要准备

隔着上次的系统架构图也有好几天了，先复习下我们austin系统的整个流程

由于是初步实现，所以我先开个接口直接调用austin-handler模块，只要在austin-handler模块下实现发送短信的逻辑就好了。

我们要发送短信，一般直接接入短信渠道商就好了。以我的理解，发短信的过程是这样的：

正好前几天在群里，有个兄弟的就是在公司做短信渠道商的相关业务的。他说接口有20W QPS并发量（之前在搞各种的中间件优化避免消息的堆积），他进去了才知道发送一条短信原来是会经过这么多的流程（我复制下他原话）

我现在才知道，原来一条短信发到我们手机，经过了不知道多少流程，包括黑名单检查风控检查，关键字检查，退订检查，模板检查，客户账号检查，路由网关检查，通道检查，状态报告检查，运营商检查。。。。。。。

一般我们要去评估是否使用某短信渠道商来发送，考量的点有两个：成本和成功率。这里应该还是比较好理解的，短信渠道商有很多，他们都需要赚钱，我们作为接入方需要省钱（那自然就有有价格的差异性）。如果某一个渠道商又便宜发送成功率又高，那当然用他作为主要渠道啊！

这次我选择的是腾讯云作为austin项目下初步发送短信的渠道商。

我这次选择的理由很简单：我进去短信产品了以后，他免费给了我100条发送短信的体验卡（应该是人人都有的？我不可能是天命之子吧）。

我发现有很多小伙伴在跟着我的步伐在做的，我肯定不能把自己的短信账号和密码直接公开给大家体验的。所以到时候你们感兴趣可以用自己的账号体验一波。

麻烦**@腾讯云给我打下广告费。 @阿里云貌似有？（但入口太难找，罢了） @华为云**我还没登录体验过，等等我！

想要发送一条短信又或是接入一个短信渠道商必不可少的两个点：短信模板和短信签名。看不懂？没事，我以具体的一条测试短信为例：

有了短信签名可以让用户知道这可能是谁发过来的短信，有了短信模板可以让发送垃圾短信的概率大大减少。

有人可能就会问了：那我每发一条短信，都需要有对应模板的话，那我维护起来不就非常麻烦？这毕竟是一个推送平台啊！每次有业务需要发送新的文案，还得去对应的渠道商后台申请模板吗？

本来我以为这是正常的，没想到，如果你是公司的话，还能谈的（🐶一般人我还不告诉他）。所以，可能会有通用短信模板的存在。

但不管怎么样，短信渠道商还是会校验各种逻辑（该验证的还是会验证，你乱发消息把你的账号给限流和设置抽样人工验证文案，这样就得不偿失了）

03、功能实现

调用第三方API可能会有两种选择：HTTP调用和内嵌SDK（如果平台方有做SDK的话）。

我以前一般都是直接HTTP调用的，因为这样我的代码就不用内嵌别人家的SDK了（内嵌SDK意味着会引入其他依赖）。于是我就直接从他提供接入文档入手，尝试使用HTTP进行接入。

嗯，我花了两天多，还没接入成功。我直呼顶不住，再这样下去，催更的人都要来我家敲门了！

腾讯云接口用HTTP验签也太太太复杂了吧！原来他的注不是在吓唬我：

我搞了两个晚上已经心灰意冷了，只能妥协用他们提供的SDK了，再加上自动生成代码，嘎嘎很快地就成功了（我好奇有没有勇士曾经按照最新的API文档用HTTP接入过他们的接口）

具体的代码我就不贴了，按照惯例大家在文末(阅读原文)找到Gitee链接🔗看就好了。

跟着项目做的小伙伴，只要在配置文件改下账号信息和调用下接口，就能收到自己的短信了。（问题应该不大，有问题来群里问就好了）

04、为什么austin是消息平台

实现发送短信是一件很简单的事（从它占文章篇幅即可推断出），发送其他渠道的消息其实也很简单。从本质上讲，就是对接API调用发送接口进行发送。

作为一般项目，发完消息就没有后续了，但如果作为一个「平台」而言，这是远远不够的。

4.1 调用发送短信接口后，如果用户反馈收不到怎么办？

我们只调用了发送短信的接口，没有记录接口的返回信息（也就没有发送凭证），当别人找过来的时候，我们也无济于事（我们什么都没记录，什么都不知道）。

解决方案：我们需要存储把发送的记录给存起来，也需要有接口把短信的回执拉回来并存储，并在推送后台提供相关的页面给予快速查询。

4.2 某个短信渠道商挂了怎么办？

别以为我们的依赖是阿里云、腾讯云或者华为云这种大公司，他们提供的产品不是万无一失的，挂也是很正常的事。那如果我们只依赖一个短信渠道，它挂了，是不是相当于我们就挂了。

解决方案：短信需要接入多个渠道商，调用接口失败需要继续调用其他渠道商，支持动态分配渠道商的流量（一旦有提前预警，直接切换渠道商）

4.3 这个月短信花了多少钱，我怎么知道？

接入的短信后台都有对应的统计，但我们量大的话是需要「对账」，以我们的发送记录与回执统计跟短信的后台进行统计。

毕竟都是钱啊，不能全部信他们的啊。我曾经就有遇到过，对方的账单跟我们自己统计的数量有比较大的出入，后来排查发现他们的统计是存在问题的。

解决方案：将短信的发送和回执数据导入到Hive，每个月跑一次Hive脚本统计进行对账

4.4 现在调用短信的量大吗？

第三方接口一般都会有限流的，比如在腾讯云官网上看到对发送接口有3000QPS的限制。我们是需要知道现在各种类型的消息的发送情况是怎么样的，是否有限流的操作。如果限流了，是不是可以告诉业务方可能是原因目前发送量过大导致触发限流。

系统上有完备的监控，你知道了各种的系统指标数据，自己才不会慌。（排查问题有监控会很容易定位）

要是某一天有人跟你说你的系统挂了，你不会还傻乎乎地去服务器上看日志吧？打开监控看下有没有流量，流量正不正常不就一眼就能看到了吗。

解决方案：监控从接口调用到消息下发整个过程的数据（主要是接口QPS和下发人数）

4.5 业务方不小心连续发了两次怎么办？

业务方使用不当，不小心连续推送了两次，如果没有任何限制，那就真的下发了两次。试想下，如果你点了下验证码，霎时间，收到了两条一模一样的短信，你是什么感受？

解决方案：作为平台需要有这种兜底的功能（尽可能避免由于业务使用不恰当，导致出现事故）

4.6 这条短信谁发的啊？

客服反馈：用户接收到了一条短信（用户对具体短信的细节不理解）。客服看着短信也两眼懵逼，公司那么大，不知道由哪个业务团队下发出来的。现在只有短信的文案，怎么能快速找到下发短信的团队呢。

我们需要让所有经过austin项目的消息都有一个「载体」（说白了就是模板），有了模板之后，业务方在接入的时候需要填写各类的信息，有了这些信息再配合搜索引擎就可以快速定位出信息。

“溯源“在很多时候都很有用（比如：你提供了一个HTTP接口，如果没对业务做任何的限制。或许有朝一日，你希望对该接口进行大改动，但你不知道现在有谁进行调用，就会很头疼）

解决方案：给接入方套”模板“，有了模板才能溯源，才能做数据追踪，模板是作为平台的基石。（下一篇等我建表的时候，我会再来跟大家详细说说对应的业务）

4.7 经常要接入短信渠道怎么办？

商务又找到了便宜的短信渠道了，接入一下看看效果吧？这可是实打实省钱的啊！每次写一个类（接入短信就相当于写一个类），我都要重启发布上线吗？这不靠谱吧？

解决方案：上规则引擎将业务代码抽离，无须上下线即可实现功能。

05、总结

实现功能很简单，但在实现功能的过程中代码的健壮性、稳定性以及灵活性如果你都考虑到了，那面试的过程中还怕什么？出去面试，就说我基于现有的场景引入了分布式配置中心，大大提高了工作效率。出去面试，就说我对整个系统进行完备的监控和告警，在这个过程中线上无任何故障，平时遇到问题，我的解决思路是怎么样的等等等。

这篇文章其实也相当于是“预告”，这些功能我后面都会一一进行实现（当然了，我的小目标也不仅仅上面所提到的如此）

开源项目Gitee链接：https://gitee.com/austin

开源项目GitHub链接：https://github.com/austin