Discutez de la logique de conception et de mise en œuvre du centre de messagerie

Fatigué d'être interrompu par des nouvelles, mais aussi peur du silence soudain ;

1. Contexte commercial

Dans le système d'architecture de microservices, il y aura de nombreux services de base qui fourniront certaines fonctionnalités dont la plupart des services peuvent avoir besoin, telles que la gestion de fichiers, les files d'attente MQ, les mécanismes de mise en cache, les centres de messagerie, etc. afin que d'autres services métiers puissent être appelés rapidement ; reprenons le principe de la notification de message :

Le message ici est différent de la file d'attente MQ, qui fait référence au mécanisme de notification côté entreprise, comme les SMS, les e-mails, les messages système, etc. fournir un mécanisme de notification ;

Du point de vue du processus, la notification de message est un modèle typique de production-consommation. Le côté métier produit en continu des messages, et le centre de messagerie les consomme après les avoir reçus, et pousse les notifications vers les canaux correspondants. Évidemment, cette logique a un fort impact. degré de réutilisation sexe.

2. Notification de messages

1. Gestion des processus

La conception du processus de notification des messages, via la méthode d'interface fournie par le centre de messagerie dans chaque secteur d'activité, le contenu du message dans différents scénarios est soumis au centre de messagerie, et le centre de messagerie effectue une maintenance et une gestion unifiées, et adapte le correspondant message en fonction de la source et de la destination du message.

  • Production de messages : de nombreux scénarios sont impliqués, tels que les activités, les mécanismes de marketing, les notifications système, la circulation des affaires, les rappels d'expiration, etc. ;
  • Gestion des messages : vérifiez la structure et les paramètres des messages pré-envoyés, créez des tâches pour la diffusion des messages, maintenez la gestion des diffusions au niveau des tâches et suivez le cycle d'état des messages ;
  • Consommation de messages : en fonction de la structure des tâches de message, construisez le contenu principal du message push et connectez plusieurs canaux d'envoi pour obtenir une livraison efficace des notifications ;
  • Tâche planifiée : le message peut être poussé directement et immédiatement, mais s'il est déclenché par une tâche planifiée de nuit, le problème de retard de poussée doit être pris en compte et le message sera livré à la période spécifiée ;
  • Ancrage de canal : généralement, différents canaux signifient différents scénarios, tels que la surveillance push DingTalk, les activités poussent généralement WeChat, les changements de compte envoient des e-mails, le marketing passe par SMS, les notifications commerciales sont intégrées à l'application ;

De nombreux modules sont impliqués dans l'ensemble du processus, et le flux d'état est également très compliqué, mais la gestion standard unifiée et le suivi des entrées et sorties via le centre de messagerie peuvent également fournir une surveillance et une maintenance claires du cycle de vie ;

2. Délai de traitement

Dans l'ensemble du lien de notification de message, dans différents nœuds de flux, tous les changements d'état (c'est-à-dire l'état from.to) sont impliqués, ce qui peut former une vue de l'ensemble du cycle de vie :

  • Initialisation : le côté métier construit une structure de message simple et, une fois la demande envoyée au centre de messagerie, une tâche de message est initialisée ;
  • Basé sur les tâches : vérifiez la demande d'envoi du message et convertissez le message en une structure de tâche push standard ;
  • 推送中:根据任务推送的时间周期类型,将任务构建成不同渠道的通知主体,从而进行渠道消息推送;
  • 已完成:根据消息在渠道推送的状态回调,更新消息中心的任务完成状态,或者失败重试;

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

3、结构设计

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

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

三、实践总结

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

  • 生产消费:消息生产之后写入消息中心的存储容器,之后进行消费流程的管理,是业务解耦的常用手段;
  • 任务管理:以任务的模式进行消息推送的调度,通过任务状态的变化和控制,实现生命周期的管理;
  • 状态机:描述消息的流转节点和状态,在不同的事件中触发不同的状态切换和转移,并在状态变化后衔接各种业务动作;
  • 渠道对接:通常消息推送的渠道多是第三方平台,所以在消息中心会接入诸多的渠道,例如微信、钉钉、短信等;
  • 基础封装:作为分布式系统中的基础功能,在封装消息管理功能时,要考虑一定的复用性和流程的可视化呈现;

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

四、参考源码

编程文档:
https://gitee.com/cicadasmile/butte-java-note

应用仓库:
https://gitee.com/cicadasmile/butte-flyer-parent

Je suppose que tu aimes

Origine juejin.im/post/7118659377296310279
conseillé
Classement