聊聊消息中心的设计与实现逻辑

聊聊消息中心的设计与实现逻辑

厌烦被消息打扰，又怕突然间的安静；

一、业务背景

微服务的架构体系中，会存在很多基础服务，提供一些大部分服务都可能需要的能力，比如文件管理、MQ队列、缓存机制、消息中心等等，这些服务需要提供各种可以复用的方法或者接口，以便其他业务服务可以快速调用；下面来看看消息通知的原理：

这里的消息不同于MQ队列，是指业务侧的通知机制，例如短信、邮件、系统消息等，在业务层面的需求很多，通常会封装单独的消息中心提供通知机制；

从流程上面看，消息通知是典型的生产-消费模式，业务侧不断的生产消息，消息中心在接收之后进行消费，把通知推送到相应的渠道中，很显然这种逻辑具备很高的复用性。

二、消息通知

1、流程管理

消息通知的流程设计，在各个业务线中通过消息中心提供的接口方法，将不同场景下的消息内容提交到消息中心，消息中心进行统一维护管理，并根据消息的来源和去向，适配相应的推送逻辑：

在整个流程中涉及到的模块比较多，状态的流转也很复杂，但是通过消息中心进行统一标准管理和流入流出的跟踪，也可以提供清晰的生命周期监控和维护；

2、流程时序

在整个消息通知链路中，在不同的流转节点中，无不涉及状态的变化（即from.to状态），这样可以构成整个生命周期的视图：

初始化：业务方构建简单的消息结构，请求发送到消息中心后，初始化一个消息任务； 任务化：对消息发送请求进行校验，并将消息转换成一个标准的推送任务结构； 推送中：根据任务推送的时间周期类型，将任务构建成不同渠道的通知主体，从而进行渠道消息推送； 已完成：根据消息在渠道推送的状态回调，更新消息中心的任务完成状态，或者失败重试；

大部分的消息通知机制都可以容忍一定的延迟性，所以消息中心完全可以解耦各个流程，引入MQ队列或者异步机制，业务方只需要将请求发送到消息中心，之后由消息中心统一调度和管理即可；

3、结构设计

这里根据系统的实现过程和经验，给出一个数据结构的设计参考，用来对业务场景做简单的维度描述：

消息模板：定义通知的主体结构，基于消息的参数模型，构建推送的消息内容； 消息任务：消息中心管理和维护的主体结构，以任务的模式维护消息从生产到推送完成的整个状态周期； 场景记录：消息最终推送出去的内容和场景分类，也可以简单的理解为不同渠道的投递记录； 交互消息：强调消息在接收方是否触达并且对消息产生了交互行为，例如会话，邮件回复，状态关联等；

三、实践总结

最后还是站在技术实现的角度，总结一下消息通知机制中的一些关键问题：

消息的本质是信息的触达和传递，但是过多的消息通知也容易让用户产生厌倦心态，所以消息内容的简洁明确，推送的间隔时段以及阅读提醒，在产品具体的实现上需要极为用心，从而让消息在业务体系中发挥更大的价值。

四、参考源码

编程文档： https://gitee.com/cicadasmile/butte-java-note 应用仓库： https://gitee.com/cicadasmile/butte-flyer-parent

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。