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ächt 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.<bindingName>.consumer.concurrency = 5

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

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