Konfiguration der Microservices

Die Backend Microservices nutzen intern üblicherweise die gleichen Technologien und können deshalb meist über die gleichen Konfigurationsparameter gesteuert werden. Die folgenden Abschnitte beschreiben allgemeine Konfiguration, die für die meisten Microservices gültig ist.

Konfigurationsdateien

Die Konfiguration der Microservices erfolgt über die Datei application.properties oder alternativ über application.yml. Die Datei kann in das Docker Image gemountet werden.

Die Dateien unterscheiden sich leicht in der Syntax, Beispiel:

application.properties

logging.level.root=INFO

application.yml

logging:
    level:
        root: INFO

Bei yml-Dateien ist auf die korrekte Einrückung zu achten.

Zu jeder Property gibt es alternativ auch eine äquivalente Umgebungsvariable.

Default Konfiguration

Die Microservices bringen für viele der folgenden Konfigurationen Default-Einstellungen mit, die ohne weitere Konfiguration angewendet werden.

Log-Level

Das Log-Level kann wie folgt konfiguriert werden:

logging.level.root=INFO

Mögliche Werte sind DEBUG, INFO, WARN und ERROR.

REST API

Der nach außen freigegebene Port kann wie folgt konfiguriert werden:

server.port=8080

Der Context-Path der REST-Endpunkte kann wie wie folgt angepasst werden:

server.servlet.contextPath=/aep-as4-address-service

Absicherung per oauth2

Die Keycloak Anbindung wird wie folgt konfiguriert:

keycloak:
  enabled: true
  auth-server-url: https://blue-energy.de/keycloak/auth
  realm: aep
  resource: b2b-message-service

Über diese Konfiguration wird die REST-API per oauth2 abgesichert. D.h. ein Client muss bei jeder Anfrage ein gültiges Token mitliefern.

AMQP API von Spring Cloud Stream

Performante Verarbeitung von Lastspitzen

Zur schnellen Verarbeitung von Lastspitzen kann es sinnvoll sein, wenn Consumer Services mehrere Consumer an einer Queue offen halten, auch wenn diese zunächst nicht verwendet werden. Denn das Erzeugen von neuen Consumern ist vergleichsweise aufwendig für einen MessageBroker, sodass deren Skalierung immer nur langsam durchgeführt wird.

Hierzu kann am jeweiligen Binding die folgende Einstellung vorgenommen werden:

spring.cloud.stream.bindings.<binding>.consumer.concurrency=5 # default 1

So werden je Instanz und Queue immer 5 Consumer offen gehalten.

Die Consumer können dynamisch skalieren, passend zur Last. Hierzu kann die maximale Anzahl der Consumer eingestellt werden:

spring.cloud.stream.rabbit.bindings.<binding>.consumer.max-concurrency=50 # default meist 50

Diese Einstellungen erfolgen pro Binding.

Bindings

Das Binding verbindet die Consumer/Producer der Application mit der jeweiligen Queue/Exchange. Die Bindings können über die Application-Properties konfiguriert werden. Neben der Konfiguration der Concurrency (siehe vorheriger Abschnitt) können auch weitere Eigenschaften im Kontext des Frameworks Spring-Cloud-Stream konfiguriert werden.

Es folgt eine Übersicht der Consumer-Bindings der Queues der AS4-Outbound/-Inbound-Marktnachrichten-Verarbeitung:

Service Direction Queue Binding
AS4-Outbound-Market-Message-Service Outbound as4.outbound.request.default consumeOutboundRequestEvent-in-0
AS4-Outbound-Sender Outbound as4.outbound.default consumeSignedEncryptedMessage-in-0
AS4-Crypto-Operations Outbound as4.encrypt.sign.default signAndEncrypt-in-0
AS4-Crypto-Operations Outbound as4.verify.default verify-in-0
AS4-Crypto-Operations Inbound as4.decrypt.verify.default decryptAndVerify-in-0
AS4-Crypto-Operations Inbound as4.sign.default bindings.sign-in-0
AS4-Receipt-Service Outbound as4.receipt.parse.default consumeReceiptEvent-in-0
AS4-Receipt-Service Inbound as4.receipt.create.default consumeDecryptedAs4Message-in-0
AS4-Message-Service Out-/Inbound as4.messages.default consumeBusinessMessageEvent-in-0
AS4-Message-Service Out-/Inbound as4.receipt.default consumeReceiptEvent-in-0
AS4-Inbound-Endpoint Inbound as4.send.receipt. consumeReceipt-in-0
B2B-Message-Service Outbound as4.receipt.outbound.delivery outboundAs4ReceiptConsumer-in-0
B2B-Message-Service Inbound as4.inbound.delivery receivedAs4MessageConsumer-in-0
B2B-Message-Service Outbound b2b.message.default b2bMessageEventConsumer-in-0

Beispiel: wenn der AS4-Outbound-Sender mindestens 20 parallele Consumer an der Queue as4.outbound.default offen halten soll, kann dies wie folgt konfiguriert werden:

spring.cloud.stream.bindings.consumeSignedEncryptedMessage-in-0.consumer.concurrency=20

Begrenzung der maximalen Einträge in einer DLQ

In manchen Fällen und speziellen Dead-Letter-Queues kann es sinnvoll sein, wenn die maximale Anzahl der neusten Einträge begrenzt wird.

Beispiel für einen solchen Fall: Es sind 1:1 Kommunikationen im System hinterlegt, deren Marktpartner MPIDs ungültig sind oder noch keine AS4 Zertifikate haben. Der certificate-manager versucht vergeblich bei jeder (täglicher) Ausführung diese herunterzuladen und schreibt so Einträge in die certificate.download.command.default.dlq, die üblicherweise nicht mehr benötigt werden.

Hierzu kann am jeweiligen Binding die folgende Einstellung vorgenommen werden, wenn z.B. nur die neusten 20 Einträge in der DLQ bleiben sollen. Dies kann ein Überlaufen des RabbitMQ Speichers verhindern.

spring.cloud.stream.bindings.<bindingName>.consumer.dlqmaxlength = 20

Management

Über actuator kann der Status eines Microservice geprüft werden. Actuator kann wie folgt aktiviert werden:

management.endpoints.web.exposure.include=health
management.endpoint.health.show-details=always

Der Management Port kann wie folgt konfiguriert werden:

management.server.port=8081

Da die Management Endpunkte von der Firewall nicht nach draußen freigegeben werden sollten, können weitere Security-Maßnahmen deaktiviert werden:

management.security.enabled=false

Weitere Details hierzu finden Sie hier.

Der server.servlet.contextPath beeinflusst nicht die Endpunkte die über den Management Port freigegeben werden.

Memory

Falls die Java Anwendungen über nicht genug Speicher verfügen, kann dieser per Konfiguration erhöht werden:

JAVA_TOOL_OPTIONS=-XX:MaxDirectMemorySize=200M
View Me   Edit Me