Mejores prácticas de despliegue
Las siguientes mejores prácticas se publican para ayudarte a comprender y tomar decisiones conscientes sobre el despliegue de tus flows de IPF, aplicaciones y soluciones completas.
Consideraciones para el despliegue de flows
IPF proporciona flexibilidad en cómo se desplegarán los flows: varios flows en un único servicio O cada flow en un servicio desplegable por separado. Desplegar los flows por separado permite que se escalen, asignen recursos, prueben y desplieguen de forma independiente.
Justificación - Las decisiones sobre cómo desplegar los flows deben estar guiadas por los requisitos no funcionales y deben permitir la máxima flexibilidad para cumplirlos.
Implicaciones
-
Es importante considerar los NFR/TPS requeridos para flows/servicios específicos al principio del proyecto para que:
-
Los servicios puedan diseñarse en consecuencia
-
La infraestructura pueda aprovisionarse y probarse pronto en el proyecto para reducir riesgos de rendimiento más adelante
-
-
Los flows que necesiten procesar un alto volumen de pagos (alto TPS) probablemente se alojarán por separado de los flows de bajo volumen para que los servicios puedan escalarse de forma independiente
-
Los flows para pagos con un perfil de procesamiento similar pueden alojarse en la misma aplicación física para ahorrar costes de infraestructura
-
Si hay ambigüedad sobre NFRs y requisitos futuros, normalmente es aconsejable “empezar simple” con menos aplicaciones físicas. Siempre es posible dividir los flows de procesamiento en aplicaciones separadas más adelante en el proyecto/roadmap.
Opciones de despliegue para múltiples flows
| Opción de despliegue | Pros | Contras |
|---|---|---|
Varios flows desplegados en la misma aplicación (desde el mismo proyecto MPS) |
Permite llamadas directas flow-flow Menos infraestructura requerida para desplegar aplicaciones:
|
La carga en un flow puede afectar al rendimiento de otros si faltan recursos No hay capacidad para escalar aplicaciones por separado |
Desplegados como aplicaciones separadas (Desde proyectos MPS separados) |
Las aplicaciones pueden escalarse por separado según los requisitos de recursos de los flows El procesamiento para diferentes perfiles de comportamiento puede dividirse entre distintas aplicaciones |
Los flows deben dividirse en proyectos MPS separados Se requiere Kafka (u otro transporte de infraestructura) para llamar de un flow a otro Más infraestructura requerida
|
Despliegue de cambios en flows
Una vez que tengas un flow desplegado en un entorno en vivo y procesando transacciones, hay que tener cuidado al desplegar cambios o actualizaciones. Se recomienda usar flow versioning
Justificación - Intentar desplegar cambios cuando un flow ya está en vivo y procesando transacciones corre el riesgo de interrumpir transacciones en curso. Por ejemplo, cambiar el comportamiento de events para añadir transitions. IPF soporta el versionado de flows para evitar esto y asegurar que las transacciones se completen en la versión en la que fueron iniciadas.
Implicaciones - Lee las consideraciones para Handling In-Flight Transactions
Escalado
Los flows de IPF que se dividen en aplicaciones de procesamiento IPF separadas pueden desplegarse por separado en diferentes clústeres de Akka [por ejemplo, iniciación vs. ejecución]. Esto permitirá el escalado individual de los flows que tengan mayores requisitos de throughput:
-
Escalado vertical: asignar recursos apropiados (CPU, RAM, etc.)
-
Escalado horizontal: más nodos en el clúster
También es posible comenzar de forma más simple, con menos aplicaciones, y dividir en aplicaciones separadas según surja la necesidad (por ejemplo, comenzar con un único clúster de aplicación para ejecución)
Los flows que pueden usar una base de código común pueden desplegarse múltiples veces, por ejemplo, en diferentes regiones, si así lo dictan los requisitos no funcionales.
| Si la misma aplicación de procesamiento IPF se desplegara en diferentes regiones en diferentes clústeres de Akka, entonces tendrían que desplegarse en infraestructura lógicamente separada: es decir, colecciones de Mongo y topics de Kafka separados (para evitar que consuman los mismos mensajes/datos) |
Esto también ayudará a lograr una estrategia de despliegue más granular, donde diferentes regiones/productos reciban nuevas versiones en distintos momentos (por ejemplo, despliegues escalonados). Esto disminuye dependencias entre áreas de negocio, donde las actualizaciones pueden recibirse según sus calendarios y prioridades.
Observabilidad
IPF proporciona varias herramientas de observabilidad; asegúrate de que estén configuradas correctamente al principio del ciclo de desarrollo.
Justificación - Los dashboards de Grafana que IPF proporciona out of the box para monitorizar la salud de la aplicación serán invaluables para el personal de operaciones al intentar resolver problemas de rendimiento tanto en entornos de prueba como de producción.
También es aconsejable usar un framework de logging para monitorizar los logs de la aplicación IPF a fin de detectar otras anomalías en el sistema.
Estas técnicas pueden proporcionar alertas tempranas de posibles problemas del sistema y ayudar a encontrar una resolución.
Implicaciones - Asegúrate de que las herramientas de monitorización estén configuradas correctamente y funcionando en todos los entornos relevantes.
Asegúrate de que los requisitos de monitorización y alertado del sistema se entiendan bien; esto puede significar que se necesiten nuevos dashboards para complementar los que IPF proporciona out of the box.