共计 3694 个字符，预计需要花费 10 分钟才能阅读完成。
我是 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、总结
实现性能很简略，但在实现性能的过程中代码的健壮性、稳定性以及灵活性如果你都思考到了，那面试的过程中还怕什么？进来面试，就说我基于现有的场景引入了分布式配置核心，大大提高了工作效率。进来面试，就说我对整个零碎进行齐备的监控和告警，在这个过程中线上无任何故障，平时遇到问题，我的解决思路是怎么样的等等等。
这篇文章其实也相当于是“预报”，这些性能我前面都会一一进行实现（当然了，我的小指标也不仅仅下面所提到的如此）
关注我的微信公众号【Java3y】除了技术我还会聊点日常，有些话只能轻轻说~【对线面试官 + 从零编写 Java 我的项目】继续高强度更新中！求 star！！原创不易！！求三连！！
Gitee 链接：https://gitee.com/austin
GitHub 链接：https://github.com/austin
