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.