对” 通知中心”方案问题思考

 紧急:

     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之后在进行发送.