Cansado de ser interrumpido por noticias, pero también temeroso del silencio repentino;
1. Antecedentes comerciales
En el sistema de arquitectura de microservicios, habrá muchos servicios básicos que brindan algunas capacidades que la mayoría de los servicios pueden necesitar, como administración de archivos, colas de MQ, mecanismos de almacenamiento en caché, centros de mensajes, etc. para que se pueda llamar rápidamente a otros servicios comerciales; echemos un vistazo al principio de notificación de mensajes:
El mensaje aquí es diferente de la cola MQ, que se refiere al mecanismo de notificación en el lado comercial, como SMS, correo electrónico, mensajes del sistema, etc. Hay muchas necesidades a nivel comercial, y generalmente se empaqueta un centro de mensajes separado para proporcionar un mecanismo de notificación;
Desde la perspectiva del proceso, la notificación de mensajes es un modelo típico de producción-consumo. El lado comercial produce mensajes continuamente, y el centro de mensajes los consume después de recibirlos y empuja las notificaciones a los canales correspondientes. Obviamente, esta lógica tiene un alto grado de reutilización sexo.
2. Notificación de mensaje
1. Gestión de procesos
El diseño del proceso de notificación de mensajes, a través del método de interfaz proporcionado por el centro de mensajes en cada línea comercial, el contenido del mensaje en diferentes escenarios se envía al centro de mensajes, y el centro de mensajes realiza un mantenimiento y gestión unificados, y adapta el correspondiente mensaje de acuerdo con la fuente y el destino del mensaje Lógica de inserción:
- Producción de mensajes: Hay muchos escenarios involucrados, tales como actividades, mecanismos de mercadeo, notificaciones del sistema, circulación comercial, recordatorios de vencimiento, etc.;
- Gestión de mensajes: verifique la estructura y los parámetros de los mensajes enviados, cree tareas para enviar mensajes, mantenga la gestión de envíos a nivel de tareas y realice un seguimiento del ciclo de estado de los mensajes;
- Consumo de mensajes: en función de la estructura de las tareas de mensajes, construya el contenido principal del envío de mensajes y conecte múltiples canales de envío para lograr una entrega eficiente de notificaciones;
- Tarea programada: el mensaje se puede enviar de forma directa e inmediata, pero si se desencadena por una tarea programada durante la noche, se debe considerar el problema de demora de envío y el mensaje se entregará en el período de tiempo especificado;
- Acoplamiento de canales: por lo general, los diferentes canales significan diferentes escenarios, como el monitoreo de DingTalk push, las actividades generalmente push WeChat, los cambios de cuenta envían correos electrónicos, el marketing pasa por SMS, las notificaciones comerciales están en la aplicación;
Hay muchos módulos involucrados en todo el proceso, y el flujo de estado también es muy complicado, pero la gestión estándar unificada y el seguimiento de flujo de entrada y salida a través del centro de mensajes también pueden proporcionar un control y mantenimiento claros del ciclo de vida;
2. Tiempo del proceso
En el enlace de notificación de mensaje completo, en diferentes nodos de flujo, están involucrados todos los cambios de estado (es decir, de. a estado), lo que puede formar una vista de todo el ciclo de vida:
- Inicialización: el lado comercial crea una estructura de mensaje simple y, después de enviar la solicitud al centro de mensajes, se inicializa una tarea de mensaje;
- Basado en tareas: verifique la solicitud de envío del mensaje y convierta el mensaje en una estructura de tarea de inserción estándar;
- 推送中：根据任务推送的时间周期类型，将任务构建成不同渠道的通知主体，从而进行渠道消息推送；
- 已完成：根据消息在渠道推送的状态回调，更新消息中心的任务完成状态，或者失败重试；
大部分的消息通知机制都可以容忍一定的延迟性，所以消息中心完全可以解耦各个流程，引入MQ队列或者异步机制，业务方只需要将请求发送到消息中心，之后由消息中心统一调度和管理即可；
3、结构设计
这里根据系统的实现过程和经验，给出一个数据结构的设计参考，用来对业务场景做简单的维度描述：
- 消息模板：定义通知的主体结构，基于消息的参数模型，构建推送的消息内容；
- 消息任务：消息中心管理和维护的主体结构，以任务的模式维护消息从生产到推送完成的整个状态周期；
- 场景记录：消息最终推送出去的内容和场景分类，也可以简单的理解为不同渠道的投递记录；
- 交互消息：强调消息在接收方是否触达并且对消息产生了交互行为，例如会话，邮件回复，状态关联等；
三、实践总结
最后还是站在技术实现的角度，总结一下消息通知机制中的一些关键问题：
- 生产消费：消息生产之后写入消息中心的存储容器，之后进行消费流程的管理，是业务解耦的常用手段；
- 任务管理：以任务的模式进行消息推送的调度，通过任务状态的变化和控制，实现生命周期的管理；
- 状态机：描述消息的流转节点和状态，在不同的事件中触发不同的状态切换和转移，并在状态变化后衔接各种业务动作；
- 渠道对接：通常消息推送的渠道多是第三方平台，所以在消息中心会接入诸多的渠道，例如微信、钉钉、短信等；
- 基础封装：作为分布式系统中的基础功能，在封装消息管理功能时，要考虑一定的复用性和流程的可视化呈现；
消息的本质是信息的触达和传递，但是过多的消息通知也容易让用户产生厌倦心态，所以消息内容的简洁明确，推送的间隔时段以及阅读提醒，在产品具体的实现上需要极为用心，从而让消息在业务体系中发挥更大的价值。
四、参考源码
编程文档：
https://gitee.com/cicadasmile/butte-java-note
应用仓库：
https://gitee.com/cicadasmile/butte-flyer-parent
- 我正在参与掘金技术社区创作者签约计划招募活动，点击链接报名投稿。