非功能性需求主要有以下幾點:1。穩定的交付保障:分為兩部分，壹是服務本身的穩定性，二是短信服務商的穩定性。服務本身的穩定性需要自己實現，可以通過微服務平臺現有的壹些工具來保證，這裏就不展開了。另壹個需要外部擔保，需要外部擔保的永遠是脆弱的，不能只用壹個服務商。需要用不止壹個。第二，方便擴展:接下來服務商可能會有變更的需求，需要保證容易接入現成的服務商。三、資產保護:短信與郵件、微信通知等的壹個區別。就是成本比較高，壹條定價3分左右，比較長的短信會拆分成多條。如果不加限制的保護，很容易造成大量的資金流失。第四，技術選型基於以上要求。公司可以使用基本的web服務。對於存儲，因為涉及到發送信息和報表，所以量可能比較大(其實上線後還行，3個月不到1000萬條記錄)，統計可能是基於壹些發送內容，用MySQL之類的可能不靠譜。選擇ES。為了安全，需要限制手機號每天的發送量和發送頻率，redis可以輕松解決。5.接入多個服務提供商需要從多個服務提供商接入，壹個服務提供商可能同時提供多個SMS功能。同時，同壹個短信功能需要依次調用所有提供的服務提供商，壹個失敗後重試。它還需要支持靈活的配置，可以禁用壹些服務提供商或輕松添加新的服務提供商。
6.設置發送限制。統計手機號碼和ip的發送次數可以簡單地通過使用reids的incr和與時間戳相關的鍵來完成。我不需要在這裏重復這個。如果發送限制首先要針對不同的功能，因為不同功能的用法是完全不同的，而且它還有隔離的作用，壹個功能超過限制就不能影響其他功能。其次，發送限制需要分層。達到全球限額後，即使不超過單個手機的限額，也不應該發出去。單次訪問應用限制(次數/白名單/交換機)->；單個電話/ip限制(次數/白名單/交換機)-& gt；應根據統計數據和業務變化適當調整風險控制服務(切換)的頻率。八。性能這個服務明顯是IO密集型的，所以沒有計算，主要是調用各種外部服務，等待IO返回。所以這些用來做請求的線程池可以配置的大壹點，實際主要的是HTTP連接池。但是，不適合將連接超時和讀取超時設置得太大。