Conceptos básicos de RocketMQ-(8-1)-EventBridge-EventBridge

Conceptos básicos de RocketMQ EventBridge

Comprender los conceptos centrales de EventBridge puede ayudarnos a analizar y utilizar mejor EventBridge. Este artículo se centra en los términos incluidos en EventBridge:

• EventSource: origen del evento. Se utiliza para administrar eventos enviados a EventBridge. Todos los eventos enviados a EventBridge deben marcarse con la información del nombre del origen del evento, correspondiente al campo de origen en el cuerpo del evento CloudEvent.
• EventBus: bus de eventos. Se utiliza para almacenar eventos enviados a EventBridge.
• EventRule: regla de evento. Cuando los consumidores necesitan suscribirse a eventos, pueden filtrar y transformar la información mediante la configuración de reglas y enviar los eventos al destino especificado.
• FilterPattern: patrón de filtrado de eventos, utilizado para configurar reglas para filtrar los eventos requeridos por el objetivo.
• Transformar: conversión de eventos, convierte el formato del evento al formato de datos requerido por el objetivo.
• EventTarget: el objetivo del evento, nuestro consumidor real del evento.

A continuación, lo ampliamos detalladamente:

Fuente del evento

La fuente del evento representa la fuente de ocurrencia del evento y se utiliza para describir un tipo de evento, que generalmente corresponde al sistema de microservicio uno a uno. Por ejemplo: origen del evento de transacción, origen del evento de asistencia, etc. La fuente de eventos es una gran clasificación de eventos. Una fuente de eventos a menudo contiene varios tipos de eventos. Por ejemplo, una fuente de eventos de transacción puede incluir: eventos de pedidos, eventos de pago, eventos de devolución, etc.

Además, cabe señalar que el origen del evento no se utiliza para describir la entidad donde ocurrió el evento, sino que en CloudEvent generalmente usamos el asunto para representar el recurso de la entidad que generó el evento. El origen de los eventos se parece un poco a las grandes categorías de los hipermercados de economía de mercado, como la zona de alimentos frescos, la zona de productos químicos diarios, la zona de electrodomésticos, etc. En el "hipermercado" del centro de eventos, podemos encontrar rápidamente los eventos que necesitamos a través de fuentes de eventos.

Autobús de eventos

El bus de eventos es un lugar donde se almacenan los eventos y puede haber múltiples implementaciones debajo de él, incluidas Local, RocketMQ, Kafka, etc.

Cuando un productor de eventos envía un evento, debe especificar el bus de eventos. El bus de eventos es un ciudadano de primera clase de EventBridge. Todos los demás recursos están lógicamente aislados alrededor del bus de eventos, es decir, las fuentes de eventos y las reglas de eventos deben pertenecer a un determinado bus de eventos. Los orígenes de eventos y las reglas de eventos en diferentes buses de eventos pueden tener el mismo nombre, pero los orígenes de eventos y las reglas en el mismo bus de eventos no deben tener el mismo nombre.

Regla del evento

Cuando los consumidores necesitan suscribirse a eventos, pueden configurar el filtrado y la transformación de la información a través de reglas de eventos y enviar eventos al objetivo especificado. Por lo tanto, las reglas de eventos contienen tres partes: filtrado de eventos + conversión de eventos + destino del evento.

Patrón de filtro

A través del modo de filtrado de eventos, podemos filtrar los eventos en el bus de eventos y enviar solo los eventos requeridos por el extremo objetivo para reducir la activación innecesaria y reducir la presión sobre el extremo objetivo del consumidor. Las capacidades de filtrado de eventos admitidas actualmente por EventBridge incluyen:

• Coincide con el valor especificado
• coincidencia de prefijos
• coincidencia de sufijos
• excluir coincidencia
• coincidencia numérica
• coincidencia de matrices
• y coincidencia lógica combinacional compleja

(Los detalles se discutirán en otros artículos)

transformar

Los eventos del productor pueden ser suscritos por varios consumidores al mismo tiempo, pero diferentes consumidores a menudo requieren diferentes formatos de datos. En este momento, necesitamos convertir los eventos del productor al formato de evento requerido por el consumidor Target. Las capacidades de conversión de eventos admitidas actualmente por EventBridge incluyen:

• Evento completo: no se realiza ninguna conversión y los CloudEvents nativos se entregan directamente;
• Eventos parciales: extraiga el contenido que debe entregarse al destino del evento desde CloudEvents mediante la sintaxis JsonPath;
• Constante: el evento solo funciona como un disparador y el contenido de la entrega es una constante;
• Convertidor de plantillas: renderice de manera flexible el formato del evento entregado definiendo plantillas;

(Los detalles se discutirán en otros artículos)

Objetivo del evento

El objetivo del evento es nuestro consumidor de eventos. En la arquitectura EventBridge, los consumidores solo necesitan diseñar de acuerdo con su propio modelo de dominio comercial y proporcionar una API pública (esta API se puede usar no solo para recibir eventos, sino también para operar el plano de control frontal), y EventBridge definirá los datos requeridos según el formato API para enviar eventos de forma segura y confiable a los consumidores de Target.

Descripción general de RocketMQ EventBridge

RocketMQ EventBridge se compromete a ayudar a los usuarios a crear una arquitectura basada en eventos altamente confiable, de bajo acoplamiento y de alto rendimiento. En la arquitectura basada en eventos, los microservicios no necesitan suscribirse activamente a mensajes externos, sino que pueden unificar todas las entradas que desencadenan cambios en el sistema de microservicios en API, y solo necesitan centrarse en la definición del modelo de dominio empresarial del microservicio actual y Diseño API Utilice una gran cantidad de código adhesivo para adaptar y analizar mensajes de servicios externos. EventBridge será responsable de adaptar y entregar de forma segura y confiable los eventos generados por servicios externos a la API del diseño de microservicio actual.

Entonces, ¿cuándo usamos mensajes RocketMQ y cuándo usamos eventos EventBridge? ¿Qué significa un evento y en qué se diferencia de un mensaje?

Noticias y eventos

Definimos eventos de la siguiente manera:

事件是指过去已经发生的事，尤其是比较重要的事。

La relación entre eventos y mensajes es la siguiente:

Los mensajes incluyen mensajes de comando y mensajes de evento. El mensaje de comando es un comando de operación enviado por el sistema externo al sistema (como se muestra en la mitad izquierda de la figura anterior); el mensaje de evento es que el sistema recibe la solicitud de operación de comando y ocurre un evento después de que el sistema cambia internamente ( como se muestra en la mitad derecha de la figura anterior);

Cuatro características

1. ha sucedido

Un evento debe haber "sucedido". "Sucedió" también significa inmutable. Esta característica es muy importante, cuando procesamos y analizamos eventos, significa que podemos confiar absolutamente en estos eventos, siempre que sean eventos recibidos, deben ser comportamientos que realmente hayan ocurrido en el sistema.

El comando representa una solicitud de operación y se desconoce si realmente ocurre, como por ejemplo:

* 把厨房的灯打开
* 去按下门铃
* 转给A账户10w

El evento es para aclarar lo que ha sucedido. Por ejemplo

* 厨房灯被打开了
* 有人按了门铃
* A账户收到了10w

2. Sin expectativas

事件是客观的描述一个事物的状态或属性值的变化，但对于如何处理事件本身并没有做任何期望。 相比之下，Command和Query则都是有期望的，他们希望系统做出改变或则返回结果，但是Event只是客观描述系统的一个变化。

Por ejemplo: Un semáforo, que cambia de luz verde a luz amarilla, sólo describe un hecho objetivo y no tiene expectativas objetivas en sí mismo. Diferentes países y regiones tienen diferentes expectativas para este evento. Por ejemplo, en Japón una luz amarilla es igual a una luz roja, pero en Rusia está tácitamente permitido pasar una luz amarilla.

Comparar con el mensaje de comando:

• Evento: Es un poco como una "economía de mercado". Los bienes se producen y se colocan en grandes escaparates en los centros comerciales. Los consumidores los volverán a comprar si les gustan. Si nadie los compra, los bienes pueden caducar y desperdiciarse.
• Mensaje de comando: Es un poco como una "economía planificada", que produce según demanda, especifica objetos de distribución y produce pocos residuos.

3. Naturalmente ordenado y único

同一个实体，不能同时发生A又发生B，必有先后关系；如果是，则这两个事件必属于不同的事件类型。

Por ejemplo: un mismo semáforo no puede cambiar a luz verde y luz roja al mismo tiempo, solo puede cambiar a un estado al mismo tiempo. Si vemos dos eventos con el mismo contenido, entonces deben haber sucedido dos veces, una antes y otra después. Esto es muy valioso para nosotros al abordar la eventual consistencia de los datos y el análisis del comportamiento del sistema (como los escenarios ABA): lo que vemos no es solo el resultado final del sistema, sino también una serie de eventos antes de que se convierta en este resultado. proceso.

4. Encarnación

El evento hará todo lo posible para registrar la "escena del crimen" de la manera más completa posible, pero como el evento no sabe cómo la usarán los consumidores, será lo más detallada posible. incluir:

什么时候发生的事件？
谁产生的？
是什么类型的事件？
事件的内容是什么？内容的结构是什么？
... ...

En comparación con nuestros mensajes comunes, debido a que el flujo ascendente y el flujo descendente generalmente están determinados, a menudo por el bien del rendimiento y la eficiencia de la transmisión, se simplificarán tanto como sea posible, siempre que satisfagan las necesidades de los consumidores especificadas por la "economía planificada".

Escenarios de aplicación típicos de RocketMQ EventBridge

Escenario 1: notificación

En los microservicios, a menudo nos encontramos con la necesidad de notificar a otros consumidores sobre los mensajes producidos en un microservicio. Aquí comparamos tres métodos:

A: método de fuerte dependencia

El productor llama activamente a los microservicios del consumidor y se adapta a la API del consumidor. Este diseño es sin duda muy malo: el productor depende en gran medida del consumidor y está profundamente acoplado. Si se produce una excepción al llamar a un determinado consumidor y no se implementa un aislamiento efectivo, es fácil que todo el microservicio se cuelgue. Cuando llegan nuevos consumidores, la escalabilidad es extremadamente pobre.

B: método semidesacoplado

Los productores envían mensajes al servicio de mensajes y los consumidores se suscriben al servicio de mensajes para obtener los mensajes y analizarlos en el formato de datos requerido en su propio modelo de dominio comercial. Este método logra el desacoplamiento en el enlace de llamada y reduce en gran medida los riesgos del sistema. Sin embargo, los consumidores aún necesitan comprender y analizar la semántica comercial del productor y convertir los mensajes en el formato que necesitan en sus propios campos comerciales. De esta manera, cuando un consumidor necesita suscribirse a datos de múltiples productores, se debe utilizar una gran cantidad de código adhesivo para adaptar los mensajes generados por cada productor. Además, cuando cambie el formato del mensaje del productor ascendente, también habrá riesgos y costos de operación y mantenimiento.

B: método de desacoplamiento completo

De esta manera, los consumidores no necesitan introducir un SDK para suscribirse al Broker. Solo necesitan diseñar la API de acuerdo con su propio modelo de dominio comercial. El servicio de mensajería filtrará y convertirá los eventos ascendentes al formato de evento requerido por la API. . No existen dependencias del enlace de llamada ni dependencias comerciales. Cuando el formato de datos del evento del productor ascendente cambia, el servicio de mensajería realizará una verificación de compatibilidad y puede negarle al productor el envío de eventos o emitir una alarma.

Escenario 2: Integración

El escenario 1 está orientado principalmente a la comunicación de eventos entre varios microservicios dentro de un producto. El escenario 2 es principalmente para la comunicación de eventos entre múltiples productos. En una empresa, a menudo utilizamos varios productos y es posible que muchos de los productos no los desarrollemos nosotros, sino que adquirimos servicios SaaS externos. En este momento, es más difícil si queremos que los eventos fluyan entre diferentes productos SaaS externos, porque estos productos SaaS externos no los desarrollamos nosotros y no podemos modificar fácilmente el código que contienen. La capacidad del centro de eventos proporcionada por EventBridge puede ayudar a recopilar eventos generados por cada producto y organizarlos bien, tal como los productos en el escaparate de un hipermercado, cuidadosamente colocados y preparados, con instrucciones de introducción para que los consumidores elijan y al mismo tiempo proporcionar Servicio de entrega puerta a puerta.

¿Cómo funciona RocketMQ EventBridge? ​

Para resolver los problemas mencionados en los dos escenarios de aplicación anteriores, EventBridge comienza con 5 comodidades:

1. Determine los estándares de los eventos:  porque los eventos no son para que usted los vea, sino para que todos los vean. No tiene consumidores claros, todos son consumidores potenciales. Por lo tanto, necesitamos estandarizar la definición de eventos para que todos puedan entenderlos de un vistazo. Actualmente, CloudEvent bajo CNCF se ha convertido gradualmente en un estándar de facto generalizado, por lo que seleccionamos CloudEvent como el estándar de eventos para nuestro EventBridge.

2. Establezca un centro de eventos:  El centro de eventos contiene todos los sistemas y varios eventos registrados. Esto es como el hipermercado de economía de mercado que mencionamos anteriormente. Está lleno de varios eventos organizados en categorías. Todos Incluso si no lo compra, puede Puedo entrar y echar un vistazo, ver qué eventos puedo necesitar y luego volver a comprarlo.

3. Definir el formato del evento:  el formato del evento se utiliza para describir el contenido específico del evento. Esto equivale a un contrato de compraventa en la economía de mercado. El formato de los eventos enviados por los productores debe determinarse y no siempre puede cambiarse; también debe determinarse el formato en el que los consumidores reciben los eventos, de lo contrario todo el mercado quedará sumido en el caos.

No. 4. "Reglas" de suscripción:  Tenemos que brindar a los consumidores la capacidad de entregar eventos al objetivo, y filtrar y convertir los eventos antes de la entrega para que puedan adaptarse al formato de los parámetros recibidos por la API de destino. esto El proceso se llama creación de una regla de suscripción.

No. 5. Bus de eventos:  Finalmente, tenemos que tener un lugar para almacenar eventos, que es el bus de eventos en el medio de la imagen.

Inicio rápido de RocketMQ EventBridge

RocketMQ EventBridge requiere un servicio de mensajería para almacenar eventos y un tiempo de ejecución para suscribirse y enviar eventos. Aquí elegimos Apache RocketMQ como nuestro servicio de mensajería y Apache RocketMQ Connect como nuestro tiempo de ejecución para suscribirnos y enviar eventos. Por supuesto, también puedes elegir otros servicios de mensajería, EventBridge no impone restricciones al respecto. En el futuro, EventBridge también planea implementar su propio Runtime basado en la API OpenMessaging Connect para brindar mejor servicios basados ​​en eventos.

Requisitos del sistema:

• Sistema operativo de 64 bits, se recomienda Linux/Unix/macOS
• JDK de 64 bits 1.8+

Implementar Apache RocketMQ

Apache RocketMQ es un excelente servicio de mensajería y lo elegimos como almacenamiento predeterminado para EventBus de forma predeterminada. Aquí puede implementar rápidamente de acuerdo con este manual:  Inicio rápido de Apache RocketMQ

Implementar Apache RocketMQ Connect

Usamos Apache RocketMQ Connect como nuestro tiempo de ejecución predeterminado para conectar servicios externos ascendentes y descendentes. Puede completar la implementación de acuerdo con el manual:  Inicio rápido de RocketMQ Connect  . Antes de implementar Apache RocketMQ Connect, debe descargar el siguiente complemento y colocarlo en el directorio definido por el parámetro de configuración "pluginPaths" en rocketmq-connect:

• rocketmq-connect-eventbridge-jar-con-dependencias.jar
• rocketmq-connect-dingtalk-jar-con-dependencias.jar
• connect-cloudevent-transform-jar-con-dependencias.jar
• conectar-filtro-transformar-jar-con-dependencias.jar
• conectar-eventbridge-transformar-jar-con-dependencias.jar

Implementar RocketMQ EventBridge

• ObtenerEventBridge

Puede descargar el paquete binario de EventBridge desde aquí : rocketmq-eventbridge-xxx-bin-release.zip. Después de descargarlo, descomprímalo y obtendrá un directorio como el siguiente:

/rocketmq-eventbridge-xxx-bin-release/
|——bin
|   |——runserver.sh
|   |——eventbridge.sh
|——config
|   |——application.properties
|——jar
|   |——rocketmq-eventbridge.jar

• Configurar EventBridge

Antes de ejecutar, debemos configurar el entorno de ejecución de EventBridge y modificar config/application.properties, la referencia es la siguiente:

# Mysql数据库的连接地址
spring.datasource.url=jdbc:mysql://xxxx:3306/xxxx?characterEncoding=utf8
spring.datasource.username=xxx
spring.datasource.password=xxxx

# RocketMQ nameserver的连接地址
rocketmq.namesrvAddr=xxxxx:9876

# RocketMQ的集群名称.
rocketmq.cluster.name=DefaultCluster

# RocketMQ Connect的连接地址
rocketmq.connect.endpoint=xxxxxx:8082

# log默认配置
log.path=～
log.level=INFO
app.name=rocketmq-eventbridge

• Iniciar EventBridge

sh bin/eventbridge.sh start 

El directorio de registro predeterminado es ~/rocketmq-eventbridge/rocketmq-eventbridge.log, que se puede modificar modificando log.path y app.name anteriores. Puede observar si el servicio se inicia normalmente a través del registro:  

• Puente de eventos de prueba

Cuando se inicia el servicio, podemos probar y verificar EventBridge a través del siguiente caso de uso de demostración.

Demostración

• Crear bus de eventos

POST /bus/createEventBus HTTP/1.1
Host: demo.eventbridge.com
Content-Type: application/json; charset=utf-8
{
"eventBusName":"demo-bus",
"description":"a demo bus."
}

• Crear fuente de evento

POST /source/createEventSource HTTP/1.1
Host: demo.eventbridge.com
Content-Type: application/json; charset=utf-8
{
"eventBusName":"demo-bus",
"eventSourceName":"demo-source",
"description":"A demo source."
}

• Crear reglas de eventos

POST /rule/createEventRule HTTP/1.1
Host: demo.eventbridge.com
Content-Type: application/json; charset=utf-8
{
  "eventBusName":"demo-bus",
  "eventRuleName":"demo-rule",
  "description":"A demo rule.",
  "filterPattern":"{}"
}

• Crear objetivo de evento

Cree un destino de evento que se entregue a EventBridge en la nube:

POST /target/createEventTargets HTTP/1.1
Host: demo.eventbridge.com
Content-Type: application/json; charset=utf-8
{
    "eventBusName":"demo-bus",
    "eventRuleName":"demo-rule",
    "eventTargets":[
            {
            "eventTargetName":"eventbridge-target",
            "className":"acs.eventbridge",
                "config":{
                "RegionId":"cn-hangzhou",
                "AliyunEventBus":"rocketmq-eventbridge"
                }
            }
        ]
}

Cree un objetivo de evento que entregue notificaciones automáticas a DingTalk Bot:

POST /target/createEventTargets HTTP/1.1
Host: demo.eventbridge.com
Content-Type: application/json; charset=utf-8
{
    "eventBusName":"demo-bus",
    "eventRuleName":"demo-rule",
    "eventTargets":[
        {
            "eventTargetName":"dingtalk-target",
            "className":"acs.dingtalk",
            "config":{
            "WebHook":"https://oapi.dingtalk.com/robot/send?access_token=b43a54b702314415c2acdae97eda1e092528b7a9dddb31510a5b4430be2ef867",
            "SecretKey":"SEC53483bf496b8f9e0b4ab0ab669d422208e6ccfaedfd5120ea6b8426b9ecd47aa",
            "Body":"{\"template\":\"{\\\"text\\\":{\\\"content\\\":\\\"${content}\\\"},\\\"msgtype\\\":\\\"text\\\"}\",\"form\":\"TEMPLATE\",\"value\":\"{\\\"content\\\":\\\"$.data.body\\\"}\"}"
            }
        }
    ]
}

• Enviar eventos a EventBus

  Finalmente, enviamos un evento a través de la API y verificamos si el lado de Target recibe el evento correspondiente como se esperaba.

POST /putEvents HTTP/1.1
Host: demo.eventbridge.com
Content-Type:"application/cloudevents+json; charset=UTF-8"
{
  "specversion" : "1.0",
  "type" : "com.github.pull_request.opened",
  "source" : "https://github.com/cloudevents/spec/pull",
  "subject" : "123",
  "id" : "A234-1234-1234",
  "time" : "2018-04-05T17:31:00Z",
  "datacontenttype" : "application/json",
  "data" : {
    "body":"demo"
  },
  "aliyuneventbusname":"demo-bus"
}