feat(build): Refactor infrastructure modules and establish single source of truth
This commit introduces a major refactoring of the build system and the core infrastructure modules. The primary goal is to establish a strict "Single Source of Truth" for all dependencies using Gradle Version Catalogs and to create a clean, maintainable, and scalable foundation for all current and future services. ### 1. Centralized Dependency Management (`libs.versions.toml`) - **Established Single Source of Truth:** All dependency versions are now exclusively managed in `gradle/libs.versions.toml`. Hardcoded versions have been removed from all build scripts. - **Introduced Gradle Bundles:** To simplify module dependencies, several bundles have been created (e.g., `testing-jvm`, `redis-cache`, `spring-cloud-gateway`, `monitoring-client`). This drastically reduces boilerplate in the `build.gradle.kts` files and improves readability. - **Cleaned up Aliases:** All library and plugin aliases have been standardized for consistency. ### 2. Infrastructure Module Refactoring All infrastructure modules (`core`, `platform`, `auth`, `cache`, `event-store`, `messaging`, `monitoring`, `gateway`) have been refactored to align with the new dependency management strategy. - **Simplified Build Scripts:** The `build.gradle.kts` for each module now uses the new bundles and aliases, making them significantly cleaner and easier to understand. - **Consistent Structure:** The architecture of each module now clearly follows the Port-Adapter pattern where applicable (e.g., `cache-api`/`redis-cache`). - **Standardized `platform-bom`:** The project's own Bill of Materials (`platform-bom`) now also includes the Spring Cloud BOM, ensuring version consistency for all Spring-related dependencies. ### 3. Added Infrastructure Documentation To improve onboarding and architectural understanding, a dedicated `README-*.md` file has been created for each refactored infrastructure module: - `README-CORE.md` - `README-PLATFORM.md` - `README-INFRA-AUTH.md` - `README-INFRA-CACHE.md` - `README-INFRA-EVENT-STORE.md` - `README-INFRA-MESSAGING.md` - `README-INFRA-MONITORING.md` - `README-INFRA-GATEWAY.md` These documents explain the purpose, architecture, and usage of each component within the system. This lays the groundwork for our "Tracer Bullet" development approach.
This commit is contained in:
stefan
@@ -0,0 +1,49 @@
|
||||
# Infrastructure/Monitoring Module
|
||||
|
||||
## Überblick
|
||||
|
||||
Das **Monitoring-Modul** ist die Grundlage für die **Observability** (Beobachtbarkeit) der gesamten Meldestelle-Systemlandschaft. In einer verteilten Microservice-Architektur ist es unerlässlich, Einblicke in das Verhalten, die Leistung und die Gesundheit der einzelnen Dienste zu haben. Dieses Modul stellt die Werkzeuge für zwei der drei Säulen der Observability bereit: **Metriken** und **Distributed Tracing**.
|
||||
|
||||
* **Metriken:** Quantitative Daten über die Leistung von Services (z.B. CPU-Auslastung, Antwortzeiten, Fehlerraten).
|
||||
* **Distributed Tracing:** Verfolgung einer einzelnen Anfrage über mehrere Service-Grenzen hinweg, um Engpässe und Fehlerquellen zu identifizieren.
|
||||
|
||||
## Architektur
|
||||
|
||||
Das Modul ist in eine wiederverwendbare Client-Bibliothek und einen zentralen Server aufgeteilt:
|
||||
|
||||
|
||||
infrastructure/monitoring/
|
||||
├── monitoring-client/ # Bibliothek, die jeder Service einbindet
|
||||
└── monitoring-server/ # Eigenständiger Service, der den Zipkin-Server hostet
|
||||
|
||||
|
||||
### `monitoring-client`
|
||||
|
||||
Dies ist eine **wiederverwendbare Bibliothek**, die von **jedem einzelnen Microservice** (z.B. `masterdata-service`, `gateway`) als Abhängigkeit eingebunden werden muss.
|
||||
|
||||
* **Zweck:** Instrumentiert den Service automatisch, um Metriken und Traces zu generieren.
|
||||
* **Technologien:**
|
||||
* **Spring Boot Actuator:** Stellt einen `/actuator/prometheus`-Endpunkt bereit, an dem Metriken im Prometheus-Format abgerufen werden können.
|
||||
* **Micrometer:** Eine Fassade für Metriken, die es ermöglicht, Anwendungsmetriken zu sammeln (z.B. HTTP-Request-Zeiten, JVM-Statistiken).
|
||||
* **Brave & Zipkin Reporter:** Instrumentiert den Code für Distributed Tracing und sendet die gesammelten Spans (Teile eines Traces) an den Zipkin-Server.
|
||||
* **Vorteil:** Entwickler müssen sich nicht aktiv um die Implementierung von Monitoring kümmern. Durch das Einbinden dieser Bibliothek erhält jeder Service automatisch grundlegende Observability.
|
||||
|
||||
### `monitoring-server`
|
||||
|
||||
Dies ist ein **eigenständiger Spring Boot Service**, der eine zentrale Komponente des Monitoring-Stacks hostet.
|
||||
|
||||
* **Zweck:** Hostet den **Zipkin-Server** inklusive seiner grafischen Benutzeroberfläche. Alle `monitoring-client`-Instanzen senden ihre Tracing-Daten an diesen Server. Entwickler können dann in der Zipkin-UI die gesamten Anfrage-Flows visualisieren und analysieren.
|
||||
|
||||
## Zusammenspiel im Ökosystem
|
||||
|
||||
Das vollständige Monitoring-Setup besteht aus mehreren Teilen:
|
||||
|
||||
1. Jeder **Microservice** bindet `:infrastructure:monitoring:monitoring-client` ein und stellt Metriken unter `/actuator/prometheus` bereit und sendet Traces an Zipkin.
|
||||
2. Der **`:infrastructure:monitoring:monitoring-server`** empfängt die Traces und stellt die Zipkin-UI zur Verfügung.
|
||||
3. Ein **Prometheus-Server** (definiert in `docker-compose.yml`) ist so konfiguriert, dass er periodisch die `/actuator/prometheus`-Endpunkte aller Microservices abfragt ("scraped") und die Metriken in seiner Zeitreihen-Datenbank speichert.
|
||||
4. Ein **Grafana-Server** (definiert in `docker-compose.yml`) visualisiert die in Prometheus gespeicherten Metriken in anpassbaren Dashboards.
|
||||
|
||||
Diese Kombination aus Micrometer, Prometheus, Zipkin und Grafana bildet einen leistungsstarken, branchenüblichen "Observability Stack".
|
||||
|
||||
---
|
||||
**Letzte Aktualisierung**: 31. Juli 2025
|
||||
@@ -1,26 +1,22 @@
|
||||
// Dieses Modul ist eine wiederverwendbare Bibliothek, die von jedem Microservice
|
||||
// eingebunden wird, um Metriken und Tracing-Daten zu exportieren.
|
||||
plugins {
|
||||
// kotlin("jvm")
|
||||
// kotlin("plugin.spring")
|
||||
|
||||
alias(libs.plugins.kotlin.jvm)
|
||||
alias(libs.plugins.kotlin.spring)
|
||||
|
||||
// KORREKTUR: Dieses Plugin ist entscheidend. Es schaltet den `springBoot`-Block
|
||||
// und alle Spring-Boot-spezifischen Gradle-Tasks frei.
|
||||
alias(libs.plugins.spring.boot)
|
||||
|
||||
// Dependency Management für konsistente Spring-Versionen
|
||||
alias(libs.plugins.spring.dependencyManagement)
|
||||
}
|
||||
|
||||
dependencies {
|
||||
// Stellt sicher, dass alle Versionen aus der zentralen BOM kommen.
|
||||
implementation(platform(projects.platform.platformBom))
|
||||
// Stellt gemeinsame Abhängigkeiten bereit.
|
||||
implementation(projects.platform.platformDependencies)
|
||||
|
||||
implementation("org.springframework.boot:spring-boot-starter-actuator")
|
||||
implementation("io.micrometer:micrometer-registry-prometheus")
|
||||
implementation("io.zipkin.reporter2:zipkin-reporter-brave")
|
||||
implementation("io.zipkin.reporter2:zipkin-sender-okhttp3")
|
||||
implementation("io.micrometer:micrometer-tracing-bridge-brave")
|
||||
// OPTIMIERUNG: Verwendung des `monitoring-client`-Bundles.
|
||||
// Es enthält Spring Boot Actuator, Micrometer Prometheus und Zipkin Tracing.
|
||||
implementation(libs.bundles.monitoring.client)
|
||||
|
||||
// Stellt alle Test-Abhängigkeiten gebündelt bereit.
|
||||
testImplementation(projects.platform.platformTesting)
|
||||
}
|
||||
|
||||
@@ -1,33 +1,32 @@
|
||||
// Dieses Modul ist ein eigenständiger Spring Boot Service, der den
|
||||
// Zipkin-Server mit seiner UI hostet, um Tracing-Daten zu visualisieren.
|
||||
plugins {
|
||||
// kotlin("jvm")
|
||||
// kotlin("plugin.spring")
|
||||
// id("org.springframework.boot")
|
||||
|
||||
alias(libs.plugins.kotlin.jvm)
|
||||
alias(libs.plugins.kotlin.spring)
|
||||
|
||||
// KORREKTUR: Dieses Plugin ist entscheidend. Es schaltet den `springBoot`-Block
|
||||
// und alle Spring-Boot-spezifischen Gradle-Tasks frei.
|
||||
alias(libs.plugins.spring.boot)
|
||||
|
||||
// Dependency Management für konsistente Spring-Versionen
|
||||
alias(libs.plugins.spring.dependencyManagement)
|
||||
|
||||
}
|
||||
|
||||
// Configure main class for bootJar task
|
||||
// Konfiguriert die Hauptklasse für das ausführbare JAR.
|
||||
springBoot {
|
||||
mainClass.set("at.mocode.infrastructure.monitoring.MonitoringServerApplicationKt")
|
||||
}
|
||||
|
||||
dependencies {
|
||||
// Stellt sicher, dass alle Versionen aus der zentralen BOM kommen.
|
||||
implementation(platform(projects.platform.platformBom))
|
||||
// Stellt gemeinsame Abhängigkeiten bereit.
|
||||
implementation(projects.platform.platformDependencies)
|
||||
|
||||
implementation("org.springframework.boot:spring-boot-starter-web")
|
||||
implementation("org.springframework.boot:spring-boot-starter-actuator")
|
||||
implementation("io.micrometer:micrometer-registry-prometheus")
|
||||
implementation("io.zipkin.java:zipkin-server:2.12.9")
|
||||
implementation("io.zipkin.java:zipkin-autoconfigure-ui:2.12.9")
|
||||
// Spring Boot Starter für einen einfachen Web-Service.
|
||||
implementation(libs.spring.boot.starter.web)
|
||||
implementation(libs.spring.boot.starter.actuator)
|
||||
|
||||
// Abhängigkeiten für den Zipkin-Server und seine UI.
|
||||
// OPTIMIERUNG: Versionen werden jetzt zentral über libs.versions.toml verwaltet.
|
||||
implementation(libs.zipkin.server)
|
||||
implementation(libs.zipkin.autoconfigure.ui)
|
||||
|
||||
// Stellt alle Test-Abhängigkeiten gebündelt bereit.
|
||||
testImplementation(projects.platform.platformTesting)
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user