厌烦被消息打扰,又怕突然间的安静;
微服务的架构体系中,会存在很多基础服务,提供一些大部分服务都可能需要的能力,比如文件管理、MQ队列、缓存机制、消息中心等等,这些服务需要提供各种可以复用的方法或者接口,以便其他业务服务可以快速调用;下面来看看消息通知的原理:
这里的消息不同于MQ队列,是指业务侧的通知机制,例如短信、邮件、系统消息等,在业务层面的需求很多,通常会封装单独的消息中心提供通知机制;
从流程上面看,消息通知是典型的生产-消费模式,业务侧不断的生产消息,消息中心在接收之后进行消费,把通知推送到相应的渠道中,很显然这种逻辑具备很高的复用性。
消息通知的流程设计,在各个业务线中通过消息中心提供的接口方法,将不同场景下的消息内容提交到消息中心,消息中心进行统一维护管理,并根据消息的来源和去向,适配相应的推送逻辑:
在整个流程中涉及到的模块比较多,状态的流转也很复杂,但是通过消息中心进行统一标准管理和流入流出的跟踪,也可以提供清晰的生命周期监控和维护;
在整个消息通知链路中,在不同的流转节点中,无不涉及状态的变化(即from.to状态),这样可以构成整个生命周期的视图:
大部分的消息通知机制都可以容忍一定的延迟性,所以消息中心完全可以解耦各个流程,引入MQ队列或者异步机制,业务方只需要将请求发送到消息中心,之后由消息中心统一调度和管理即可;
这里根据系统的实现过程和经验,给出一个数据结构的设计参考,用来对业务场景做简单的维度描述:
最后还是站在技术实现的角度,总结一下消息通知机制中的一些关键问题:
消息的本质是信息的触达和传递,但是过多的消息通知也容易让用户产生厌倦心态,所以消息内容的简洁明确,推送的间隔时段以及阅读提醒,在产品具体的实现上需要极为用心,从而让消息在业务体系中发挥更大的价值。
编程文档:
https://gitee.com/cicadasmile/butte-java-note
应用仓库:
https://gitee.com/cicadasmile/butte-flyer-parent