如何设计一个公司级别的消息通知系统？

实际场景



早上买早点，扫码下单，用户在微信中会收到下单成功的服务通知。





扫码出地铁后，手机会收到APP支付通知。





微信、支付宝、刷卡消费后，手机会收到短信通知。





在海底捞吃完火锅，扫结账小票上的开票二维码开电子发票，商家开完票要通过邮件通知发送给消费者。





在移动互联网时代，商家要通过各种渠道触达到消费者。触达的方式各种各样，可以通过Email、Wechat、DingDing、SMS、App、MQTT通知等。对于做B2C业务的企业，需要具备这些相关的能力。今天，我们就聊一聊通知系统怎么做。



架构设计



通常来说，一个公司有很多的业务线，这些业务线都需要通过不同的方式通知自己的消费者。虽然每条业务线都有这个需求，但是不用重复造轮子，可以做一个公司级别的通知系统，有业务线需要使用，就可以直接调用通知系统的接口，进行相关的通知发送。



既然是一个公司级别的通知系统，上游业务方使用的通知方式肯定多种多样，这就需要通知系统聚合这些通知功能，然后向上游暴露这些接口，给业务方使用。



同时，通知系统要考虑触达率，如果用户收不到信息，是不是需要做重试，重试的次数等问题。





这里，给大家介绍一些相关的设计思路，及需要考虑的问题，供大家参考。



重点问题



1.并发问题



既然是一个公司级别的通知系统，上游业务方众多，并发量大，考虑到是通知业务，并不是有非常非常高的实时性需求，所以可以考虑做异步处理，上游调用通知接口，通知服务将通知任务放入通知队列慢慢处理，并立即告诉上游业务方通知任务接受成功。这里异步可以考虑使用Kafka。



对于有实时性要求的业务，可以单独再开接口处理。



2.是否重试、如何重试



因为上游业务是不一样的，有的业务需要对通知失败的任务进行重试，有的可能就不管了。所以通知业务再提供接口时，可以考虑加上参数QOS，也就是消息质量，如果传入了对应需要重试的QOS，则通知系统会重试通知。



如果需要重试，如何自动重试，重试的时间间隔如何？这一点我在之前的文章《支付公司如何赚钱？支付网关如何设计？》中也说过，可以看一下。其中设计的参考信息也给出来，轮询时间间隔可以参考（微信通知)，队列可以参考亚马逊云的死信队列（死信队列）。



经过多次重试，最终还是失败的任务，需要持久化到数据库。



重试功能应该是通知平台的重要功能之一。



3.后台统计分析、通知监控、手动重试



一个公用的通知平台，需要一个监控后台，监控、分析平台通知发送情况、通知到达率、失败任务手动重试等功能。



4.实现各种通知能力



触达消费者的方式各种各样，可以通过email、wechat、dingding、sms、app、mqtt 等各种方式，通知系统的功能重要功能之一就是聚合这些通知方式。

Email



消费者开电子发票，发票业务系统就需要把开除了的票通过Email发送给消费者，通知系统就需要集合邮件功能。

Wechat



消费者下完单，下单业务系统就需要通过公众号模版等形式给消费者微信推送下单成功的消息，通知系统就需要集成服务消息推送功能。

SMS



双十一之前，商户需要通过短信给自己的会员发送节日活动等信息，通知系统就需要集成短信推送功能。

HTTP



自己的系统替商户处理完业务后，需要回调通知商户系统，通常都需要使用http做回调，通知系统就需要实现http回调功能。

MQTT



业务系统需要使用mqtt发布订阅消息时，通知系统就需要实现mqtt的sub功能。可以参考我之前的一篇关于MQTT的介绍。



当一个通知系统集成了各种通知功能，可以自动重试，同时有统计监控管理平台，一个通用的通知系统就搭建完成了。



参考：

Amazon Simple Notification Service

Aliyun MQTT



完成，收工！！

【传播知识，共享价值】，感谢小伙伴们的关注和支持，我是【诸葛小猿】，一个彷徨中奋斗的互联网民工。