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