Implementaciones de Actualización Continua con IPF SDK

Cambiar un flujo sin versionado introduce imprevisibilidad: un flujo en ejecución iniciado en la versión anterior del servicio puede no ser capaz de avanzar al ser rehidratado en la nueva versión del servicio debido a diversas incompatibilidades y, por lo tanto, podría quedar atrapado en un bucle infinito de recuperación-fallo.

Si un flujo necesita ser actualizado — cambios en las transiciones, introducción de nuevos estados, etc. — se debe crear una nueva versión del flujo y los cambios deben realizarse en esa versión. Ver Flujos de Versionado en la sección del tutorial para instrucciones sobre cómo hacer esto.

Eliminar una versión de flujo presente en la versión anterior del servicio abre la puerta a la orfandad de flujos en curso. IPF utiliza Akka Cluster roles para decidir qué nodos pueden alojar qué flujos. Si para el momento en que la actualización continua alcance el nodo final aún hay algunos flujos en curso que están ejecutando la versión eliminada, el clúster se encontrará en un estado en el que ningún nodo será capaz de alojar la versión antigua del flujo, lo que causará que el flujo en curso quede huérfano y atrapado para siempre en un estado incompleto.

Si la versión anterior de su servicio tenía la capacidad de iniciar un número de flujos de una cierta versión, esos flujos no deben ser eliminados en la nueva versión.

Elimine los flujos solo cuando no haya instancias en curso de los mismos y la versión anterior no tenga forma de iniciarlos.

Para determinar si se puede iniciar un cierto flujo, debe inspeccionar sus reglas de enrutamiento de flujo (cubiertas en el siguiente punto).

Selección de Versión de Flujo Basada en el Contexto le permite crear reglas de enrutamiento basadas en la configuración que dependen de los encabezados de los mensajes para realizar el enrutamiento a diferentes versiones de un flujo.

Alternativamente, como se indica en Flujos de Versionado, usted tiene control programático directo sobre qué versión de un flujo iniciar, por lo que crear reglas de enrutamiento arbitrarias también es una posibilidad.

Por defecto, si no se especifica una versión, se utiliza la más reciente.

Dependiendo del nivel de confianza en la corrección de sus nuevas versiones de flujo, puede decidir seguir iniciando las versiones antiguas hasta que se cumplan ciertas condiciones — un customer con una bandera de características inicia el flujo, el mensaje de inicio contiene un encabezado específico, se aplica un predicado de configuración estática, etc. La selección de versiones basada en el contexto mencionada anteriormente también puede ser utilizada para realizar pruebas canary y permitirle migrar lentamente a una nueva versión de un flujo. Ver Selección de Versión de Flujo Basada en Contexto para Pruebas Canary para más detalles.

Los esquemas están definidos por los elementos de datos empresariales enumerados para el evento en el DSL.

Romper un esquema de evento significará que sus flujos en vuelo no podrán ser recuperados en un rebalanceo, dejándolos huérfanos y sin poder completarse sin una implementación de hotfix.

Incluso si un flujo no cambia los elementos de datos comerciales de un evento, aún podría ocurrir un cambio no intencionado en un tipo utilizado en algún lugar del gráfico de objetos, por ejemplo, al actualizar una versión de una biblioteca común.

Para asegurar que los esquemas de eventos no se rompan, usted debe crear un conjunto de pruebas que verifique sus esquemas en el momento de la construcción.

Si por alguna razón poco probable no puede evitar romper un esquema de evento, puede utilizar el IPF domain event schema evolution support como último recurso.

Los consumidores que procesan respuestas de sus dominios externos deben ser capaces de enviar las entradas adecuadas tanto a las versiones antiguas como a las nuevas de sus flujos.

No apoyar las versiones antiguas además de las nuevas causará que los flujos de la versión antigua en curso se agoten o queden huérfanos en un estado inconsistente.

Bastantes Akka Las opciones de configuración — particularmente relacionadas con el agrupamiento, por ejemplo, las estrategias del Resolutor de Cerebros Divididos, el número de fragmentos, etc. — requieren que todos los nodos en el clúster estén configurados con el mismo valor para poder formar un clúster con éxito.

Si necesita cambiar un Akka valor de configuración que requiere consistencia en todo el clúster, deberá apagar todo su clúster.

La configuración relacionada con los reintentos de acción y los tiempos de espera es sensible a los cambios de versión del flujo, consulte Flujos de Versionado para más detalles.

Debe aplicar una consideración cuidadosa al actualizar ciertos journal processor configuraciones ya que pueden romper la compatibilidad de actualización continua:

El SDK de IPF viene con un conjunto predefinido de herramientas de monitoreo y soporte para trazado distribuido. Integrarlos en su ecosistema de observabilidad resultaría beneficioso al solucionar problemas.

Incluso si su pipeline de CD implica un entorno de pre-producción que refleja de cerca la producción, y ha realizado pruebas exhaustivas de sus nuevas versiones de flujo en pre-producción, puede ser recomendable aumentar lentamente la iniciación de nuevas versiones de flujo justo después del despliegue, especialmente si los flujos están llamando a nuevos endpoints de servicios externos.

Puede confiar en el métricas de la aplicación existente para rastrear qué versiones de qué flujos están siendo iniciadas y completadas.

En este momento, cualquier problema que se encuentre probablemente será resuelto por sus procedimientos habituales de corrección de errores.

Esto incluye versiones de flujo que ya no están activas en su servicio; con todas las instancias en curso de los flujos antiguos completadas en producción y las reglas de enrutamiento que impiden que se inicien nuevamente, ya no serán necesarias en la próxima versión de su servicio.

Por otro lado, si no le preocupa el tamaño de sus archivos JAR, no hay inconveniente en mantener los flujos antiguos, especialmente si desea permitirse la capacidad de construir procesadores de diarios que funcionen con todos los datos históricos en el diario.

Incluso con Akka Recuerde que, con las entidades habilitadas, no hay nada que se pueda hacer para permitir la reactivación de esos flujos en la versión antigua del servicio de orquestación, ya que el código necesario para ejecutarlos ya no existe.

Dependiendo de cómo configure sus reglas de enrutamiento, esto puede o no requerir un reinicio de todos los nodos en el clúster.

Revertir las reglas de enrutamiento no dejará huérfanas ninguna de las flujos, pero el problema subyacente puede seguir dejando los flujos atascados y puede ser necesaria alguna intervención manual.

A diferencia de realizar un retroceso completo de la versión del servicio, revertir las reglas de enrutamiento le permitiría crear utilidades ad-hoc que programáticamente abortar cualquiera de los flujos que están atascados, o al menos pasivar ellos. Usando el Transaction Operations API también es una opción para crear scripts de recuperación ad-hoc.