Müde, von Neuigkeiten unterbrochen zu werden, aber auch Angst vor plötzlicher Stille;
1. Betriebswirtschaftlicher Hintergrund
Im Microservice-Architektursystem wird es viele grundlegende Dienste geben, die einige Funktionen bereitstellen, die die meisten Dienste möglicherweise benötigen, wie Dateiverwaltung, MQ-Warteschlangen, Caching-Mechanismen, Nachrichtenzentren usw. Diese Dienste müssen verschiedene wiederverwendbare Methoden bereitstellen. damit andere Business-Dienste schnell aufgerufen werden können; schauen wir uns das Prinzip der Nachrichtenbenachrichtigung an:
Die Nachricht hier unterscheidet sich von der MQ-Warteschlange, die sich auf den Benachrichtigungsmechanismus auf der Geschäftsseite bezieht, z. B. SMS, E-Mail, Systemnachrichten usw. Auf Geschäftsebene gibt es viele Anforderungen, und normalerweise wird ein separates Nachrichtenzentrum dazu gepackt Bereitstellung eines Benachrichtigungsmechanismus;
Aus Sicht des Prozesses stellt die Nachrichtenbenachrichtigung ein typisches Produktions-Konsum-Modell dar. Die Geschäftsseite produziert kontinuierlich Nachrichten, und das Nachrichtenzentrum konsumiert sie nach Erhalt und sendet die Benachrichtigungen an die entsprechenden Kanäle.Offensichtlich hat diese Logik einen hohen Stellenwert Grad der Wiederverwendung Geschlecht.
2. Nachrichtenbenachrichtigung
1. Prozessmanagement
Das Prozessdesign der Nachrichtenbenachrichtigung über die vom Nachrichtenzentrum in jedem Geschäftsbereich bereitgestellte Schnittstellenmethode, der Inhalt der Nachricht in verschiedenen Szenarien wird an das Nachrichtenzentrum übermittelt, und das Nachrichtenzentrum führt eine einheitliche Wartung und Verwaltung durch und passt die entsprechenden an Nachricht nach Quelle und Ziel der Nachricht Push-Logik:
- Nachrichtenproduktion: Es gibt viele Szenarien, wie Aktivitäten, Marketingmechanismen, Systembenachrichtigungen, Geschäftsumlauf, Ablauferinnerungen usw.;
- Nachrichtenverwaltung: Überprüfen Sie die Struktur und die Parameter aktuell gesendeter Nachrichten, erstellen Sie Aufgaben für den Nachrichten-Push, verwalten Sie die Push-Verwaltung auf Aufgabenebene und verfolgen Sie den Statuszyklus von Nachrichten;
- Nachrichtenverbrauch: Erstellen Sie basierend auf der Struktur von Nachrichtenaufgaben den Hauptinhalt von Nachrichten-Push und verbinden Sie mehrere Sendekanäle, um eine effiziente Zustellung von Benachrichtigungen zu erreichen;
- Geplanter Task: Die Nachricht kann direkt und sofort gepusht werden, aber wenn sie durch einen nächtlichen geplanten Task ausgelöst wird, sollte das Push-Verzögerungsproblem berücksichtigt werden, und die Nachricht wird zum angegebenen Zeitpunkt zugestellt;
- Kanal-Docking: Normalerweise bedeuten unterschiedliche Kanäle unterschiedliche Szenarien, z. B. Überwachung von Push-DingTalk, Aktivitäten pushen im Allgemeinen WeChat, Kontoänderungen senden E-Mails, Marketing geht über SMS, Geschäftsbenachrichtigungen sind In-App;
Es gibt viele Module, die in den gesamten Prozess involviert sind, und der Statusfluss ist auch sehr kompliziert, aber ein einheitliches Standardmanagement und die Verfolgung von Zu- und Abflüssen durch das Nachrichtenzentrum können auch eine klare Lebenszyklusüberwachung und -wartung bieten;
2. Prozess-Timing
In der gesamten Nachrichtenbenachrichtigungsverknüpfung sind in verschiedenen Flussknoten alle Zustandsänderungen (d. h. von.nach-Zustand) beteiligt, die eine Ansicht des gesamten Lebenszyklus bilden können:
- Initialisierung: Die Geschäftsseite erstellt eine einfache Nachrichtenstruktur, und nachdem die Anforderung an das Nachrichtenzentrum gesendet wurde, wird eine Nachrichtenaufgabe initialisiert;
- Aufgabenbasiert: Überprüfen Sie die Anfrage zum Senden der Nachricht und konvertieren Sie die Nachricht in eine standardmäßige Push-Aufgabenstruktur;
- 推送中：根据任务推送的时间周期类型，将任务构建成不同渠道的通知主体，从而进行渠道消息推送；
- 已完成：根据消息在渠道推送的状态回调，更新消息中心的任务完成状态，或者失败重试；
大部分的消息通知机制都可以容忍一定的延迟性，所以消息中心完全可以解耦各个流程，引入MQ队列或者异步机制，业务方只需要将请求发送到消息中心，之后由消息中心统一调度和管理即可；
3、结构设计
这里根据系统的实现过程和经验，给出一个数据结构的设计参考，用来对业务场景做简单的维度描述：
- 消息模板：定义通知的主体结构，基于消息的参数模型，构建推送的消息内容；
- 消息任务：消息中心管理和维护的主体结构，以任务的模式维护消息从生产到推送完成的整个状态周期；
- 场景记录：消息最终推送出去的内容和场景分类，也可以简单的理解为不同渠道的投递记录；
- 交互消息：强调消息在接收方是否触达并且对消息产生了交互行为，例如会话，邮件回复，状态关联等；
三、实践总结
最后还是站在技术实现的角度，总结一下消息通知机制中的一些关键问题：
- 生产消费：消息生产之后写入消息中心的存储容器，之后进行消费流程的管理，是业务解耦的常用手段；
- 任务管理：以任务的模式进行消息推送的调度，通过任务状态的变化和控制，实现生命周期的管理；
- 状态机：描述消息的流转节点和状态，在不同的事件中触发不同的状态切换和转移，并在状态变化后衔接各种业务动作；
- 渠道对接：通常消息推送的渠道多是第三方平台，所以在消息中心会接入诸多的渠道，例如微信、钉钉、短信等；
- 基础封装：作为分布式系统中的基础功能，在封装消息管理功能时，要考虑一定的复用性和流程的可视化呈现；
消息的本质是信息的触达和传递，但是过多的消息通知也容易让用户产生厌倦心态，所以消息内容的简洁明确，推送的间隔时段以及阅读提醒，在产品具体的实现上需要极为用心，从而让消息在业务体系中发挥更大的价值。
四、参考源码
编程文档：
https://gitee.com/cicadasmile/butte-java-note
应用仓库：
https://gitee.com/cicadasmile/butte-flyer-parent
- 我正在参与掘金技术社区创作者签约计划招募活动，点击链接报名投稿。