Aunque me he encontrado con Kafka antes, recientemente me di cuenta de que Kafka quizás podría usarse como (la base de) un CQRS , tienda de eventos .

Uno de los puntos principales que admite Kafka:

• Captura / almacenamiento de eventos, todo HA, por supuesto.
• Pub / sub arquitectura
• Capacidad para reproducir el registro de eventos que permite a los nuevos suscriptores registrarse con el sistema después del hecho.

Es cierto que no estoy 100% versado en CQRS / fuente de eventos, pero esto parece bastante parecido a lo que debería ser un almacén de eventos. Lo curioso es que realmente no puedo encontrar tanto sobre el uso de Kafka como tienda de eventos, así que quizás me estoy perdiendo algo.

Entonces, ¿le falta algo a Kafka para que sea una buena tienda de eventos? ¿Funcionaría? ¿Usándolo en producción? Interesado en información, enlaces, etc.

Básicamente, el estado del sistema se guarda en función de las transacciones / eventos que el sistema ha recibido, en lugar de simplemente guardar el estado / instantánea actual del sistema, que es lo que generalmente se hace. (Piense en ello como un libro mayor en contabilidad: todas las transacciones finalmente se suman al estado final) Esto permite todo tipo de cosas interesantes, pero solo lea en los enlaces provistos.

Kafka está destinado a ser un sistema de mensajería que tiene muchas similitudes con una tienda de eventos, sin embargo, para citar su introducción:

El clúster Kafka retiene todos los mensajes publicados, se hayan consumido o no, durante un período de tiempo configurable . Por ejemplo, si la retención se establece durante dos días, los dos días posteriores a la publicación de un mensaje estarán disponibles para el consumo, luego de lo cual se descartarán para liberar espacio. El rendimiento de Kafka es efectivamente constante con respecto al tamaño de los datos, por lo que retener muchos datos no es un problema.

Entonces, si bien los mensajes pueden retenerse indefinidamente, la expectativa es que se eliminarán. Esto no significa que no pueda usar esto como una tienda de eventos, pero puede ser mejor usar otra cosa. Echa un vistazo a EventStore para una alternativa.

ACTUALIZAR

Documentación de Kafka :

El abastecimiento de eventos es un estilo de diseño de aplicaciones donde los cambios de estado se registran como una secuencia de registros ordenada por tiempo. El soporte de Kafka para datos de registro almacenados muy grandes lo convierte en un excelente back-end para una aplicación construida en este estilo.

ACTUALIZACIÓN 2

Una preocupación con el uso de Kafka para el abastecimiento de eventos es la cantidad de temas requeridos. Por lo general, en el abastecimiento de eventos, hay una secuencia (tema) de eventos por entidad (como usuario, producto, etc.). De esta manera, el estado actual de una entidad se puede reconstituir volviendo a aplicar todos los eventos en la secuencia. Cada tema de Kafka consta de una o más particiones y cada partición se almacena como un directorio en el sistema de archivos. También habrá presión de ZooKeeper a medida que aumente el número de znodes.

Soy uno de los autores originales de Kafka. Kafka funcionará muy bien como un registro para el abastecimiento de eventos. Es tolerante a fallas, escala a enormes tamaños de datos y tiene un modelo de particionamiento incorporado.

Lo usamos para varios casos de uso de este formulario en LinkedIn. Por ejemplo, nuestro sistema de procesamiento de flujo de código abierto, Apache Samza, viene con soporte incorporado para el abastecimiento de eventos.

Creo que no escuchas mucho sobre el uso de Kafka para el abastecimiento de eventos principalmente porque la terminología del abastecimiento de eventos no parece ser muy frecuente en el espacio web del consumidor donde Kafka es más popular.

He escrito un poco sobre este estilo de uso de Kafka aquí .

Sigo volviendo a este control de calidad. Y no encontré las respuestas existentes lo suficientemente matizadas, así que estoy agregando esta.

TL; DR. Sí o No, dependiendo del uso de su fuente de eventos.

Hay dos tipos principales de sistemas de origen de eventos que conozco.

Procesadores de eventos posteriores = Sí

En este tipo de sistema, los eventos ocurren en el mundo real y se registran como hechos. Tal como un sistema de almacén para realizar un seguimiento de las paletas de productos. Básicamente no hay eventos en conflicto. Todo ya ha sucedido, incluso si estuvo mal. (Es decir, el pallet 123456 se colocó en el camión A, pero estaba programado para el camión B.) Luego, se verifican las excepciones a través de mecanismos de informes. Kafka parece adecuado para este tipo de aplicación de procesamiento de eventos descendente.

En este contexto, es comprensible por qué la gente de Kafka lo defiende como una solución de Abastecimiento de eventos. Porque es bastante similar a cómo ya se usa, por ejemplo, en secuencias de clics. Sin embargo, las personas que usan el término Abastecimiento de eventos (a diferencia del procesamiento de flujo) probablemente se refieran al segundo uso ...

Fuente de verdad controlada por la aplicación = No

Este tipo de aplicación declara sus propios eventos como resultado de las solicitudes de los usuarios que pasan por la lógica empresarial. Kafka no funciona bien en este caso por dos razones principales.

Falta de aislamiento de la entidad.

Este escenario necesita la capacidad de cargar la secuencia de eventos para una entidad específica. La razón común para esto es construir un modelo de escritura transitoria para que la lógica de negocios utilice para procesar la solicitud. Hacer esto no es práctico en Kafka. El uso de tema por entidad podría permitir esto, excepto que esto no es un comienzo cuando puede haber miles o millones de entidades. Esto se debe a límites técnicos en Kafka / Zookeeper.

Una de las principales razones para utilizar un modelo de escritura transitoria de esta manera es hacer que los cambios en la lógica de negocios sean baratos y fáciles de implementar.

En su lugar, se recomienda el uso de tema por tipo para Kafka, pero esto requeriría cargar eventos para cada entidad de ese tipo solo para obtener eventos para una sola entidad. Como no puede determinar por posición de registro qué eventos pertenecen a qué entidad. Incluso usando Instantáneas para comenzar desde una posición de registro conocida, este podría ser un número significativo de eventos para pasar.

Falta de detección de conflictos

En segundo lugar, los usuarios pueden crear condiciones de carrera debido a solicitudes concurrentes contra la misma entidad. Puede ser bastante indeseable guardar eventos en conflicto y resolverlos después del hecho. Por lo tanto, es importante poder prevenir eventos conflictivos. Para escalar la carga de solicitudes, es común usar servicios sin estado mientras se evitan conflictos de escritura usando escrituras condicionales (solo escriba si el último evento de entidad fue #x). Aka concurrencia optimista. Kafka no admite simultaneidad optimista. Incluso si lo apoyara a nivel de tema, tendría que estar todo el camino hasta el nivel de entidad para ser efectivo. Para usar Kafka y evitar eventos conflictivos, necesitaría usar un escritor con estado y serializado a nivel de aplicación. Este es un requisito / restricción arquitectónica importante.

Más información

Actualización por comentario

El comentario se ha eliminado, pero la pregunta era algo así como: ¿qué utilizan las personas para el almacenamiento de eventos?

Parece que la mayoría de las personas implementa su propia implementación de almacenamiento de eventos sobre una base de datos existente. Para escenarios no distribuidos, como productos internos o productos independientes, está bien documentado cómo crear un almacén de eventos basado en SQL. Y hay bibliotecas disponibles sobre una base de datos de varios tipos. También está EventStore , que está diseñado para este propósito.

En escenarios distribuidos, he visto un par de implementaciones diferentes. El proyecto Jet's Panther usa Azure CosmosDB , con la función Cambiar fuente para notificar a los oyentes. Otra implementación similar de la que he oído hablar en AWS es usar DynamoDB con su función Streams para notificar a los oyentes. La clave de partición probablemente debería ser la identificación del flujo para la mejor distribución de datos (para disminuir la cantidad de sobreaprovisionamiento). Sin embargo, una reproducción completa a través de transmisiones en Dynamo es costosa (lectura y costo). Por lo tanto, este impl también se configuró para Dynamo Streams para volcar eventos en S3. Cuando un nuevo oyente se conecta, o un oyente existente quiere una repetición completa, leería S3 para ponerse al día primero.

Mi proyecto actual es un escenario multiinquilino, y rodé el mío sobre Postgres. Algo parecido a Citus parece apropiado para la escalabilidad, partición por tentant + stream.

Kafka sigue siendo muy útil en escenarios distribuidos. Es un problema no trivial exponer los eventos de cada servicio a otros servicios. Por lo general, no se crea una tienda de eventos para eso, pero eso es precisamente lo que Kafka hace bien. Cada servicio tiene su propia fuente interna de verdad (podría ser el almacenamiento de eventos o no), pero escucha a Kafka para saber qué está sucediendo "afuera". El servicio también puede publicar eventos en Kafka para informar al "exterior" de cosas interesantes que hizo el servicio.

Puede usar Kafka como tienda de eventos, pero no recomiendo hacerlo, aunque podría parecer una buena opción:

• Kafka solo garantiza al menos una vez la entrega y hay duplicados en la tienda de eventos que no se pueden eliminar. Actualización: Aquí puede leer por qué es tan difícil con Kafka y algunas últimas noticias sobre cómo finalmente lograr este comportamiento: https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how -apache-kafka-does-it /
• Debido a la inmutabilidad, no hay forma de manipular el almacén de eventos cuando la aplicación evoluciona y los eventos deben transformarse (por supuesto, hay métodos como la transmisión, pero ...). Una vez podría decir que nunca necesita transformar eventos, pero eso no es una suposición correcta, podría haber una situación en la que haga una copia de seguridad del original, pero los actualice a las últimas versiones. Ese es un requisito válido en arquitecturas controladas por eventos.
• No hay lugar para persistir las instantáneas de entidades / agregados y la reproducción será cada vez más lenta. La creación de instantáneas debe presentarse para la tienda de eventos desde una perspectiva a largo plazo.
• Dado que las particiones Kafka se distribuyen y son difíciles de administrar y hacer copias de seguridad en comparación con las bases de datos. Las bases de datos son simplemente más simples :-)

Entonces, antes de hacer su elección, lo piensa dos veces. La tienda de eventos como combinación de interfaces de capa de aplicación (monitoreo y administración), la tienda SQL / NoSQL y Kafka como agente es la mejor opción que dejar que Kafka maneje ambas funciones para crear una solución completa de funciones completas.

La tienda de eventos es un servicio complejo que requiere más de lo que Kafka puede ofrecer si se toma en serio la aplicación de fuentes de eventos, CQRS, Sagas y otros patrones en la arquitectura impulsada por eventos y mantiene un alto rendimiento.

¡Siéntete libre de desafiar mi respuesta! Es posible que no le guste lo que digo sobre su corredor favorito con muchas capacidades superpuestas, pero aún así, Kafka no fue diseñado como tienda de eventos, sino más bien como corredor de alto rendimiento y amortiguador al mismo tiempo para manejar escenarios de productores rápidos versus consumidores lentos, por ejemplo.

Consulte el marco de código abierto de microservicios eventuate.io para descubrir más sobre los posibles problemas: http://eventuate.io/

Actualización a partir del 8 de febrero de 2018

No incorporo nueva información de los comentarios, pero estoy de acuerdo con algunos de esos aspectos. Esta actualización trata más sobre algunas recomendaciones para la plataforma basada en eventos de microservicios. Si se toma en serio el diseño robusto de microservicios y el mayor rendimiento posible en general, le proporcionaré algunas sugerencias que podrían interesarle.

1. No use Spring, es genial (lo uso mucho), pero es pesado y lento al mismo tiempo. Y no es una plataforma de microservicio en absoluto. Es "solo" un marco para ayudarlo a implementar uno (mucho trabajo detrás de esto ...). Otros marcos son "simplemente" REST o JPA livianos o marcos enfocados de manera diferente. Recomiendo probablemente la mejor plataforma de microservicio de código abierto disponible en su clase que vuelve a las raíces puras de Java: https://github.com/networknt

Si se pregunta sobre el rendimiento, puede compararse con el conjunto de pruebas de referencia existente. https://github.com/networknt/microservices-framework-benchmark

2. No uses Kafka en absoluto :-)) Es una broma a medias. Quiero decir que si bien Kafka es genial, es otro sistema centrado en corredores. Creo que el futuro está en los sistemas de mensajería sin intermediario. Puede que se sorprenda, pero hay sistemas más rápidos que Kafka :-), por supuesto, debe bajar al nivel inferior. Mira la crónica.

3. Para la tienda de eventos, recomiendo la extensión superior Postgresql llamada TimescaleDB, que se centra en el procesamiento de datos de series de tiempo de alto rendimiento (los eventos son series de tiempo) en gran volumen. Por supuesto, CQRS, el abastecimiento de eventos (funciones de repetición, etc.) se integran en light4j framework fuera de la caja que usa Postgres como poco almacenamiento.

4. Para la mensajería intente mirar Chronicle Queue, Map, Engine, Network. Me refiero a deshacerse de estas antiguas soluciones centradas en corredores e ir con el sistema de micro mensajería (integrado). Chronicle Queue es incluso más rápido que Kafka. Pero estoy de acuerdo en que no es una solución todo en uno y que necesita hacer un desarrollo, de lo contrario, vaya y compre la versión Enterprise (de pago). Al final, el esfuerzo de construir desde Chronicle su propia capa de mensajería se pagará eliminando la carga de mantener el clúster de Kafka.

Sí, puedes usar Kafka como tienda de eventos. Funciona bastante bien, especialmente con la introducción de Kafka Streams , que proporciona una forma nativa de Kafka para procesar sus eventos en un estado acumulado que puede consultar .

Respecto a:

Capacidad para reproducir el registro de eventos que permite a los nuevos suscriptores registrarse con el sistema después del hecho.

Esto puede ser complicado. Cubrí eso en detalle aquí: https://stackoverflow.com/a/48482974/741970

Sí, Kafka funciona bien en el modelo de aprovisionamiento de eventos especialmente CQRS, sin embargo, debe tener cuidado al configurar TTL para los temas y siempre tenga en cuenta que Kafka no fue diseñado para este modelo, sin embargo, podemos usarlo muy bien.

Creo que deberías mirar axon framework junto con su soporte para Kafka