Akka Persistence

Akka Persistence permite a los actores con estado persistir su state para que pueda ser recuperado cuando un actor esté ya sea restarted, como después de un JVM crash, 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 el events que son persistidos por el actor son almacenados, no el actual state del actor (aunque actor state el soporte de instantáneas está disponible). El events se persisten al agregar a almacenamiento (nunca se muta nada), lo que permite tasas de transacción muy altas y una replicación eficiente. Un actor con estado se recupera al reproducir el almacenado events al actor, permitiéndole reconstruir su state. Esto puede ser ya sea el historial completo de cambios o comenzar desde un punto de control en una instantánea, lo que puede reducir drásticamente los tiempos de recuperación.

Las secciones que subyacen a esta página contienen instructions en relación con 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

Events suceder en el pasado. Por ejemplo, "el pain. 001 fue recibido", "la Cuenta fue Debitada", "el efectivo fue dispensado". Todos estos events se describen utilizando el tiempo pasado.
Events son inmutables, esto significa que events suceder en el pasado, no pueden ser cambiados ni deshechos. Sin embargo, posteriores events puede alterar o anular los efectos de anteriores events. Por ejemplo, "el débito fue cancelado" es un event que cambia el resultado de un débito anterior event. En este caso, el débito original event todavía existe, pero la segunda cancelación event cambia el total state de la transacción en el sistema. El actual state es la culminación de la secuencia de events que conduce a ello.

Típicamente,events incluya parámetros que proporcionen información adicional sobre el event. Por ejemplo, "La cuenta 12345678 fue debitada mediante cheque."

Usando Event Sourcing

Event sourcing es una forma de conocer la-de su aplicación.state 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 Sistema de origen, almacenará todas las transacciones y cancelaciones.events para cada esquema de pago y luego calcular el número actual de transacciones accediendo a la relevante events asociado con el esquema para el cual usted quería 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 restringe 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 el events pasa por.

Por ejemplo, un IPF process flow 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 service a ser enviado a customer en otro banco, puede considerarse como el Actor.

¿Por qué utilizamos event sourcing?

Event sourcing almacena un historial completo de la events asociado 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 events debe ser inmutable. Una vez que se ha realizado 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. Representación a través de events le permite reconstruir el state de cualquier objeto en cualquier momento en el tiempo, 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 usted puede obtener al utilizar event sourcing:

  • Rendimiento: Porque events son inmutables, se utilizan operaciones de solo anexado para guardarlos. Events también son 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 simplemente guardar events, 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 de la state del sistema. Como tal, pueden proporcionar un registro de auditoría detallado de lo que ha tenido lugar dentro del sistema.

  • Nuevas proyecciones pueden acceder a existentesevents**: Las proyecciones (también conocidas como Modelos de Vista o Modelos de Consulta) proporcionan una vista de la base subyacente event modelo de datos basado en. Cuando se añaden nuevas Proyecciones, pueden acceder inmediatamente a los existentes events 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 events, por lo tanto no afecta el rendimiento del sistema en cuestión.

  • Integración con otros subsistemas: Events proporciona una forma útil de comunicarse con otros subsistemas. Su event la tienda puede publicar events para notificar a otros subsistemas interesados sobre los cambios en la aplicación state. Nuevamente, el event la tienda proporciona un registro completo de todos los events que se publicó en otros sistemas. En IPF, por ejemplo, esto podría ser el Servicio de Notificaciones o ODS.

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

  • Solución de problemas de producción: Puede utilizar el event almacenar para solucionar problemas en un sistema de producción tomando una copia de la producción event almacenar y reproducirlo en un entorno de prueba. Si usted conoce el momento en que ocurrió un problema en el sistema de producción, entonces puede reproducir fácilmente el event transmitir hasta ese punto para observar exactamente lo que 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 event transmita para que el sistema calcule el valor correctamente basado en la nueva versión del código.

  • Pruebas: Todos los state los cambios en sus agregados se registran como events. Por lo tanto, puede probar que un comando tuvo el efecto esperado en un agregado simplemente verificando la event.

  • Flexibilidad: Una secuencia de events puede ser proyectado a cualquier representación estructural deseada.