Implementaciones de Actualización Continua con IPF SDK

Cambiar un flujo sin versioning introduce imprevisibilidad: un flujo en vuelo iniciado en la versión antigua 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 instructions 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 en línea 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 state donde ningún nodo podrá alojar la versión antigua del flujo, causando que el flujo en curso quede huérfano y atrapado para siempre en un estado incompleto state.

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 determinado 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 característica flag inicia el flujo, el mensaje de iniciación 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 canarias 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 son definidos por el business data elementos listados para el event en el DSL.

Rompiendo un event el esquema 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 un event’s business data elementos, un cambio no intencionado a un tipo utilizado en algún lugar del gráfico de objetos podría ocurrir, por ejemplo, al actualizar una versión de una biblioteca común.

Para asegurar event los esquemas no están rotos, usted debe crear un conjunto de pruebas que verifique sus esquemas en el tiempo de construcción.

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

Los consumidores que procesan respuestas de su external domains debe ser capaz 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.state.

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 El valor de configuración que requiere consistencia en todo el clúster, deberá apagar todo su clúster.

Configuración relacionada con los reintentos de acción y timeouts 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 serí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 ningún inconveniente en mantener los flujos antiguos, especialmente si desea permitirse la capacidad de construir.journal processor s que trabajan contra 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 restart 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.