Akka Persistence

Akka Persistencehabilita a los actores con estado a persistir su estado para que pueda ser recuperado cuando un actor se reinicie, como después de un JVM fallo, por un supervisor o un paro-arranque manual, o migrado dentro de un clúster. El concepto clave detrás de Akka Persistence es que solo se almacenan los eventos que son persistidos por el actor, no el estado actual del actor (aunque se dispone de soporte para instantáneas del estado del actor). Los eventos se persisten añadiendo a la almacenamiento (nada se muta nunca), lo que permite tasas de transacción muy altas y una replicación eficiente. Un actor con estado se recupera reproduciendo los eventos almacenados al actor, lo que le permite reconstruir su estado. Esto puede ser ya sea el historial completo de cambios o comenzando desde un punto de control en una instantánea, lo que puede reducir drásticamente los tiempos de recuperación.

Las secciones subyacentes a esta página contienen instrucciones sobre el uso de Akka Persistence dentro de IPF. El resto de esta página desglosa los conceptos y el significado de las palabras e ideas en el párrafo anterior.

Antecedentes

Eventssuceder en el pasado. Por ejemplo, "el pain. 001 "fue recibido", "la Cuenta fue Debitada", "el efectivo fue dispensado". Todos estos eventos se describen utilizando el tiempo pasado. Eventsson inmutables, esto significa que, dado que los eventos ocurren en el pasado, no pueden ser cambiados ni deshechos. Sin embargo, eventos posteriores pueden alterar o anular los efectos de eventos anteriores. Por ejemplo, "el débito fue cancelado" es un evento que cambia el resultado de un evento de débito anterior. En este caso, el evento de débito original aún existe, pero el segundo evento de cancelación cambia el estado general de la transacción en el sistema. El estado actual es la culminación de la secuencia de eventos que conducen a él.

Típicamente, los eventos incluyen parámetros que proporcionan información adicional sobre el evento. Por ejemplo, "La cuenta 12345678 fue debitada a través de un cheque."

Usando Event Suministro

Eventsourcing es una forma de conocer el estado de su aplicación al almacenar el historial de Events que conducen al momento actual en el tiempo. Por ejemplo, un sistema de pagos necesita rastrear el número de transacciones completadas a través de un método de pago para poder verificar si el valor total de un día determinado coincide con el que cita el esquema de pago. El sistema podría almacenar el número total de transacciones para un esquema de pago de dos maneras:

  • En un modelo tradicional de tipo "CRUD", se podría Crear un elemento de datos para almacenar el número total de transacciones para un esquema particular, luego Leer y Actualizar este número cada vez que alguien realice o cancele un pago antes de Eliminarlo cuando haya terminado con él. Puede pensar en el número de transacciones como un valor entero almacenado en una columna específica de una tabla que tiene una fila para cada sistema de pago utilizado por el banco.

  • En un Event El sistema de origen almacenará todas las transacciones y eventos de cancelación para cada esquema de pago y luego calculará el número actual de transacciones accediendo a los eventos relevantes asociados con el esquema para el cual usted desea verificar el número total actual de transacciones.

Agregados

Un agregado es un grupo de objetos de datos que pueden ser tratados como una única unidad para el propósito de cambios en los datos y Events. Cada agregado tiene una raíz y un límite. La raíz es el punto de entrada al agregado y se pasa como una referencia al grupo. El Límite limita el acceso a los objetos dentro del grupo. Cualquier cosa dentro del Límite puede acceder a cualquier otra cosa en el agregado, pero el acceso externo está limitado a través de la raíz. El proceso principal que utiliza el agregado se considera como el Dominio en el que vive el grupo.

En el ejemplo de un pacs. 008 En conjunto, el mensaje en sí sería un objeto de dominio, pero está compuesto por varios objetos de datos internos: El Deudor, El Acreedor, el valor y la moneda del pago, etc. Cada parte de los datos necesarios para el mensaje es una entidad. La raíz debe ser una única entidad específica en el agregado, por lo que esto podría, por ejemplo, ser el MessageId.

"The" pacs. 008 sometió a Verificación de Sanciones", sería un ejemplo de un Event dentro del ciclo de vida del agregado.

Actores

El Actor en un Event Un sistema impulsado puede ser considerado como la lógica de procesamiento de un sistema que está trabajando en un agregado y que facilita los eventos por los que transita.

Por ejemplo, un flujo de proceso IPF que decide si un pacs. 008 el agregado necesita su BIC de destino enriquecido, antes de ser enviado para verificaciones de sanciones y luego a un CSM servicio a ser enviado un customer en otro banco, puede considerarse como el Actor.

¿Por qué utilizamos event sourcing?

EventLa adquisición almacena un historial completo de los eventos asociados con los agregados en su dominio. Esta es una característica vital en algunas implementaciones, como la contabilidad, donde necesita un rastro de auditoría completo de las transacciones financieras, y donde los eventos deben ser inmutables. Una vez que ha ocurrido una transacción, no puede eliminarla ni cambiarla, aunque puede crear una nueva transacción correctiva o de reversión si es necesario.

El beneficio principal de utilizar event sourcing es un mecanismo de auditoría incorporado que garantiza la consistencia de los datos transaccionales y los datos de auditoría porque estos son los mismos datos. La representación a través de eventos le permite reconstruir el estado de cualquier objeto en cualquier momento, lo cual es crucial para la recuperación de procesos interrumpidos (por ejemplo, durante un outage o fallo del sistema).

La siguiente lista describe algunos de los beneficios adicionales que puede obtener al utilizar event sourcing:

  • Rendimiento: Debido a que los eventos son inmutables, se utilizan operaciones de solo anexado para guardarlos. Events son también objetos simples e independientes. Ambos factores conducen a un mejor rendimiento y escalabilidad para el sistema que los enfoques que utilizan modelos de almacenamiento relacional complejos.

  • Simplificación: Events son objetos simples que describen lo que ha sucedido en el sistema. Al guardar eventos de manera sencilla, usted está evitando las complicaciones asociadas con el almacenamiento de objetos de dominio complejos en un almacén relacional.

  • Registro de auditoría: Events son inmutables y almacenan el historial completo del estado del sistema. Como tal, pueden proporcionar un registro de auditoría detallado de lo que ha tenido lugar dentro del sistema.

  • Las Nuevas Proyecciones pueden acceder a eventos existentes: Las Proyecciones (también conocidas como Modelos de Vista o Modelos de Consulta) proporcionan una vista del modelo de datos basado en eventos subyacente. Cuando se añaden nuevas Proyecciones, pueden acceder inmediatamente a los eventos existentes para mostrar una nueva vista de los datos. A menudo se les denomina "lado de lectura", ya que solo necesitan leer del almacén de datos existente y no interfieren con la escritura de nuevos eventos, por lo tanto, no impactan en el rendimiento del sistema en cuestión.

  • Integración con otros subsistemas: Events proporcionar una forma útil de comunicarse con otros subsistemas. Su almacén de eventos puede publicar eventos para notificar a otros subsistemas interesados sobre cambios en el estado de la aplicación. Nuevamente, el almacén de eventos proporciona un registro completo de todos los eventos que ha publicado a otros sistemas. En IPF, por ejemplo, esto podría ser el Servicio de Notificaciones o ODS.

  • Derivando valor adicional para el negocio a partir del historial de eventos: Al almacenar eventos, usted tiene la capacidad de determinar el estado del sistema en cualquier momento anterior consultando los eventos asociados con un objeto de dominio hasta ese momento. Esto le permite responder preguntas históricas del negocio sobre el sistema. Además, usted no puede predecir qué preguntas podría querer hacer el negocio sobre la información almacenada en un sistema. Si usted almacena sus eventos, no está descartando información que podría resultar valiosa en el futuro.

  • Solución de problemas en producción: Puede utilizar el almacén de eventos para solucionar problemas en un sistema de producción tomando una copia del almacén de eventos de producción y reproduciéndola en un entorno de prueba. Si conoce el momento en que ocurrió un problema en el sistema de producción, entonces puede reproducir fácilmente el flujo de eventos hasta ese punto para observar exactamente qué estaba sucediendo.

  • Corrección de errores: Puede descubrir un error de codificación que resulta en que el sistema calcule un valor incorrecto. En lugar de corregir el error de codificación y realizar un ajuste manual arriesgado en un elemento de datos almacenado, puede corregir el error de codificación y reproducir el flujo de eventos para que el sistema calcule el valor correctamente basado en la nueva versión del código.

  • Pruebas: Todos los cambios de estado en sus agregados se registran como eventos. Por lo tanto, puede probar que un comando tuvo el efecto esperado en un agregado simplemente verificando el evento.

  • Flexibilidad: Se puede proyectar una secuencia de eventos a cualquier representación estructural deseada.