對” 通知中心”方案問題思考

 緊急:

     1, 高可用,異常恢複

     2, 通知中心監控

大家與小果老師溝通後:

   1,監控

        (1)發送成功如何判斷

        (2)如果發送失敗能否快速定位?

   2, 建議用Jar方式接入業務系統(參考:jar,rest,url)

   3,隊列優先級 (例如正處理30萬短信,突來2個驗證碼,這個優先級問題.)

   4,存入Mysql并發問題.

   5,第三方切入,切換; 如何解耦合

   6,銘感詞

1、為什要調整架構

針對目前存在的問題

（1）功能單一: 存在一個短信平台,隻能發送短信。需要擴充郵件，APP等服務。

（2）排錯困難: 短信平台沒有詳細的資訊跟蹤，線上問題隻能找運維,排查問題困難

（3）穩定性：子產品耦合嚴重，需要進行拆分處理。

2、寫入資料庫怎麼解決高并發

異步寫入：消費者消費隊列上的資訊，配置設定不同的線程處理寫入Mysql和發送短信給使用者。

3、發送給第三方成功與否怎麼确認？

（1）根據日志進行監控，每個方法都會有日志資訊。

（2）将第三方的傳回碼作為資料庫的字段，友善查詢問題。

4、服務高可用怎麼實作

先部署一部分，後部署一部分？

5、給業務方url安全問題怎麼處理，調用失敗應對措施？

封裝成長連接配接或者dubbo，封裝成sdk，

url嵌套在sdk内部，使用内網？

業務系統注冊的key值設定成動态

6、可擴充性考慮

短信網關過渡到新的平台如何進行？

郵件和其他APP應用（比如學而思APP、教師APP），統一規範如何确定？

可以預留拓展接口。

7、一個接口能否相容不同的消息處理？

API命名的設計需要仔細考慮。

如何區分不同的消息類型？

8、SDK接入方式

依賴的的三方包要盡量的少，容易與接入的系統發生沖突。

9、管理背景——模闆管理

1. 需要對常見的模闆進行配置化，給每一個模提供Id，提升使用者的使用者體驗。
2. 消息組裝（填空方式）？
3. 統計短信從業務方調用到通知中心再到第三方平台的時延、到達率、發送短信的規則（時間段的選擇）、KPI考核。

10、消息由哪一方放入到MQ裡？

目前由短信平台放到mq中去。

11、建議增加外呼系統

現在依賴第三方，可以接入外呼系統，模拟人進行打電話，主要應用于短信驗證碼，可以在短信阻塞的情況下進行語音提示（時間不宜過晚）。

12、優先級的判斷

MQ的選擇一個還是多個

與産品進行溝通。

13、标簽化管理

背景可以對不同行為的使用者打上标簽，友善推送或者提醒繳費等任務。

14,在規定時間發送問題, 例如23:00-6:00之間,不進行發送,如果就是22:59正在發送一百萬,還有二十萬消息,這個怎麼處理?

 解答:

     (1)消息定時在進入隊列之前進行設定,而不是進隊列之後進行定時設定.

     (2)到了23:00剩下的明天6:00之後在進行發送.