Prácticas recomendadas para la arquitectura de microservicios basada en eventos

Si es un arquitecto empresarial, probablemente haya oído hablar de una arquitectura de microservicios y haya trabajado con ella. Y si bien es posible que haya utilizado REST como su capa de comunicaciones de servicio en el pasado, cada vez más proyectos se están moviendo hacia una arquitectura basada en eventos. Analicemos los pros y los contras de esta popular arquitectura, algunas de las opciones de diseño clave que implica y los antipatrones comunes.

¿Qué es la arquitectura de microservicios basada en eventos?

En la arquitectura basada en eventos, cuando un servicio realiza algún trabajo que podría interesar a otros servicios, ese servicio produce un evento , un registro de la acción realizada. Otros servicios consumen esos eventos para que puedan realizar cualquiera de sus propias tareas necesarias como resultado del evento. A diferencia de REST, los servicios que crean solicitudes no necesitan conocer los detalles de los servicios que consumen las solicitudes.

Aquí hay un ejemplo simple: cuando se realiza un pedido en un sitio de comercio electrónico, se produce un solo evento de "pedido realizado" y luego lo consumen varios microservicios:

1. el servicio de pedidos que podría escribir un registro de pedidos en la base de datos
2. el servicio de atención al cliente que podría crear el registro del cliente , y
3. el servicio de pago que podría procesar el pago.

Los eventos se pueden publicar de varias formas. Por ejemplo, se pueden publicar en una cola que garantiza la entrega del evento a los consumidores apropiados, o se pueden publicar en un flujo de modelo "pub/sub" que publica el evento y permite el acceso a todas las partes interesadas. En cualquier caso, el productor publica el evento y el consumidor lo recibe, reaccionando en consecuencia. Tenga en cuenta que, en algunos casos, estos dos actores también pueden denominarse editor (el productor) y suscriptor (el consumidor).

Por qué usar la arquitectura basada en eventos

Una arquitectura basada en eventos ofrece varias ventajas sobre REST, que incluyen:

• Asíncrono : las arquitecturas basadas en eventos son asíncronas sin bloqueo. Esto permite que los recursos se muevan libremente a la siguiente tarea una vez que se complete su unidad de trabajo, sin preocuparse por lo que sucedió antes o lo que sucederá a continuación. También permiten que los eventos se pongan en cola o se almacenen en búfer, lo que evita que los consumidores vuelvan a presionar a los productores o los bloqueen.
• Acoplamiento suelto : los servicios no necesitan (y no deberían tener) conocimiento o dependencias de otros servicios. Cuando se utilizan eventos, los servicios funcionan de forma independiente, sin conocimiento de otros servicios, incluidos los detalles de implementación y el protocolo de transporte. Los servicios bajo un modelo de eventos se pueden actualizar, probar e implementar de forma independiente y más fácil.
• Fácil escalado : dado que los servicios están desacoplados bajo una arquitectura basada en eventos, y como los servicios generalmente realizan solo una tarea, rastrear los cuellos de botella en un servicio específico y escalar ese servicio (y solo ese servicio) se vuelve fácil.
• Soporte de recuperación: una arquitectura basada en eventos con una cola puede recuperar el trabajo perdido "reproduciendo" eventos del pasado. Esto puede ser valioso para evitar la pérdida de datos cuando un consumidor necesita recuperarlos.

Por supuesto, las arquitecturas basadas en eventos también tienen inconvenientes. Son fáciles de sobrediseñar al separar preocupaciones que podrían ser más simples cuando están estrechamente acopladas; puede requerir una inversión inicial significativa; y, a menudo, dan como resultado una complejidad adicional en la infraestructura, los contratos o esquemas de servicio, los sistemas de compilación políglotas y los gráficos de dependencia.

Quizás el inconveniente y desafío más importante es la gestión de datos y transacciones. Debido a su naturaleza asíncrona, los modelos basados en eventos deben manejar con cuidado los datos inconsistentes entre los servicios, las versiones incompatibles, vigilar los eventos duplicados y, por lo general, no admiten transacciones ACID, sino que admiten la coherencia final que puede ser más difícil de rastrear o depurar.

Incluso con estos inconvenientes, una arquitectura basada en eventos suele ser la mejor opción para los sistemas de microservicios de nivel empresarial. Los pros (diseño escalable, débilmente acoplado y compatible con operaciones de desarrollo) superan los contras.

Cuándo usar DESCANSO

Sin embargo, hay momentos en los que una interfaz REST/web aún puede ser preferible:

• Necesita una interfaz de solicitud/respuesta con límite de tiempo
• Soporte conveniente para transacciones
• Su API está disponible para el público
• Su proyecto es pequeño (REST es mucho más simple de configurar e implementar)

Su elección de diseño más importante: marco de mensajería

Una vez que se haya decidido por una arquitectura basada en eventos, es hora de elegir su marco de eventos. La forma en que se producen y consumen sus eventos es un factor clave en su sistema. Existen docenas de marcos y opciones comprobados, y elegir el correcto requiere tiempo e investigación.

Su elección básica se reduce al procesamiento de mensajes o al procesamiento de secuencias.

Procesamiento de mensajes

En el procesamiento de mensajes tradicional, un componente crea un mensaje y luego lo envía a un destino específico (y generalmente único). El componente receptor, que ha estado inactivo y esperando, recibe el mensaje y actúa en consecuencia. Normalmente, cuando llega el mensaje, el componente receptor realiza un solo proceso. Luego, el mensaje se elimina.

Un ejemplo típico de una arquitectura de procesamiento de mensajes es una cola de mensajes. Aunque la mayoría de los proyectos más nuevos utilizan el procesamiento de secuencias (como se describe a continuación), las arquitecturas que utilizan colas de mensajes (o eventos) siguen siendo populares. Las colas de mensajes suelen utilizar un sistema de intermediarios de "almacenamiento y reenvío" en el que los eventos viajan de un intermediario a otro hasta que llegan al consumidor apropiado. ActiveMQ y RabbitMQ son dos ejemplos populares de marcos de cola de mensajes. Ambos proyectos tienen años de uso comprobado y comunidades establecidas.

Procesamiento de flujo

Por otro lado, en el procesamiento de flujos, los componentes emiten eventos cuando alcanzan un determinado estado. Otros componentes interesados escuchan estos eventos en el flujo de eventos y reaccionan en consecuencia. Los eventos no están dirigidos a un determinado destinatario, sino que están disponibles para todos los componentes interesados.

En el procesamiento de flujos, los componentes pueden reaccionar a múltiples eventos al mismo tiempo y aplicar operaciones complejas en múltiples flujos y eventos. Algunas transmisiones incluyen persistencia donde los eventos permanecen en la transmisión durante el tiempo que sea necesario.

Con el procesamiento de flujo, un sistema puede reproducir un historial de eventos, conectarse después de que ocurrió el evento y aun así reaccionar ante él, e incluso realizar cálculos de ventana deslizante. Por ejemplo, podría calcular el uso promedio de la CPU por minuto a partir de una secuencia de eventos por segundo.

Uno de los marcos de procesamiento de flujo más populares es Apache Kafka . Kafka es una solución madura y estable utilizada por muchos proyectos. Se puede considerar una solución de procesamiento de flujo de potencia industrial. Kafka tiene una gran base de usuarios, una comunidad útil y un conjunto de herramientas evolucionado.

Otras opciones

Hay otros marcos que ofrecen una combinación de flujo y procesamiento de mensajes o su propia solución única. Por ejemplo, Pulsar , una oferta más reciente de Apache, es un sistema de mensajería pub/sub de código abierto que admite flujos y colas de eventos, todo con un rendimiento extremadamente alto. Pulsar tiene muchas funciones (ofrece múltiples inquilinos y replicación geográfica) y, en consecuencia, es complejo. Se ha dicho que Kafka apunta a un alto rendimiento, mientras que Pulsar apunta a una baja latencia.

NATS es un sistema de mensajería pub/sub alternativo con colas "sintéticas". NATS está diseñado para enviar mensajes pequeños y frecuentes. Ofrece alto rendimiento y baja latencia. Sin embargo, NATS considera que cierto nivel de pérdida de datos es aceptable, priorizando el rendimiento sobre las garantías de entrega.

Otras consideraciones de diseño

Una vez que haya seleccionado el marco de su evento, aquí hay varios otros desafíos a considerar:

Abastecimiento de eventos

Es difícil implementar una combinación de servicios débilmente acoplados, almacenes de datos distintos y transacciones atómicas. Un patrón que puede ayudar es Event Sourcing . En Event Sourcing, las actualizaciones y eliminaciones nunca se realizan directamente en los datos; más bien, los cambios de estado de una entidad se guardan como una serie de eventos.

CQRS

El abastecimiento de eventos anterior presenta otro problema: dado que el estado debe construirse a partir de una serie de eventos, las consultas pueden ser lentas y complejas. Command Query Responsibility Segregation ( CQRS ) es una solución de diseño que requiere modelos separados para operaciones de inserción y operaciones de lectura.

Descubrimiento de información de eventos

Uno de los mayores desafíos en la arquitectura basada en eventos es la catalogación de servicios y eventos. ¿Dónde se encuentran las descripciones y los detalles de los eventos? ¿Cuál es el motivo de un evento? ¿Qué equipo creó el evento? ¿Están trabajando activamente en ello?

Lidiando con el cambio

¿Cambiará el esquema de un evento? ¿Cómo cambia un esquema de evento sin romper otros servicios? La forma en que responda estas preguntas se vuelve crítica a medida que crece su número de servicios y eventos.

Ser un buen consumidor de eventos significa codificar esquemas que cambian. Ser un buen productor de eventos significa ser consciente de cómo los cambios de su esquema afectan a otros servicios y crear eventos bien diseñados que estén claramente documentados.

Implementación en las instalaciones frente a hospedada

Independientemente de su marco de eventos, también deberá decidir entre implementar el marco usted mismo en las instalaciones (los intermediarios de mensajes no son triviales para operar, especialmente con alta disponibilidad), o usar un servicio alojado como Apache Kafka en Heroku .

Antipatrones

Como ocurre con la mayoría de las arquitecturas, una arquitectura basada en eventos viene con su propio conjunto de antipatrones. Aquí hay algunos a tener en cuenta.

Demasiado de una cosa buena

Tenga cuidado de no entusiasmarse demasiado con la creación de eventos. La creación de demasiados eventos creará una complejidad innecesaria entre los servicios, aumentará la carga cognitiva para los desarrolladores, dificultará la implementación y las pruebas y causará congestión para los consumidores de eventos. No todos los métodos tienen que ser un evento.

Eventos genéricos

No use eventos genéricos, ya sea en el nombre o en el propósito. Desea que otros equipos entiendan por qué existe su evento, para qué debe usarse y cuándo debe usarse. Los eventos deben tener un propósito específico y ser nombrados en consecuencia. Los eventos con nombres genéricos o eventos genéricos con banderas confusas causan problemas.

Gráficos de dependencia complejos

Tenga cuidado con los servicios que dependen unos de otros y crean gráficos de dependencia complejos o ciclos de retroalimentación. Cada salto de red agrega latencia adicional a la solicitud original, particularmente el tráfico de red norte/sur que sale del centro de datos.

Según el pedido garantizado, la entrega o los efectos secundarios

Los eventos son asincrónicos; por lo tanto, incluir suposiciones de orden o duplicados no solo agregará complejidad sino que anulará muchos de los beneficios clave de la arquitectura basada en eventos. Si su consumidor tiene efectos secundarios, como agregar un valor en una base de datos, es posible que no pueda recuperarse reproduciendo eventos.

Optimización prematura

La mayoría de los productos comienzan pequeños y crecen con el tiempo. Si bien puede soñar con necesidades futuras para escalar a una organización grande y compleja, si su equipo es pequeño, la complejidad adicional de las arquitecturas basadas en eventos puede en realidad ralentizarlo. En su lugar, considere diseñar su sistema con una arquitectura simple pero incluya la necesaria separación de preocupaciones para que pueda cambiarlo a medida que crezcan sus necesidades.

Esperar que los eventos lo solucionen todo

En un nivel menos técnico, no espere que la arquitectura basada en eventos solucione todos sus problemas. Si bien esta arquitectura ciertamente puede mejorar muchas áreas de disfunción técnica, no puede solucionar problemas centrales, como la falta de pruebas automatizadas, la mala comunicación del equipo o las prácticas obsoletas de operaciones de desarrollo.

Aprende más

Comprender los pros y los contras de las arquitecturas basadas en eventos y algunas de sus decisiones y desafíos de diseño más comunes es una parte importante para crear el mejor diseño posible.

Si desea obtener más información, consulte esta arquitectura de referencia basada en eventos que creamos en Heroku, que le permite implementar un proyecto de trabajo en Heroku con un solo clic. Esta arquitectura de referencia crea una tienda web que vende productos de café ficticios.

Los clics en productos se rastrean como eventos y se almacenan en Kafka. Luego, son consumidos por un tablero de informes.

El código es de código abierto para que puedas modificarlo según tus necesidades y realizar tus propios experimentos.