Anatomía de una Aplicación Típica de Orquestación IPF

Una aplicación de orquestación de IPF consiste en varios componentes clave que trabajan juntos para procesar y enrutar mensajes. Este documento describe la arquitectura de una aplicación de orquestación de IPF, abarcando las interacciones entre estos componentes, el flujo de mensajes y cómo se maneja la sobrecarga.

componentes principales

Diagram

Componentes del Dominio

El Domains el componente representado en el diagrama anterior abarca la definición de DSL y MPS-componentes generados que proporcionan la lógica de orquestación dentro del Servicio de Orquestación IPF:

  • Flujo Event Sourced Behaviours(ESBs): Estos forman el core de la lógica de orquestación, implementando finito state máquinas que impulsan los procesos empresariales. Los ESBs son generados completamente por MPS y utilice event sourcing, leyendo y persistiendo domain events a través de la Akka Persistence Plugin.

  • Input Adapter s: Estos componentes envían entradas a la flow ESB s, provocando transiciones entre finito state estados de la máquina. Input Adapter s son generados completamente por MPS.

  • Action Adapter s: Definidos por el servicio de orquestación IPF, estos componentes implementan la Acción Ports generado por MPS y se integre con el Domain a través de esas interfaces. Action Adapter s son implementados por el equipo de ingeniería que crea el servicio de orquestación.

Componentes de Conectividad

  • Receive Connector s: Componentes de las bibliotecas de conectividad del sistema IPF que consumen mensajes enviados por external domains. Su función principal en un servicio de orquestación es convertir los mensajes entrantes en apropiados Input objetos y remítalos a los correspondientes Input Adapter.

  • Send Connector s: Similar a Receive Connectors, pero diseñado para la comunicación saliente. Estos componentes transmiten mensajes a external domains.

  • Cache Adaptadores: Proporcionados por IPF Cache bibliotecas, estos componentes típicamente operan en frente de Request Reply Send Connectors to cache resultados de HTTP llamadas. Delegan a los conectores cuando un cache la falta ocurre pero devuelve cached resultados cuando estén disponibles.

Interacción del Sistema y Flujo de Mensajes

Los componentes de IPF interactúan de manera coordinada para procesar mensajes. Entender este flujo y cómo se aplica la sobrepresión en todo el sistema es esencial para la resolución de problemas, la planificación de capacidad y la optimización del rendimiento.

Proceso de Flujo de Mensajes

ipf message flow drawio

A continuación se presenta una breve descripción de cada paso en el flujo de mensajes. Tenga en cuenta que, debido a Akka cluster sharding, los pasos 1-3 y 4-7 probablemente se realicen en diferentes nodos del servicio de orquestación de IPF.

  1. Los mensajes generalmente ingresan a un servicio de orquestación IPF a través de un Receive Connector

  2. El conector transforma el mensaje recibido en un apropiado Input y llama a los relevantes Domain Input Adapter

  3. El único propósito del adaptador es convertir la entrada en un comando y enviarlo al correspondiente.Flow ESB, que puede residir en un nodo de servicio diferente

  4. Cuando recibe el comando, el Flow ESB primero verifica si el comando debe ser aplicado. Si la verificación es exitosa, un event se persiste utilizando el complemento de persistencia. Si la verificación falla, se omiten los pasos posteriores.

  5. (Optional)Akka Persistence Plugin convierte el events escribe comandos en la base de datos y se comunica con la base de datos

  6. (Optional) Si hay acciones configuradas (efectos secundarios) que deben ser triggered sobre event persistencia, el Flow ESB los activa en este punto a través del apropiado Action Adapter.

    • Si la implementación de la acción configurada modela una interacción con un sistema externo, un Send Connector puede ser utilizado para ejecutar esto, como se muestra en el paso 7. La elección de Send Connector se informa por el tipo de acción que ha sido modelada:

      • Se utiliza una acción de Solicitud-Respuesta — A Send Connector o un no almacenado Request Reply Send Connector se utiliza para enviar un mensaje. Cualquier respuesta potencial a ese mensaje del dominio externo será recibida a través de un Receive Connector.

      • Se utiliza una acción de Función de Dominio — Un potencialmente cached Request Reply Send Connector se llama, lo que significa un configurado Cache Adapter se consulta primero.

        • En un cache miss, the Request Reply Send Connector la llamada procede y el resultado de la operación se almacena en el cache para uso futuro.

        • On a cache si se produce un golpe, omitimos el paso 7.

    • Si la implementación de la acción configurada representa un proceso que se maneja completamente dentro de los límites del dominio, un Send Connector no es necesario y el Action Adapter convierte la respuesta en un apropiado Input y llama a su Input Adapter, continuando el flujo desde el paso 3.

    • Si no se van a realizar acciones triggered, el paso 7 también se omite.

  7. (Optional) El conector convierte los datos de la acción en un formato que el dominio externo espera y los envía utilizando el transporte configurado.

Presión de retroceso

La retropresión es un medio de control de flujo y una forma para que los consumidores de datos notifiquen a un productor sobre su disponibilidad actual, ralentizando efectivamente al productor aguas arriba para que coincida con sus velocidades de consumo. La mayoría de las bibliotecas de flujos reactivos ofrecen a los desarrolladores varios enfoques (que a veces pueden combinarse) para utilizar cuando se encuentra con la presión de retroceso:

  • Mensajes de búfer

  • Reduzca la velocidad (regule) el procesamiento

  • Carga de desecho (mensajes descartados)

  • Tome el último mensaje (cabeza)

Por lo general, la contrapresión se aplica dentro de un único proceso del sistema operativo (en nuestro caso, un JVM) y se menciona con mayor frecuencia en el contexto de flujos reactivos. Algunos protocolos de mensajería sí admiten la retropresión como parte de su especificación, permitiendo que las señales salgan de los confines de un solo proceso (por ejemplo,https://docs.oasis-open.org/amqp/core/v1. 0/os/amqp-core-transport-v1. 0-os.html#doc-flow-control[Control de flujo AMQP]).

Presión de retroceso en Akka

Los conectores IPF se construyen sobre Akka Streams, una implementación de flujos reactivos, que viene con mecanismos de retropresión integrados.

 Akka Los actores se comunican mediante el paso de mensajes asíncronos, que por defecto no ofrece retroalimentación.
Sin embargo, se puede añadir contrapresión aplicando el https://doc.akka.io/libraries/akka-core/current/actors.html#ask-send-and-receive-future[patrón de solicitud], obligando a los usuarios de cualquier actor (lo que incluye IPF flows) para esperar una respuesta antes de continuar.

Para flujos,https://doc.akka.io/libraries/akka-core/current/typed/index-persistence.html[Akka Persistence] solo permitirá que se inicie o rehidrate un número configurable de flujos de manera concurrente. Esto, en combinación con el patrón de solicitud mencionado anteriormente, actúa como una barrera protectora alrededor del event almacenar, propagando cualquier presión de retroceso desde la base de datos hacia arriba.

Presión de retroceso en la base de datos

IPF utiliza el flujos reactivos MongoDB controlador, que viene con soporte de retropresión incorporado. El MongoDB el cliente reactivo se ralentiza ante la sobrepresión, y esta sobrepresión se propaga a los Conectores IPF y Akka Persistence.

Presión de retroceso en conectores

Como se mencionó anteriormente, los conectores IPF se construyen utilizando Akka Streams, haciendo que la contrapresión sea una característica incorporada.

Todos los etapas de conector ralentizan el consumo por retropresión de forma predeterminada, aunque ciertas etapas ofrecen otras opciones:

  • doc.akka.io/docs/akka/current/stream/operators/Source/queue.html Source.queue] se utiliza principalmente en Send Connectors para encolar mensajes para su envío. Almacena solicitudes para enviar hasta un límite, luego reduce la velocidad de los productores hasta un límite. Una vez que ambos límites son superados, comienza a eliminar mensajes.

  • Flow.mapAsync se utiliza en todo tipo de conectores para realizar diversas tareas que pueden llevar mucho tiempo —mapping, registro, correlación, adición a colas de cartas muertas, etc. Se puede ver como un suministro de un búfer de solicitudes que se ejecutan de manera concurrente, después de lo cual se ralentiza el flujo ascendente.

Presión de retroceso en IPF (Todo Junto)

ipf backpressure flow drawio

Como se explicó en la sección de flujo de mensajes, todos los componentes de IPF están intrínsecamente vinculados entre sí, lo que provoca que sus mecanismos de contrapresión se combinen. En la práctica,Receive Connectors sirve como el principal cuello de botella en el servicio de orquestación de IPF, donde la presión de retroceso de las dependencias aguas abajo se manifiesta en última instancia. Esto significa que la velocidad a la que el Receive Connector El consumo y procesamiento del trabajo está determinado por la velocidad de procesamiento de todo el flujo de mensajes, y no es más rápido que su paso más lento.

El flujo de contrapresión a través del servicio es el siguiente:

  1. An External System crea un mensaje y lo hace entregar a través de un medio de transporte de su elección. El transporte elegido influye en si las señales de contrapresión del servicio de orquestación llegan al sistema externo. HTTP puede reducir la carga al devolver errores 503 por presión de retroceso, AMQP admite la desaceleración de los productores, mientras Kafka y JMS simplemente actúan como amortiguadores.

  2. Cada Receive Connector tendrá una o más etapas con un pequeño búfer de mensajes que pueden ser procesados en paralelo. Cuando el búfer está lleno, el conector ejercerá presión inversa y dejará de consumir nuevo trabajo. Los mensajes solo se eliminan del búfer cuando su procesamiento se completa (con éxito o no). Dependiendo de la configuración de resiliencia del conector, el procesamiento de un failed El mensaje puede ser reintentado un número configurable de veces hasta que se alcance el número máximo de intentos, o hasta que transcurra la duración de tiempo configurada.

  3. An Input Adapter no ofrece mecanismos de contrapresión propios y, en su lugar, propaga la contrapresión aguas abajo al esperar la confirmación — en forma de un mensaje de resultado de procesamiento exitoso — de que los pasos 3-7 se han completado con éxito. Los adaptadores vienen con su propio RetrySupport— un (reintentable)failed llamada a la Flow ESB se reintentará un número configurable de veces antes de que la falla se propague al conector.

  4. Cada llamada a la Flow ESB desde un Input Adapter usará Akka el soporte de 's para la mensajería de clústeres transparente a la ubicación, y esperará un tiempo configurado para recibir el mensaje de resultado del procesamiento antes de agotar el tiempo y señalizar al adaptador.RetryStrategy que el intento ha failed.Flow ESB Los actores procesan los comandos uno por uno y almacenan los mensajes pendientes en sus colas de mensajes. Si el Flow ESB determina que el comando no debe aplicarse (por ejemplo, es inválido para el actual state, un duplicado, etc.), se envía un resultado de procesamiento a la Input Adapter y se omiten los pasos adicionales.

  5. La velocidad a la que se procesan los comandos depende directamente de la velocidad a la que el Akka Persistence Plugin puede persistirlos. Una vez que el event se persiste, el Flow ESB está libre para aceptar nuevos comandos.

  6. Todas las acciones configuradas que el Flow ESB los disparadores se llaman de manera asíncrona y en paralelo. El resultado del procesamiento se envía a la Input Adapter desde el paso 2 solo después de que se hayan completado todas las acciones.

  7. Dependiendo del tipo de acción y su implementación, se aplican diferentes reglas de retropresión:

    • Las decisiones no interactúan con sistemas externos, pero resultan en una ejecución encadenada que efectivamente activa los pasos 3-7 y propaga su retropresión hacia arriba a la Receive Connector.

    • Domain Functions puede requerir interacciones externas, después de las cuales se produce una ejecución encadenada, activando efectivamente los pasos 3-7 y propagando su contrapresión hacia arriba a la Receive Connector.

    • Las acciones de Notificaciones y Respuesta a Solicitudes generalmente requieren interacciones externas, pero típicamente no desencadenan una ejecución encadenada a menos que interactúen con un flujo separado. Como resultado, solo la contrapresión de Send Connectors se propagará a la Receive Connector.

    • A menos que sean remotos o distribuidos por naturaleza,Cache Adapters típicamente no generan contrapresión — accediendo al cache es una operación en memoria.

    • Ambos el plano Send Connector y el Request Reply Send Connector proporcione un búfer para los mensajes que se envían en paralelo. Una vez que el búfer esté lleno, se ralentizará y luego comenzará a descartar mensajes.

    • Ambos tipos de Send Connector soporte para reintentos configurables y timeouts, que se incluirá en las desaceleraciones por contrapresión.