Prácticas recomendadas para la implementación
Las siguientes mejores prácticas se publican para ayudarle a entender y tomar decisiones conscientes.decisions sobre el despliegue de su IPF flows, aplicaciones y soluciones completas.
-
Observabilidad == Consideraciones para el Despliegue de Flujos
IPF proporciona flexibilidad en la forma en que se desplegarán los flujos; ya sea múltiples flujos en un único servicio O cada flujo en un servicio desplegable separado. Desplegar flujos por separado permite que sean escalados, dotados de recursos, probados y desplegados de manera independiente.
Justificación- Decisions acerca de cómo desplegar flujos debe ser impulsado por los requisitos no funcionales y debe permitir la máxima flexibilidad en cómo cumplir con esos requisitos.
Implicaciones
-
Es importante considerar los NFRs/TPS requeridos para flujos/servicios específicos al inicio del proyecto para que:
-
Los servicios pueden ser diseñados en consecuencia.
-
La infraestructura puede ser aprovisionada y probada al inicio del proyecto para reducir el riesgo de problemas de rendimiento más adelante.
-
-
Los flujos que necesitan procesar un alto volumen de pagos (alto TPS) probablemente se alojarán por separado de los flujos de bajo volumen para que los servicios puedan escalarse de manera independiente.
-
Los flujos de pagos con un perfil de procesamiento similar pueden ser alojados en la misma aplicación física para ahorrar en costos de infraestructura.
-
Si hay ambigüedad sobre los NFR y los requisitos futuros, normalmente se aconseja 'comenzar de manera simple' con menos aplicaciones físicas. Siempre es posible dividir los flujos de procesamiento en aplicaciones separadas más adelante en el proyecto/hoja de ruta. == Opciones de implementación de flujos múltiples
| Opción de Despliegue | Pros | Cons |
|---|---|---|
Múltiples flujos desplegados en la misma aplicación (from the same MPS proyecto) |
Permite el flujo directo-flow calls Menos infraestructura requerida para desplegar aplicaciones:
|
La carga en un flujo puede afectar el rendimiento de otros si los recursos son insuficientes. No hay capacidad para escalar aplicaciones por separado. |
Desplegado como aplicaciones separadas (Desde separado MPS proyectos) |
Las aplicaciones pueden escalarse por separado de acuerdo con los requisitos de recursos de los flujos. El procesamiento para diferentes perfiles de comportamiento puede dividirse entre diferentes aplicaciones. |
Los flujos deben dividirse en separados MPS proyectos Kafka(o algún otro transporte de infraestructura) requerido para llamar de un flujo a otro Se requiere más infraestructura.
|
Implementación de Cambios en el Flujo
Una vez que tenga un flujo desplegado en un entorno en vivo y procesando transacciones, se debe tener cuidado al implementar cambios o actualizaciones. Se le aconseja utilizar versionado de flujo
Justificación- Intentar implementar cambios una vez que un flujo está activo y procesando transacciones conlleva el riesgo de interrumpir transacciones en curso. Por ejemplo, cambiar el event comportamiento para añadir transiciones. IPF admite flujo versioning para evitar esto y asegurar que las transacciones se completen en la versión en la que fueron iniciadas por primera vez.
Implicaciones- Lea las consideraciones para Manejo de Transacciones en Vuelo
Escalado
IPF flows que están divididas en aplicaciones de procesamiento IPF separadas pueden ser implementadas por separado en diferentes Akka cluster s [por ejemplo, iniciación frente a ejecución]. Esto permitirá la escalabilidad individual de flujos que tienen requisitos de mayor rendimiento:
-
Escalado verticalmente-asignados recursos apropiados (CPU, RAM, etc.)
-
Escalado horizontalmente-más nodos en el clúster
También es posible comenzar de manera más sencilla, con menos aplicaciones, y dividir en aplicaciones separadas a medida que surja la necesidad (por ejemplo, un clúster de aplicación única para la ejecución para comenzar).
Los flujos que pueden utilizar una base de código común pueden ser desplegados múltiples veces, por ejemplo, en diferentes regiones, si así lo dictan los requisitos no funcionales.
| Si la misma aplicación de procesamiento de IPF se fuera a implementar en diferentes regiones en diferentes Akka cluster s, entonces deben ser desplegados en una infraestructura lógicamente separada.- es decir, colecciones de Mongo separadas y Kafka temas (para evitar que consuman los mismos mensajes/datos) |
Esto también ayudará a lograr una estrategia de implementación más granular, donde diferentes regiones/productos reciben nuevas versiones en diferentes momentos (por ejemplo, implementaciones escalonadas). Esto disminuye las dependencias entre áreas de negocio donde las actualizaciones pueden ser recibidas de acuerdo con los horarios y prioridades del negocio.
Observabilidad
IPF proporciona una serie de herramientas de observabilidad, asegúrese de que estas estén configuradas correctamente al inicio del ciclo de desarrollo.
Justificación- El Grafana tableros de control que IPF proporciona de forma predeterminada para monitorear la salud de la aplicación, los cuales serán invaluables para el personal operativo al intentar resolver problemas de rendimiento tanto en los entornos de prueba como en los de producción.
También se recomienda utilizar un marco de registro para monitorear IPF application registros para detectar cualquier otra anomalía en el sistema.
Las técnicas mencionadas anteriormente pueden proporcionar alertas tempranas sobre problemas potenciales con el sistema y ayudar en la búsqueda de una resolución.
Implicaciones- Asegúrese de que las herramientas de monitoreo estén configuradas correctamente y funcionando en todos los entornos relevantes.
Asegúrese de que los requisitos de monitoreo y alerta del sistema estén bien entendidos; esto puede significar que se requieren nuevos paneles para complementar los proporcionados con IPF de forma predeterminada.