分為兩部分,壹個是服務本身的穩定性,另壹個是短信服務提供商的穩定性.
服務本身穩定是自己需要實現的,可以通過微服務平臺已經有的壹些工具保證,這裏不進行展開.而另壹個是需要外部保證的,外部需要保證的東西永遠是脆弱的,所以不能僅僅使用壹家服務商,需要使用多家.
二、方便擴展:
接著壹點,服務商可能會有更換的需求,需要保證能夠方便接入下架服務商.
三、資產保護:
短信相比郵件,微信通知等的壹個不同是他花費比較高,壹條的計價在3分左右,較長的短信會被拆為多條,如果不加限制進行保護很容易造成大量的資損.
四、技術選型
有了上面的需求之後就是選用什麽技術了.基礎的web服務就使用公司現有的即可.對於存儲,因為涉及到發送信息和報告的記錄,量可能會很大(其實上線之後也還好,3個月不到千萬記錄),統計時可能會按照某些發送內容統計,使用MySQL之類的可能會不太靠譜,選擇使用ES.對於安全,壹定需要做手機號每日發送量和發送頻率等的限制,這個用redis可以較為輕松解決.五、接入多家服務商需要有多家服務商的接入,壹家服務商可能同時供應多個短信功能.同時同壹個短信功能需要輪流調用所有提供的服務商,並在壹家失敗後進行重試.也需要支持靈活的配置,可以禁用掉壹些服務商,也可以方便加入新的。六、發送限制設置關於手機號和ip的發送數量計數使用reids的incr配合時間戳相關的key就可以很簡單完成,這裏不累述這個.發送限制的話先要針對不同功能,因為不同功能的使用量是截然不同的,並且也有隔離的作用,壹個功能超限不能影響其他功能.其次,發送的限制需要分層級,當達到了全局大限制後,就算沒有超過單手機限制也不應該發出去了.七、使用的層次是:
功能全局次數(次數)->單接入應用限制(次數/白名單/開關)->單手機/ip限制(次數/白名單/開關)->風控服務(開關)，後次數要根據統計情況和業務更改做適當調整.八、性能
這個服務很明顯是IO密集的,就沒什麽計算,主要是調用各種外部服務,等IO返回.所以對於這些各個用來做請求的線程池就可以配置稍微大壹點,實際主要的就是HTTP的連接池.但連接超時,讀取超時也不適合設置過大.