Header Ads Widget

Ticker

6/recent/ticker-posts

Uso de Apache Kafka para crear API flexibles (estudio de caso)

 


La construcción de grandes plataformas siempre ha sido difícil. Las aplicaciones monolíticas anticuadas están plagadas de ciclos de entrega lentos, confiabilidad cuestionable y complejidad seria. Por otro lado, el enfoque de microservicios tiene sus propias complejidades, como la superposición de servicios o las dependencias no deseadas. Pero, ¿qué pasaría si pudiera crear servicios acoplados libremente con un propósito comercial claro y sin límites para escalar?

En este artículo, analizamos cómo la empresa de transporte público noruego Entur está utilizando Kafka para construir una arquitectura de servicios escalables con dependencias mínimas y máxima flexibilidad.

Este artículo está basado en una charla de Henrik Stene de Aboveit en la Cumbre de la Plataforma de APIs nórdicas de 2019.

 

El objetivo: una arquitectura de acoplamiento flexible

Una parte fundamental del modelo comercial de Entur es su sistema unificado de venta y emisión de boletos, que permite a los clientes realizar reservas de boletos para casi todos los principales medios de transporte. La empresa deseaba construir este sistema como una colección de módulos de funciones y datos independientes , ofreciendo la flexibilidad de una arquitectura fina con una lógica empresarial clara.

Estos son solo algunos de los módulos de datos que eligieron:
payment
customer
order
product

Al minimizar la superposición de datos (y en su lugar, utilizar referencias entre módulos), cada módulo de datos puede tratarse como una única fuente de verdad para los datos disponibles, explica Henrik. Esto significa que todos los datos de los clientes se guardan en un solo lugar, lo que simplifica el cumplimiento de las regulaciones de protección de datos como GDPR.

Los módulos de función, como order historyreserve, combinan varios módulos de datos para cumplir una función empresarial específica. Por ejemplo, el order historymódulo de funciones combina datos de los módulos de datos customerorderpara generar una lista de los pedidos de un cliente determinado. El objetivo principal de esto es simplemente facilitar a los clientes la interacción con la API.

Por supuesto, es esencial que la información fluya entre estos módulos para que funcionen sin problemas. Entur no querría crear un nuevo ticket si el pedido no se hubiera confirmado, y no querría confirmar un pedido si no se hubiera pagado. Pero, ¿cómo permite que la información fluya entre estos módulos de datos sin crear dependencias?

Apache Kafka para la propagación de datos

Para facilitar la difusión de datos entre varios módulos, Entur optó por emplear Kafka . Esta plataforma de transmisión distribuida de alto rendimiento crea un "grupo" central de eventos, que las aplicaciones (en este caso, los módulos de datos y funciones) pueden escuchar e interactuar a voluntad.

La idea es sencilla. Cada uno de los módulos de Entur tiene un conjunto de eventos asociados. En cuanto al paymentmódulo de datos, los eventos incluyen la creación, finalización y cancelación de pagos, entre otros. Siempre que ocurre uno de estos eventos, los detalles relevantes se publican en el grupo de Kafka.

Mientras tanto, todos los módulos de funciones y datos están constantemente "escuchando" el registro de eventos en busca de eventos que puedan afectarlos. Por ejemplo, el ordermódulo puede escuchar eventos relacionados con el pago para que cuando se complete un pago, se pueda actualizar el estado del pedido.

“Cuando el módulo de pedido ha leído el evento“ Pago completado ”, puede reaccionar cambiando el estado del pedido. Pero un cambio en el estado del pedido es información que el módulo de tickets podría estar interesado en conocer. Entonces, el módulo de boletos, en este ejemplo, está escuchando un evento de "Pedido confirmado", porque le gustaría reaccionar a ese evento creando y habilitando el boleto para este pedido en particular ".

Características valiosas de Kafka

Además de permitir una comunicación fluida entre módulos separados, Kafka tiene al menos otras dos características que lo convierten en un punto de partida atractivo para su backend: una expansión sin problemas y un lenguaje de consulta integrado.

Expansión perfecta

Un gran beneficio de construir su backend alrededor de una plataforma de transmisión como Kafka es que puede agregar nuevas funciones sin problemas. Henrik da el ejemplo de un departamento de contabilidad que busca comenzar a rastrear las ventas: simplemente pueden crear su propio módulo que escuche el flujo de Kafka, sin tener que realizar ningún cambio en los módulos existentes.
Sin embargo, lo que es específico de Kafka es su capacidad para realizar un seguimiento de los eventos pasados. Esto significa que los nuevos módulos pueden leer cualquiera (y todos) los eventos que han ocurrido desde el inicio del clúster. Para algunos propósitos, esto no importará, pero para otros, es absolutamente esencial.

Lenguaje de consulta

Otra característica asombrosa de Kafka es su lenguaje de consulta dedicado, KSQL . Esto le permite escribir flujos de trabajo simples con increíble facilidad, que se pueden utilizar para procesar eventos entrantes en tiempo real. Henrik comparte el ejemplo de una consulta que identifica transacciones sospechosas (cuatro o más boletos comprados en cinco minutos) y los agrega a un flujo dedicado:

CREATE STREAM suspicious_sales AS
SELECT customer_id, count(*)
FROM order_confirmed
WINDOW TUMBLING (SIZE 10 MINUTE)
GROUP BY customer_id
HAVING count(*) > 4

Bono: una corriente de Kafka orientada al cliente

Como se demostró, Apache Kafka puede ser un excelente medio de comunicación para su ecosistema de servicios, ¡pero eso no es todo lo que puede hacer! En su presentación, Henrik menciona cómo puede exponer un flujo de Kafka orientado al cliente para proporcionar una especie de API asíncrona.

En el caso de Entur, esto significa copiar un puñado de eventos a un flujo externo de Kafka (si cumplen ciertas condiciones) para uso de socios / clientes. Por ejemplo, todos los eventos de "Pedido confirmado" se comparten con el flujo externo para que el operador de transporte público en cuestión pueda procesar inmediatamente la reserva.

La exposición de este flujo de eventos abre muchas posibilidades para la personalización de los socios. Como explica Henrik, permitir que los socios envíen sus propios correos electrónicos transaccionales de marca, que de otro modo podría ser una tarea complicada, es tan simple como exponer estos eventos al flujo externo y elegir no reaccionar a ellos internamente.

Conclusión

Cuando se trata de arquitecturas de plataforma, hay mucho más para elegir que solo microservicios. La charla de Henrik comparte una visión general de cómo Kafka puede facilitar la propagación de datos entre varios módulos de funciones y datos individuales, ofreciendo una plataforma escalable que es fácil de modificar e incluso más fácil de construir. Junto con sus potentes funciones, como la capacidad de leer eventos pasados ​​y un lenguaje de consulta dedicado, esto convierte a Kafka en una herramienta atractiva en el arsenal del arquitecto de servicios.

Publicar un comentario

0 Comentarios