Estilo de arquitectura basada en eventos

Azure Stream Analytics

Funciones de Azure

Azure Service Bus

Una arquitectura controlada por eventos consta de productores de eventos que generan una secuencia de eventos, consumidores de eventos que escuchan estos eventos y canales de eventos que transfieren eventos de productores a consumidores.

Los eventos se entregan casi en tiempo real, de modo que los consumidores pueden responder inmediatamente a los eventos cuando se producen. Los productores se desacoplan de los consumidores: un productor no sabe qué consumidores están escuchando. Los consumidores también se desconectan entre sí, y cada consumidor ve todos los eventos. Este proceso difiere de un patrón de consumidores competidores en el que los consumidores extraen mensajes de una cola y un mensaje solo se procesa una vez, suponiendo que no haya errores. En algunos sistemas, como Azure Internet de las cosas (IoT), los eventos deben ingerirse en grandes volúmenes.

Una arquitectura controlada por eventos puede usar un modelo de publicación y suscripción o un modelo de flujo de eventos.

• Pub/sub: La infraestructura de mensajería publish-subscribe realiza un seguimiento de las suscripciones. Cuando se publica un evento, se envía el evento a cada suscriptor. No se puede reproducir un evento después de recibirlo y los nuevos suscriptores no ven el evento.

• Streaming de eventos: Los eventos se escriben en un registro. Los eventos se ordenan estrictamente dentro de una partición y son duraderos. Los clientes no se suscriben a la secuencia. En su lugar, un cliente puede leer desde cualquier parte de la secuencia. El cliente es responsable de avanzar su posición en la secuencia. Esto significa que un cliente puede unirse en cualquier momento y puede reproducir eventos.

En el lado del consumidor, hay algunas variaciones comunes:

• Procesamiento de eventos simple: Un evento desencadena inmediatamente una acción en el consumidor. Por ejemplo, puede usar Azure Functions con un desencadenador de Azure Service Bus para que una función se ejecute cada vez que se publique un mensaje en un tema de Service Bus.

• Correlación de eventos básica: Un consumidor procesa algunos eventos empresariales discretos, los correlaciona por algún identificador y conserva la información de eventos anteriores para su uso al procesar eventos posteriores. Las bibliotecas como NServiceBus y MassTransit admiten este patrón.

• Procesamiento de eventos complejos: Un consumidor usa una tecnología como Azure Stream Analytics para analizar una serie de eventos e identificar patrones en los datos de eventos. Por ejemplo, puede agregar lecturas desde un dispositivo incrustado a lo largo de un período de tiempo y generar una notificación si la media móvil cruza un umbral determinado.

• Procesamiento del flujo de eventos: Use una plataforma de streaming de datos, como Azure IoT Hub o Apache Kafka, como una canalización para ingerir eventos y alimentarlos a los procesadores de flujos. Los procesadores de flujos sirven para procesar o transformar el flujo. Puede haber varios procesadores de flujo para distintos subsistemas de la aplicación. Este enfoque es una buena opción para las cargas de trabajo de IoT.

El origen de los eventos puede ser externo al sistema, como los dispositivos físicos de una solución de IoT. En ese caso, el sistema debe poder ingerir los datos en el volumen y el rendimiento que requiere el origen de datos.

Hay dos enfoques principales para estructurar cargas de eventos. Cuando tenga control sobre los consumidores de eventos, puede decidir la estructura de carga de cada consumidor. Esta estrategia permite mezclar enfoques según sea necesario dentro de una sola carga de trabajo.

• Incluya todos los atributos necesarios en la carga: Use este enfoque cuando quiera que los consumidores tengan toda la información disponible sin necesidad de consultar un origen de datos externo. Sin embargo, puede provocar problemas de coherencia de datos debido a varios sistemas de registro, especialmente después de las actualizaciones. La administración de contratos y el control de versiones también pueden ser complejas.

• Incluya solo claves en la carga: En este enfoque, los consumidores recuperan los atributos necesarios, como una clave principal, para capturar de forma independiente los datos restantes de un origen de datos. Este método proporciona una mejor coherencia de los datos porque tiene un único sistema de registros. Sin embargo, puede tener un rendimiento más deficiente que el primer enfoque porque los consumidores deben consultar el origen de datos con frecuencia. Tiene menos preocupaciones sobre el acoplamiento, el ancho de banda, la administración de contratos o el control de versiones porque los eventos más pequeños y los contratos más sencillos reducen la complejidad.

En el diagrama anterior, cada tipo de consumidor se muestra como un único cuadro. Para evitar que el consumidor se convierta en un único punto de error en el sistema, es habitual tener varias instancias de un consumidor. Es posible que también se necesiten varias instancias para controlar el volumen y la frecuencia de los eventos. Un único consumidor puede procesar eventos en varios subprocesos. Esta configuración puede crear desafíos si los eventos se deben procesar en orden o requieren una semántica exactamente una vez. Para obtener más información, vea Minimizar la coordinación.

Hay dos topologías principales en muchas arquitecturas controladas por eventos:

• Topología de agente: Los componentes difunden repeticiones como eventos en todo el sistema. Otros componentes actúan en el evento o omiten el evento. Esta topología es útil cuando el flujo de procesamiento de eventos es relativamente sencillo. No hay coordinación central ni orquestación, por lo que esta topología puede ser dinámica. Esta topología está muy desacoplada, lo que ayuda a proporcionar escalabilidad, capacidad de respuesta y tolerancia a errores de componentes. Ningún componente posee o conoce el estado de ninguna transacción empresarial de varios pasos y las acciones se realizan de forma asincrónica. Posteriormente, las transacciones distribuidas son arriesgadas porque no hay ninguna manera nativa de reiniciarse o reproducirse. Debe tener en cuenta cuidadosamente las estrategias de control de errores y intervención manual, ya que esta topología puede ser un origen de incoherencia de datos.

• Topología del mediador: Esta topología aborda algunas de las deficiencias de la topología de agente. Hay un mediador de eventos que administra y controla el flujo de eventos. El mediador de eventos mantiene el estado y administra las funcionalidades de control y reinicio de errores. A diferencia de la topología del agente, en esta topología, los componentes difunden repeticiones como comandos y solo a canales designados. Estos canales suelen ser colas de mensajes. Se espera que los consumidores procesen estos comandos. Esta topología proporciona más control, mejor control de errores distribuidos y posiblemente una mejor coherencia de los datos. Esta topología introduce un mayor acoplamiento entre los componentes y el mediador de eventos puede convertirse en un cuello de botella o un problema de confiabilidad.

Cuándo utilizar esta arquitectura

Debe usar esta arquitectura cuando:

• Varios subsistemas deben procesar los mismos eventos.
• Se requiere el procesamiento en tiempo real con un retraso de tiempo mínimo.
• Se requiere procesamiento de eventos complejos, como la coincidencia de patrones o la agregación a lo largo del tiempo.
• Se requiere un gran volumen y una alta velocidad de los datos, como con, por ejemplo, IoT.

Ventajas

Las ventajas de esta arquitectura son:

• Se desvinculan productores y consumidores.
• No existen integraciones de punto a punto. Es fácil agregar nuevos consumidores al sistema.
• Los consumidores pueden responder a eventos inmediatamente a medida que se producen.
• Altamente escalable, elástico y distribuido.
• Los subsistemas tienen vistas independientes del flujo de eventos.

Desafíos

• Entrega garantizada.

  En algunos sistemas, especialmente en escenarios de IoT, es fundamental garantizar la entrega de los eventos.

• Procesamiento de eventos en orden o exactamente una vez.

  Para lograr resistencia y escalabilidad, cada tipo de consumidor normalmente se ejecuta en varias instancias. Este proceso puede crear un desafío si los eventos deben procesarse en orden dentro de un tipo de consumidor o si no se implementa la lógica de procesamiento de mensajes idempotentes .

• Coordinación de mensajes entre servicios.

  Los procesos empresariales suelen tener varios servicios que publican y se suscriben a mensajes para lograr un resultado coherente en toda una carga de trabajo. Puede usar patrones de flujo de trabajo como el patrón coreográfico y la orquestación saga para administrar de forma confiable los flujos de mensajes en varios servicios.

• Control de errores.

  La arquitectura controlada por eventos usa principalmente la comunicación asincrónica. Un desafío con la comunicación asincrónica es el control de errores. Una manera de solucionar este problema es usar un procesador de controlador de errores independiente. Cuando el consumidor de eventos experimenta un error, envía inmediatamente y asincrónicamente el evento erróneo al procesador del controlador de errores y se mueve. El procesador del controlador de errores intenta corregir el error y devuelve el evento al canal de ingesta original. Pero si se produce un error en el procesador del controlador de errores, puede enviar el evento erróneo a un administrador para su posterior inspección. Si usa un procesador de controladores de errores, los eventos erróneos se procesan fuera de secuencia cuando se envían.

• Pérdida de datos.

  Otro desafío con la comunicación asincrónica es la pérdida de datos. Si alguno de los componentes se bloquea antes de procesar y entregar correctamente el evento a su siguiente componente, el evento se quita y nunca lo convierte en el destino final. Para minimizar la posibilidad de pérdida de datos, conserve los eventos en tránsito y quite o quite los eventos solo cuando el siguiente componente confirme la recepción del evento. Estas características se conocen como el modo de confirmación de cliente y la última compatibilidad con los participantes.

• Implementación de un patrón tradicional de solicitud-respuesta.

  A veces, el productor de eventos requiere una respuesta inmediata del consumidor de eventos, como obtener la idoneidad del cliente antes de continuar con un pedido. En una arquitectura controlada por eventos, la comunicación sincrónica se puede lograr mediante la mensajería de solicitud-respuesta.

  Este patrón normalmente se implementa con dos colas: una cola de solicitudes y una cola de respuesta. El productor de eventos envía una solicitud asincrónica a una cola de solicitudes, pausa otras operaciones en esa tarea y espera una respuesta en la cola de respuestas. Este enfoque convierte eficazmente este patrón en un proceso sincrónico. A continuación, los consumidores de eventos procesan la solicitud y envían la respuesta a través de una cola de respuesta. Este enfoque suele usar un identificador de sesión para el seguimiento, por lo que el productor de eventos sabe qué mensaje de la cola de respuesta está relacionado con la solicitud específica. La solicitud original también puede especificar el nombre de la cola de respuesta, potencialmente efímera, en un encabezado de respuesta u otro atributo personalizado mutuamente acordado.

• Mantenimiento del número adecuado de eventos.

  La generación de un número excesivo de eventos específicos puede saturar y sobrecargar el sistema, lo que dificulta el análisis eficaz del flujo global de eventos. Este problema se agrava cuando es necesario revertir los cambios. Por el contrario, la consolidación excesiva de eventos también puede crear problemas, lo que da lugar a un procesamiento y respuesta innecesarios de los consumidores de eventos.

  Para lograr el equilibrio adecuado, tenga en cuenta las consecuencias de los eventos y si los consumidores necesitan inspeccionar las cargas de eventos para determinar sus respuestas. Por ejemplo, si tiene un componente de comprobación de cumplimiento, podría ser suficiente publicar solo dos tipos de eventos: compatibles y no compatibles. Este enfoque ayuda a garantizar que solo los consumidores pertinentes procesen cada evento, lo que impide el procesamiento innecesario.

Otras consideraciones

• La cantidad de datos que se va a incluir en un evento puede ser una consideración importante que afecta al rendimiento y los costos. Puede simplificar el código de procesamiento y eliminar búsquedas adicionales colocando toda la información pertinente necesaria para su procesamiento directamente en el evento. Cuando se agrega solo una cantidad mínima de información a un evento, como algunos identificadores, se reduce el tiempo de transporte y el costo. Sin embargo, este enfoque requiere el código de procesamiento para recuperar cualquier información adicional que necesite. Para obtener más información, consulta Poner tus eventos en una dieta.

• Una solicitud solo es visible para el componente de control de solicitudes. Sin embargo, los eventos a menudo son visibles para varios componentes de una carga de trabajo, incluso si esos componentes no están diseñados para consumirlos o no. Para operar con una mentalidad de "asumir vulneración", tenga en cuenta la información que se incluye en eventos para evitar la exposición de información no deseada.

• Muchas aplicaciones usan la arquitectura controlada por eventos como su arquitectura principal. Puede combinar este enfoque con otros estilos arquitectónicos para crear una arquitectura híbrida. Las combinaciones típicas incluyen microservicios y canalizaciones y filtros. Integre la arquitectura controlada por eventos para mejorar el rendimiento del sistema mediante la eliminación de cuellos de botella y la represión durante grandes volúmenes de solicitudes.

• Los dominios específicos suelen abarcar varios productores de eventos, consumidores o canales de eventos. Los cambios en un dominio determinado pueden afectar a muchos componentes.

Recursos relacionados

• Vídeo de discusión de la Comunidad sobre las consideraciones de elección entre coreografía y orquestación.

Una arquitectura controlada por eventos consta de productores de eventos que generan una secuencia de eventos, consumidores de eventos que escuchan estos eventos y canales de eventos que transfieren eventos de productores a consumidores.

Los eventos se entregan casi en tiempo real, de modo que los consumidores pueden responder inmediatamente a los eventos cuando se producen. Los productores se desacoplan de los consumidores: un productor no sabe qué consumidores están escuchando. Los consumidores también se desconectan entre sí, y cada consumidor ve todos los eventos. Este proceso difiere de un patrón de consumidores competidores en el que los consumidores extraen mensajes de una cola y un mensaje solo se procesa una vez, suponiendo que no haya errores. En algunos sistemas, como Azure Internet de las cosas (IoT), los eventos deben ingerirse en grandes volúmenes.

Una arquitectura controlada por eventos puede usar un modelo de publicación y suscripción o un modelo de flujo de eventos.

• Pub/sub: La infraestructura de mensajería publish-subscribe realiza un seguimiento de las suscripciones. Cuando se publica un evento, se envía el evento a cada suscriptor. No se puede reproducir un evento después de recibirlo y los nuevos suscriptores no ven el evento.

• Streaming de eventos: Los eventos se escriben en un registro. Los eventos se ordenan estrictamente dentro de una partición y son duraderos. Los clientes no se suscriben a la secuencia. En su lugar, un cliente puede leer desde cualquier parte de la secuencia. El cliente es responsable de avanzar su posición en la secuencia. Esto significa que un cliente puede unirse en cualquier momento y puede reproducir eventos.

En el lado del consumidor, hay algunas variaciones comunes:

• Procesamiento de eventos simple: Un evento desencadena inmediatamente una acción en el consumidor. Por ejemplo, puede usar Azure Functions con un desencadenador de Azure Service Bus para que una función se ejecute cada vez que se publique un mensaje en un tema de Service Bus.

• Correlación de eventos básica: Un consumidor procesa algunos eventos empresariales discretos, los correlaciona por algún identificador y conserva la información de eventos anteriores para su uso al procesar eventos posteriores. Las bibliotecas como NServiceBus y MassTransit admiten este patrón.

• Procesamiento de eventos complejos: Un consumidor usa una tecnología como Azure Stream Analytics para analizar una serie de eventos e identificar patrones en los datos de eventos. Por ejemplo, puede agregar lecturas desde un dispositivo incrustado a lo largo de un período de tiempo y generar una notificación si la media móvil cruza un umbral determinado.

• Procesamiento del flujo de eventos: Use una plataforma de streaming de datos, como Azure IoT Hub o Apache Kafka, como una canalización para ingerir eventos y alimentarlos a los procesadores de flujos. Los procesadores de flujos sirven para procesar o transformar el flujo. Puede haber varios procesadores de flujo para distintos subsistemas de la aplicación. Este enfoque es una buena opción para las cargas de trabajo de IoT.

El origen de los eventos puede ser externo al sistema, como los dispositivos físicos de una solución de IoT. En ese caso, el sistema debe poder ingerir los datos en el volumen y el rendimiento que requiere el origen de datos.

Hay dos enfoques principales para estructurar cargas de eventos. Cuando tenga control sobre los consumidores de eventos, puede decidir la estructura de carga de cada consumidor. Esta estrategia permite mezclar enfoques según sea necesario dentro de una sola carga de trabajo.

• Incluya todos los atributos necesarios en la carga: Use este enfoque cuando quiera que los consumidores tengan toda la información disponible sin necesidad de consultar un origen de datos externo. Sin embargo, puede provocar problemas de coherencia de datos debido a varios sistemas de registro, especialmente después de las actualizaciones. La administración de contratos y el control de versiones también pueden ser complejas.

• Incluya solo claves en la carga: En este enfoque, los consumidores recuperan los atributos necesarios, como una clave principal, para capturar de forma independiente los datos restantes de un origen de datos. Este método proporciona una mejor coherencia de los datos porque tiene un único sistema de registros. Sin embargo, puede tener un rendimiento más deficiente que el primer enfoque porque los consumidores deben consultar el origen de datos con frecuencia. Tiene menos preocupaciones sobre el acoplamiento, el ancho de banda, la administración de contratos o el control de versiones porque los eventos más pequeños y los contratos más sencillos reducen la complejidad.

En el diagrama anterior, cada tipo de consumidor se muestra como un único cuadro. Para evitar que el consumidor se convierta en un único punto de error en el sistema, es habitual tener varias instancias de un consumidor. Es posible que también se necesiten varias instancias para controlar el volumen y la frecuencia de los eventos. Un único consumidor puede procesar eventos en varios subprocesos. Esta configuración puede crear desafíos si los eventos se deben procesar en orden o requieren una semántica exactamente una vez. Para obtener más información, vea Minimizar la coordinación.

Hay dos topologías principales en muchas arquitecturas controladas por eventos:

• Topología de agente: Los componentes difunden repeticiones como eventos en todo el sistema. Otros componentes actúan en el evento o omiten el evento. Esta topología es útil cuando el flujo de procesamiento de eventos es relativamente sencillo. No hay coordinación central ni orquestación, por lo que esta topología puede ser dinámica. Esta topología está muy desacoplada, lo que ayuda a proporcionar escalabilidad, capacidad de respuesta y tolerancia a errores de componentes. Ningún componente posee o conoce el estado de ninguna transacción empresarial de varios pasos y las acciones se realizan de forma asincrónica. Posteriormente, las transacciones distribuidas son arriesgadas porque no hay ninguna manera nativa de reiniciarse o reproducirse. Debe tener en cuenta cuidadosamente las estrategias de control de errores y intervención manual, ya que esta topología puede ser un origen de incoherencia de datos.

• Topología del mediador: Esta topología aborda algunas de las deficiencias de la topología de agente. Hay un mediador de eventos que administra y controla el flujo de eventos. El mediador de eventos mantiene el estado y administra las funcionalidades de control y reinicio de errores. A diferencia de la topología del agente, en esta topología, los componentes difunden repeticiones como comandos y solo a canales designados. Estos canales suelen ser colas de mensajes. Se espera que los consumidores procesen estos comandos. Esta topología proporciona más control, mejor control de errores distribuidos y posiblemente una mejor coherencia de los datos. Esta topología introduce un mayor acoplamiento entre los componentes y el mediador de eventos puede convertirse en un cuello de botella o un problema de confiabilidad.

Cuándo utilizar esta arquitectura

Debe usar esta arquitectura cuando:

• Varios subsistemas deben procesar los mismos eventos.
• Se requiere el procesamiento en tiempo real con un retraso de tiempo mínimo.
• Se requiere procesamiento de eventos complejos, como la coincidencia de patrones o la agregación a lo largo del tiempo.
• Se requiere un gran volumen y una alta velocidad de los datos, como con, por ejemplo, IoT.

Ventajas

Las ventajas de esta arquitectura son:

• Se desvinculan productores y consumidores.
• No existen integraciones de punto a punto. Es fácil agregar nuevos consumidores al sistema.
• Los consumidores pueden responder a eventos inmediatamente a medida que se producen.
• Altamente escalable, elástico y distribuido.
• Los subsistemas tienen vistas independientes del flujo de eventos.

Desafíos

• Entrega garantizada.

  En algunos sistemas, especialmente en escenarios de IoT, es fundamental garantizar la entrega de los eventos.

• Procesamiento de eventos en orden o exactamente una vez.

  Para lograr resistencia y escalabilidad, cada tipo de consumidor normalmente se ejecuta en varias instancias. Este proceso puede crear un desafío si los eventos deben procesarse en orden dentro de un tipo de consumidor o si no se implementa la lógica de procesamiento de mensajes idempotentes .

• Coordinación de mensajes entre servicios.

  Los procesos empresariales suelen tener varios servicios que publican y se suscriben a mensajes para lograr un resultado coherente en toda una carga de trabajo. Puede usar patrones de flujo de trabajo como el patrón coreográfico y la orquestación saga para administrar de forma confiable los flujos de mensajes en varios servicios.

• Control de errores.

  La arquitectura controlada por eventos usa principalmente la comunicación asincrónica. Un desafío con la comunicación asincrónica es el control de errores. Una manera de solucionar este problema es usar un procesador de controlador de errores independiente. Cuando el consumidor de eventos experimenta un error, envía inmediatamente y asincrónicamente el evento erróneo al procesador del controlador de errores y se mueve. El procesador del controlador de errores intenta corregir el error y devuelve el evento al canal de ingesta original. Pero si se produce un error en el procesador del controlador de errores, puede enviar el evento erróneo a un administrador para su posterior inspección. Si usa un procesador de controladores de errores, los eventos erróneos se procesan fuera de secuencia cuando se envían.

• Pérdida de datos.

  Otro desafío con la comunicación asincrónica es la pérdida de datos. Si alguno de los componentes se bloquea antes de procesar y entregar correctamente el evento a su siguiente componente, el evento se quita y nunca lo convierte en el destino final. Para minimizar la posibilidad de pérdida de datos, conserve los eventos en tránsito y quite o quite los eventos solo cuando el siguiente componente confirme la recepción del evento. Estas características se conocen como el modo de confirmación de cliente y la última compatibilidad con los participantes.

• Implementación de un patrón tradicional de solicitud-respuesta.

  A veces, el productor de eventos requiere una respuesta inmediata del consumidor de eventos, como obtener la idoneidad del cliente antes de continuar con un pedido. En una arquitectura controlada por eventos, la comunicación sincrónica se puede lograr mediante la mensajería de solicitud-respuesta.

  Este patrón normalmente se implementa con dos colas: una cola de solicitudes y una cola de respuesta. El productor de eventos envía una solicitud asincrónica a una cola de solicitudes, pausa otras operaciones en esa tarea y espera una respuesta en la cola de respuestas. Este enfoque convierte eficazmente este patrón en un proceso sincrónico. A continuación, los consumidores de eventos procesan la solicitud y envían la respuesta a través de una cola de respuesta. Este enfoque suele usar un identificador de sesión para el seguimiento, por lo que el productor de eventos sabe qué mensaje de la cola de respuesta está relacionado con la solicitud específica. La solicitud original también puede especificar el nombre de la cola de respuesta, potencialmente efímera, en un encabezado de respuesta u otro atributo personalizado mutuamente acordado.

• Mantenimiento del número adecuado de eventos.

  La generación de un número excesivo de eventos específicos puede saturar y sobrecargar el sistema, lo que dificulta el análisis eficaz del flujo global de eventos. Este problema se agrava cuando es necesario revertir los cambios. Por el contrario, la consolidación excesiva de eventos también puede crear problemas, lo que da lugar a un procesamiento y respuesta innecesarios de los consumidores de eventos.

  Para lograr el equilibrio adecuado, tenga en cuenta las consecuencias de los eventos y si los consumidores necesitan inspeccionar las cargas de eventos para determinar sus respuestas. Por ejemplo, si tiene un componente de comprobación de cumplimiento, podría ser suficiente publicar solo dos tipos de eventos: compatibles y no compatibles. Este enfoque ayuda a garantizar que solo los consumidores pertinentes procesen cada evento, lo que impide el procesamiento innecesario.

Otras consideraciones

• La cantidad de datos que se va a incluir en un evento puede ser una consideración importante que afecta al rendimiento y los costos. Puede simplificar el código de procesamiento y eliminar búsquedas adicionales colocando toda la información pertinente necesaria para su procesamiento directamente en el evento. Cuando se agrega solo una cantidad mínima de información a un evento, como algunos identificadores, se reduce el tiempo de transporte y el costo. Sin embargo, este enfoque requiere el código de procesamiento para recuperar cualquier información adicional que necesite. Para obtener más información, consulta Poner tus eventos en una dieta.

• Una solicitud solo es visible para el componente de control de solicitudes. Sin embargo, los eventos a menudo son visibles para varios componentes de una carga de trabajo, incluso si esos componentes no están diseñados para consumirlos o no. Para operar con una mentalidad de "asumir vulneración", tenga en cuenta la información que se incluye en eventos para evitar la exposición de información no deseada.

• Muchas aplicaciones usan la arquitectura controlada por eventos como su arquitectura principal. Puede combinar este enfoque con otros estilos arquitectónicos para crear una arquitectura híbrida. Las combinaciones típicas incluyen microservicios y canalizaciones y filtros. Integre la arquitectura controlada por eventos para mejorar el rendimiento del sistema mediante la eliminación de cuellos de botella y la represión durante grandes volúmenes de solicitudes.

• Los dominios específicos suelen abarcar varios productores de eventos, consumidores o canales de eventos. Los cambios en un dominio determinado pueden afectar a muchos componentes.

Recursos relacionados

• Vídeo de discusión de la Comunidad sobre las consideraciones de elección entre coreografía y orquestación.