三歪用了10分鐘寫完了一個(gè)需求

前幾天分享了一篇「為什么PUSH推送經(jīng)常要背鍋」，反響還挺不錯(cuò)的。最近也在整理系統(tǒng)，所以想輸出一下項(xiàng)目相關(guān)的東西。

上次分享的是PUSH推送相關(guān)的，這次我們來聊聊「短信」。

拋出問題

每個(gè)公司都會發(fā)短信，對的吧？所以一般的公司都會有一個(gè)發(fā)短信的平臺（我司有一個(gè)系統(tǒng)整合了所有的消息下發(fā)，取了一個(gè)名字叫做「消息管理平臺」）。

發(fā)短信我們需要做的東西其實(shí)很少，如果發(fā)過短信的同學(xué)可能就知道：「無非就調(diào)個(gè)短信接口的API」

本質(zhì)的確是調(diào)短信接口的API而已，就是這么簡單。

一個(gè)公司往往對接的短信渠道可能不止有一個(gè)，可能對接有「百度」「騰訊」「阿里」等等各種的渠道商，所以我們很可能會分開不同的賬號。

（這里瞎扯，真實(shí)不是這樣）比如：我發(fā)營銷類的短信對接的是「百度」短信API、我發(fā)通知類短信對接的是「騰訊」短信API、我發(fā)金融催收類的短信對接的是「阿里」短信API.......

現(xiàn)在有三個(gè)渠道，所以我們的代碼也很簡單，只要在代碼里邊對接這三個(gè)渠道就OK了。

問題是這樣的：現(xiàn)實(shí)我們的渠道商往往不止這三個(gè)，變動的概率也很大，每次新增一個(gè)渠道商我們都要新增一個(gè)類，然后去發(fā)布代碼上線

有人就會問：為什么渠道商的變動概率會很大？

其實(shí)理由也很簡單：有一天有個(gè)渠道商找過來，說一分錢一條短信?，F(xiàn)在百度的短信要3分錢一條，你想不想試試新的渠道商？那肯定是想的啊。我們先接入一下，給予一些小流量，看一下成功率是怎么樣的，然后再判斷要不要放量

我們下發(fā)短信了以后，還得拉取短信的回執(zhí)（實(shí)際上就是看看我們短信的下發(fā)情況是怎么樣的）。同理，如果要拉取短信回執(zhí)，也是要單獨(dú)開發(fā)一個(gè)類去做的。

痛點(diǎn)

上面的問題痛點(diǎn)是什么？是對接一個(gè)新的渠道去下發(fā)短信嗎？并不是。下發(fā)短信的API非常簡單，我們照著文檔搞一下很快就能搞好了。

主要的痛點(diǎn)是：「每次新增一個(gè)短信渠道，我都需要去發(fā)布代碼，走上線流程」。

業(yè)務(wù)多變性，使得我們不停地修改代碼、發(fā)布代碼，會浪費(fèi)了一定時(shí)間在發(fā)布流程上......那么一些體積小的、變動頻繁的部分是否可以使用動態(tài)腳本替代？

我司就有這么一個(gè)「腳本平臺」，聽到「腳本」這個(gè)詞，你會不會覺得有點(diǎn)牛逼。（反正三歪第一次聽到的時(shí)候，就覺得這個(gè)東西就很有東西）。

使用腳本平臺

我們使用腳本的姿勢大概是這樣的:通過腳本名取到腳本對象，用接口來接收，然后調(diào)用方法（這就是面向接口編程的好處）

將代碼寫在腳本平臺上，保存起來。

一句話概要：腳本寫在腳本平臺上，然后通過腳本平臺提供的API我們通過腳本名去得到腳本對象。一般我們用接口來接收，隨后調(diào)用接口的方法。

腳本平臺如何實(shí)現(xiàn)

三歪在公司里邊并沒寫過腳本平臺，只是這次要寫文章，就簡單看了一下它的代碼。腳本平臺架構(gòu)大概如下：

首先腳本平臺給我們提供了一個(gè)頁面入口，讓我們?nèi)懩_本，填寫腳本的基本信息（腳本唯一標(biāo)識，用途，是哪個(gè)應(yīng)用需要使用等等）

腳本在頁面上填寫完畢后，存儲腳本，維護(hù)腳本的版本、狀態(tài)等信息（比如可以回滾到上一個(gè)版本，將腳本禁用/啟用）

到這里，我們可以簡單的認(rèn)為：就是把代碼存起來而已，只不過加了一些對這份代碼的一些功能（版本/狀態(tài))

腳本平臺暴露出ScriptClient客戶端供我們使用。在使用的過程中，我們只知道可以通過ScriptClient客戶端拿到腳本對象，那怎么實(shí)現(xiàn)的呢？我如果更改了腳本的內(nèi)容，那我們通過ScriptClient拿到的對象應(yīng)該也是更改過的，是怎么辦到的呢？

這種無需發(fā)布上線，更改即可生效的會讓你想到什么？配置中心 （Nacos、Apollo、Spring Cloud Config等）

腳本平臺就是通過「配置中心」類似的方式來實(shí)現(xiàn)的，其實(shí)我們要的是「能夠動態(tài)監(jiān)聽變更」的功能，而配置中心剛好都有這些功能，于是我們就用它來承載了。

知道了這個(gè)以后，事情就變得簡單起來了：ScriptServer保存完腳本以后，然后通知ScriptClient去解析腳本，ScriptClient解析腳本，反射成對象，用一個(gè)Map裝載起來。每當(dāng)我們修改腳本后，通知ScriptClient重新解析腳本、反射對象。

一句話總結(jié)：腳本實(shí)際上就是代碼，只不過代碼由我們自己來解析，反射成對象。代碼的變更，我們利用「配置中心」就可以實(shí)現(xiàn)對象的變更（不過是重新解析腳本，反射成對象，替換舊的對象而已）

短信的一些事

上面花了挺大的篇幅去介紹腳本平臺的，本來沒想寫那么多的，但怕只是提兩句三歪怕你們看不懂，于是三歪就寫多了點(diǎn)。

很多時(shí)候，明知某些流程/代碼會變更的情況下，我們可以利用腳本去寫，這樣我們就不用經(jīng)常上下線去發(fā)布代碼了。現(xiàn)在新接入一個(gè)渠道（短信簽名）對我這邊來說是非常簡單的，就寫寫腳本，本地測一下，代碼都不用發(fā)布。工作效率就能提升很多

上面也提到了，短信渠道會有很多，我們可能的營銷類短信可能就會有4~5個(gè)渠道能支持下發(fā)。

那渠道之間的流量分配我們又可以寫在配置中心上，如果某個(gè)渠道突然要漲價(jià)了，我們只要把流量切過去別的渠道就好了。如果某個(gè)渠道不合作了，那我們把該渠道腳本禁用掉就OK了。完全不需要發(fā)布

最后

如果我們有的邏輯可能需要頻繁變動，可能是校驗(yàn)邏輯，也有可能像我這種需要增加新的「渠道」。

可以考慮使用「腳本」的方式來接入，這樣我們在上線新的「邏輯」/「渠道」的時(shí)候就不需要上下線了。這樣會使我們的效率能夠提高。

我司的腳本平臺原理也很簡單（主邏輯）：Server端負(fù)責(zé)把腳本存起來以及維護(hù)其狀態(tài)，通知Client端腳本存在變動，Client端對腳本進(jìn)行解析，反射成對象，對外使用。

最近系統(tǒng)要做些整改和合并的事，所以可能最近都會分享一下項(xiàng)目相關(guān)的東西，希望大家會喜歡

各類知識點(diǎn)總結(jié)

下面的文章都有對應(yīng)的原創(chuàng)精美PDF，在持續(xù)更新中，可以來找我催更~

• 92頁的Mybatis
• 129頁的多線程
• 141頁的Servlet
• 158頁的JSP
• 76頁的集合
• 64頁的JDBC
• 105頁的數(shù)據(jù)結(jié)構(gòu)和算法
• 142頁的Spring
• 58頁的過濾器和監(jiān)聽器
• 30頁的HTTP
• Hibernate
• AJAX
• Redis
• ......

掃碼或者微信搜Java3y?免費(fèi)領(lǐng)取原創(chuàng)思維導(dǎo)圖、精美PDF。在公眾號回復(fù)「888」領(lǐng)取，PDF內(nèi)容純手打有任何不懂歡迎來問我。

原創(chuàng)電子書

原創(chuàng)思維導(dǎo)圖