七、上行短信處理服務 -功能詳細設計 --短信平臺

 9、  上行短信處理服務

短信平臺接收的上行短信，須要傳遞給各自第三方系統自行處理。也是設計了幾個方案。

方案1、每一個系統本身開發處理邏輯，繼承同一個接口，封裝成組件dll，配置到上行短信處理的Windows服務中，由Windows服務框架直接調用相應的dll。

優勢：省事，執行效率高。

缺點：後期組件更新可能會出現各系統封裝時所用的公共組件版本不一樣，致使配置到服務框架後公共組件出現衝突。

方案2、每一個系統本身開發處理邏輯，並封裝成繼承同一個接口的WebService，由上行短信處理Windows服務調用各自系統的WebService。

優勢：各系統相互獨立。可以安全的處理各自的數據。

缺點：聯調麻煩點。使用過程當中可能出現網絡問題。

方案3、由上行短信處理Windows服務將上行短信數據分別寫入各系統的數據庫。再由各應用系統本身運行定時服務進行數據處理。

優勢：數據由短信平臺推送到各系統的過程當中基本不會出現問題。

缺點：各應用系統須要多一個數據表，須要有本身的windows服務。須要在短信平臺中配置每一個系統的數據庫鏈接串，安全性過低。同時因爲定時處理，處理時間有延遲。

方案3、由各系統定時從短信平臺數據庫中獲取上行短信數據，並進行處理。

優勢：各應用系統無需本身的數據表。只需在各系統中配置一個短信平臺數據鏈接串便可。

缺點：短信平臺的數據表可被多個系統訪問，數據安全性沒法保證。另外各系統仍是須要本身的Windows服務。數據處理一樣會有延遲。

 

最後選定使用方案二，由各系統自行開發處理上行短信的WebService，再由短信平臺統一調用。

此方案能有效保證原始數據的安全性，使用異步方式調用可以極大提升數據處理服務的處理效率。可是在第三方應用系統項目部署時確實遇到了一些問題，像是部署後短信平臺服務器和第三方系統所在的服務器網絡不通、第三方系統WebService異常信息不精準等問題，出錯後都須要慢慢排查解決。