Introducción

Descripción general

Dependiendo de su message log configuración para usar Kafka o Base de datos, el despliegue podría ser ligeramente diferente.

Kafka Message Log ging

NetOwl Namematcher - Utilizado por VoP a través de la Resolución de Identidad (integrada) como el proveedor externo para la coincidencia de nombres.
Gestión de Cuentas - Utilizado por VoP para consultar los detalles de la cuenta utilizados en la coincidencia
Base de datos - Utilizado para la concesión de licencias
Kafka - Utilizado por VoP para el registro de mensajes y el almacenamiento del archivo de procesamiento

Base de datos Message Log ging

NetOwl Namematcher - Utilizado por VoP a través de la Resolución de Identidad (integrada) como el proveedor externo para la coincidencia de nombres.
Gestión de Cuentas - Utilizado por VoP para consultar los detalles de la cuenta utilizados en la coincidencia
Base de datos - Utilizado para la concesión de licencias y el registro de mensajes
Kafka - Utilizado por VoP para almacenar el archivo de procesamiento

Configuración y Tiempo de Ejecución

La Verificación del Beneficiario (VoP) es una aplicación independiente que puede ejecutarse como un servicio, al igual que cualquier otro IPF application despliegue. El VoP El servicio Responder puede ejecutarse como una única instancia o múltiples.

Configuración

La configuración de docker compose a continuación es la mínima requerida para el VoP Servicio de respuesta para ejecutarse utilizando Kafka para el registro de mensajes y MongoDB para la concesión de licencias.

VoPResponder no requiere un Akka Cluster a ser configurado.

ipf {
  mongodb.url = "mongodb://ipf-mongo:27017/vop"  (1)
}

common-kafka-client-settings {
  bootstrap.servers = "kafka:9092" (2)
}

akka {
  kafka {
    producer {
      kafka-clients = ${common-kafka-client-settings}
    }
    consumer {
      kafka-clients = ${common-kafka-client-settings}
      kafka-clients.group.id = vop-responder-consumer-group
    }
  }
}

ipf.verification-of-payee.responder {
  name-match { (3)
    thresholds = [
      {
        processing-entity = "default",
        scorings: [
          {type: "default", lowerbound = 0.80, upperbound = 0.90}
        ]
      }
    ]
  }
  account-management.http.client {
    host = account-management-sim (4)
    port = 8080
  }
  country-filtering.enabled = true (5)
  scheme-allowed-countries = [
    {
      scheme: EPC, (5)
      regulatory-date-timezone: "Europe/Berlin" (5)
      allowed-countries: [
        {country-code: "de", regulatory-date: "2026-09-17"}, (5)
        {country-code: "fr"}
      ]
    }
  ]
}

identity-resolution.comparison.netowl {
  default {
    http.client {
      host = netowl-namematcher (6)
      port = 8080
    }
  }
  table {
    http.client {
      host = netowl-namematcher (6)
      port = 8080
    }
  }
}

Tenga en cuenta los siguientes aspectos clave:

1	Establezca el MongoDB URL según corresponda a su entorno
2	Establezca el Kafka URL según corresponda a su entorno
3	Establezca el Coincidencia de Nombres umbrales requeridos para su implementación
4	Establezca el Gestión de Cuentas nombre de host y puerto según corresponda a su entorno
5	Establezca el Filtrado por País y defina qué códigos de país están permitidos para cada esquema con fecha y hora regulatoria opcional y zona horaria.
6	Establezca el Resolución de Identidad NetOwl nombre de host y puerto según corresponda a su entorno

Ejecutando

Docker Componer

El siguiente docker compose es un VoP Despliegue del servicio Responder que contiene toda la infraestructura/aplicaciones requeridas (Kafka,MongoDB, NetOwl, Gestión de Cuentas) necesaria para ejecutar el VoP Aplicación de respuesta. Esta implementación de muestra se está ejecutando con Kafka para el registro de mensajes y MongoDB para la concesión de licencias.

Esto representa una configuración de muestra y no está destinado a representar preocupaciones de rendimiento o resiliencia, las cuales se abordarán en otra sección en futuras versiones.

Docker Compose

services:

  # Infrastructure
  ipf-mongo:
    image: ${docker.registry}/ipf-docker-mongodb:latest
    container_name: ipf-mongo
    ports:
      - "27018:27017"
    healthcheck:
      test: echo 'db.runCommand("ping").ok' | mongo localhost:27017/test --quiet

  kafka:
    image: apache/kafka-native:4.0.0
    container_name: kafka
    ports:
      - "9092:9092"
      - "9093:9093"
    environment:
      - KAFKA_NODE_ID=1
      - KAFKA_AUTO_CREATE_TOPICS_ENABLE=true
      - KAFKA_CONTROLLER_QUORUM_VOTERS=1@localhost:9094
      - KAFKA_CONTROLLER_LISTENER_NAMES=CONTROLLER
      - KAFKA_PROCESS_ROLES=broker,controller
      - KAFKA_LOG_RETENTION_MINUTES=10
      - KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR=1
      - KAFKA_OFFSETS_TOPIC_NUM_PARTITIONS=1
      - KAFKA_LISTENERS=PLAINTEXT://:9092,LOCAL://:9093,CONTROLLER://:9094
      - KAFKA_LISTENER_SECURITY_PROTOCOL_MAP=LOCAL:PLAINTEXT,PLAINTEXT:PLAINTEXT,CONTROLLER:PLAINTEXT
      - KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://kafka:9092,LOCAL://localhost:9093
      - KAFKA_CREATE_TOPICS=MESSAGE_LOG:1:1,PROCESSING_ARCHIVE:1:1

  # Apps
  account-management-sim:
    image: ${docker.registry}/account-management-simulator:${project.version}
    container_name: account-management-sim
    ports:
      - "8082:8080"
      - "55555:55555"
      - "5006:5005"
    volumes:
      - ${docker-logs-directory}:/ipf/logs
      - ./config/account-management-sim:/account-management-simulator/conf
    user: "1000:1000"
    healthcheck:
      test: [ "CMD", "curl", "-f", "http://localhost:55555/statistics" ]
      interval: 1s
      timeout: 1s
      retries: 90

  netowl-namematcher:
    image: ${docker.registry}/netowl-namematcher:4.9.5.2
    container_name: netowl-namematcher
    ports:
      - "8081:8080"
    volumes:
      - ./config/netowl-namematcher:/var/local/netowl-data/
    healthcheck:
      test: [ "CMD", "curl", "-f", "http://localhost:8080/api/v2" ]
      interval: 1s
      timeout: 1s
      retries: 90

  vop-responder-app:
    image: ${docker.registry}/verification-of-payee-responder-application:${project.version}
    container_name: vop-responder-app
    ports:
      - "8080:8080"
      - "5005:5005"
    volumes:
      - ${docker-logs-directory}:/ipf/logs
      - ./config/vop-responder-app:/verification-of-payee-responder-application/conf
    user: "1000:1000"
    environment:
      - IPF_JAVA_ARGS=-Dma.glasnost.orika.writeClassFiles=false -Dma.glasnost.orika.writeSourceFiles=false -Dconfig.override_with_env_vars=true
    depends_on:
      - ipf-mongo
      - kafka
    healthcheck:
      test: [ "CMD", "curl", "http://localhost:8080/actuator/health" ]

Tenga en cuenta los siguientes aspectos clave:

MongoDBy Kafka los contenedores son imágenes de terceros y no son proporcionadas por Icon Soluciones
El Simulador de Gestión de Cuentas se ha añadido con fines ilustrativos y no es proporcionado por Icon Soluciones pero debería ser un customer implementación conforme a la API de Gestión de Cuentas
El NetOwl la imagen anterior es un contenedor de terceros no suministrado por Icon Las soluciones y actualmente está siendo utilizadas por el Servicio de Resolución de Identidad, que se está ejecutando embebido en el VoP Aplicación Responder. Para más detalles sobre esto, por favor revise el Resolución de Identidad documentación. Si ya existe una instancia separada en el customer entorno, cualquier customisations debe ser reaplicado aquí si se utiliza una nueva imagen.
El VoP La aplicación Responder es creada por Icon Soluciones y alojadas en nuestro ipf-lanzamientos repositorio en Nexus.

Kubernetes

El siguiente Kubernetes la configuración es un VoP Despliegue del servicio Responder que contiene la configuración recomendada para desplegar un VoP Aplicación de respuesta. Esta implementación de muestra se está ejecutando con Kafka para el registro de mensajes.

Esto representa una configuración de muestra y no está destinado a representar preocupaciones de rendimiento que se tratarán en otra sección en futuras versiones.

Configmap

apiVersion: v1
kind: ConfigMap
metadata:
  name: responder-config
  labels:
    app: verification-of-payee-responder
    product: ipfv2
data:
  application.conf: |
    ipf.mongodb.url = "mongodb://mongo:27017/vop"
    server.port = 8081
    
    identity-resolution.comparison.netowl {
      default {
        http.client {
          host = localhost
          port = 8080
        }
      }
      table {
        http.client {
          host = localhost
          port = 8080
        }
      }
    }
    
    ipf.verification-of-payee.responder {
      name-match {
        thresholds = [
          {
            processing-entity = "default",
            scorings: [
              {type: "default", lowerbound = 0.80, upperbound = 0.90}
            ]
          }
        ]
      }
      account-management.http.client {
        host = account-management
        port = 8080
      }
      country-filtering.enabled = true
      scheme-allowed-countries = [
        {
          scheme: EPC,
          regulatory-date-timezone: "Europe/Berlin"
          allowed-countries: [
            {country-code: "de", regulatory-date: "2026-09-17"},
            {country-code: "fr"}
          ]
        }
      ]
    }
    
    common-kafka-client-settings {
      bootstrap.servers = "kafka:9092"
    }
    akka {
      kafka {
        producer {
          kafka-clients = ${common-kafka-client-settings}
        }
        consumer {
          kafka-clients = ${common-kafka-client-settings}
          kafka-clients.group.id = vop-responder-consumer-group
        }
      }
    }

  license.key: |-
    {
      "product":"NameMatcher",
      "type":"Development",
      "thread limit":1,
       "*":{
          "lifespan":[ "2022-01-01 00:00Z", "2026-01-01 00:00Z" ],
          "features":[ "Latin" ]
       },
      "verification":<hidden>
    }

Despliegue

apiVersion: apps/v1
kind: Deployment
metadata:
  name: verification-of-payee-responder-application
  labels:
    app: verification-of-payee-responder-application
    product: ipfv2
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  selector:
    matchLabels:
      app: verification-of-payee-responder-application
      product: ipfv2
  template:
    metadata:
      labels:
        app: verification-of-payee-responder-application
        product: ipfv2
    spec:
      imagePullSecrets:
        - name: registry-credentials
      terminationGracePeriodSeconds: 10
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: app
                      operator: In
                      values:
                        - verification-of-payee-responder-application
                topologyKey: "kubernetes.io/hostname"
      containers:
        - name: verification-of-payee-responder-application
          image: registry.ipf.iconsolutions.com/verification-of-payee-responder-application:latest
          ports:
            - containerPort: 8081
              name: server-port
            - containerPort: 5005
              name: debug-port

          env:
            - name: "IPF_JAVA_ARGS"
              value: "-Dma.glasnost.orika.writeClassFiles=false -Dma.glasnost.orika.writeSourceFiles=false"

          livenessProbe:
            httpGet:
              path: /actuator/health
              port: "server-port"
              scheme: HTTP
            initialDelaySeconds: 60
            periodSeconds: 5
            timeoutSeconds: 1
            failureThreshold: 3
            successThreshold: 1

          readinessProbe:
            httpGet:
              path: /actuator/health
              port: server-port
              scheme: HTTP
            initialDelaySeconds: 60
            periodSeconds: 5
            timeoutSeconds: 1
            failureThreshold: 3
            successThreshold: 1

          startupProbe:
            httpGet:
              path: /actuator/health
              port: server-port
              scheme: HTTP
            failureThreshold: 30
            periodSeconds: 10

          volumeMounts:
            - name: application-config
              mountPath: /verification-of-payee-responder-application/conf/application.conf
              subPath: application.conf

        - name: netowl-namematcher
          image: registry.ipf.iconsolutions.com/netowl-namematcher:latest
          imagePullPolicy: IfNotPresent

          ports:
            - containerPort: 8080
              name: netowl-port

          livenessProbe:
            httpGet:
              path: /api/v2/healthy
              port: 8080
            initialDelaySeconds: 15
            timeoutSeconds: 2
            periodSeconds: 5

          volumeMounts:
            - name: netowl-data
              mountPath: /var/local/netowl-data
            - name: application-config
              mountPath: /var/local/netowl-data/license.key
              subPath: license.key


      volumes:
        - name: application-config
          configMap:
            name: responder-config
        - name: netowl-data
          emptyDir: {}

Servicio

apiVersion: v1
kind: Service
metadata:
  name: verification-of-payee-responder-application
spec:
  selector:
    app: verification-of-payee-responder-application
  ports:
    - protocol: TCP
      port: 8081
      targetPort: 8081
      name: server-port

Tenga en cuenta los siguientes aspectos clave:

Servicios de infraestructura como Kafka y MongoDB no se han proporcionado en la configuración anterior y no suministrados por Icon Soluciones.
El NetOwl la imagen anterior es un contenedor de terceros no suministrado por Icon Las soluciones y actualmente está siendo utilizadas por el Servicio de Resolución de Identidad, que se está ejecutando embebido en el VoP Responder app. Para más detalles sobre esto, por favor revise el Resolución de Identidad documentación. Si ya existe una instancia separada en el customer entorno, cualquier customisations debe ser reaplicado aquí si se utiliza una nueva imagen.
El VoP La aplicación Responder es creada por Icon Soluciones y alojadas en nuestro ipf-lanzamientos repositorio en Nexus.
El número de réplicas se ha establecido en 3 por razones de balanceo de carga.
Se han configurado las sondas de Liveness, Readiness y Startup para apoyar la estabilidad de nodos y pods, pero estas pueden ser modificadas si es necesario.
La anti-afinidad de pods ha sido configurada para distribuir los pods a través de múltiples nodos para prevenir un único punto de falla.

Ajuste de Rendimiento

Errores al Llamar a Servicios Externos

Puede encontrar errores si hay un alto número de VoP solicitudes que resultan en un número correspondiente alto de HTTP solicitudes que se están realizando a la VoP servicios aguas abajo. Esto también puede ocurrir si los servicios aguas abajo son simplemente lentos para responder a las solicitudes, causando un retraso en las solicitudes.

Akka HTTP

--HTTP Connector Transport usos Akka HTTP, las solicitudes utilizan las conexiones disponibles de la Akka HTTP pool de conexiones para realizar un nativo HTTP solicitud.

Akka HTTP - Desbordamiento de la piscina y la configuración de max-open-requests la página explica las posibles causas con más detalle y sugiere ajustar el Akka HTTP configúrelo como se muestra a continuación.

akka.http.host-connection-pool.max-connections = 64
akka.http.host-connection-pool.max-open-requests = 512

Los valores predeterminados se pueden encontrar aquí:https://doc.akka.io/libraries/akka-http/current/client-side/configuration.html[Akka HTTP - Configuración Predeterminada del Grupo de Clientes]

Los números utilizados son solo para referencia y no son cifras recomendadas. La cifra real debe ser determinada en función de pruebas realizadas en un entorno realista donde usted observó originalmente que ocurrían los errores.

Errores de Inicio

VoPResponder requiere una conexión a la base de datos durante el inicio de la aplicación, independientemente del tipo de registro de mensajes configurado, debido a Licenciamiento de IPF. Si la aplicación no puede conectarse a la base de datos durante el inicio, se marcará como no saludable. Continuará intentando reconectarse, y una vez que se establezca una conexión con éxito, la aplicación pasará a un estado saludable. Todos los fallos de conexión y los intentos de reintento se registrarán en el registro de la aplicación en el WARN nivel.

Cuando kafka se selecciona como el tipo de registro de mensajes, la aplicación también intentará conectarse a Kafka al iniciar. Sin embargo, la falta de conexión a Kafka se registrará pero no afectará el estado de salud de la aplicación por defecto. Esto es para evitar que el registro de mensajes se detenga. VoP solicitudes en proceso.

Si se considera crítico el registro de mensajes y Kafka los problemas de conectividad deben afectar la salud y la funcionalidad principal de la aplicación, puede habilitar este comportamiento configurando:

message.logger.send-connector.resiliency-settings.enabled = true

Si la base de datos se vuelve inaccesible después de la VoP Responder ha comenzado, luego el VoP El servicio de Responder dejará de estar disponible.