Disponible · Open to all France
Comment j'aborde la conception de systemes microservices — decompose a travers un projet reel : une plateforme bancaire composee de 10 services Spring Boot sur AWS.
gitlab.com/bank-platform — lisons ensemble ce qui est implemente, pas ce qu'on suppose.
Environnement de production reel — pas de staging, pas de simulation. L'instance EC2 tourne en mode economie (s'eteint quand inactive). Si vous tapez et que rien ne repond, c'est simplement coupe. Tentez votre chance ci-dessous.
/* This is a live production probe. // The EC2 instance runs on economy mode — it boots on-demand and shuts down after use. // No uptime guarantee, just raw honesty. */
Press the probe button to send a live GET request
to the production health endpoint.
Dans cette section, je prends un projet existant et je le decompose. Pas de theorie pure — chaque choix d'architecture vient d'un fichier reel (README, Dockerfile, CI/CD). Quand je specule, je le dis. Le reste est documente dans les liens ci-dessus.
Le systeme repose sur 10 services independants, chacun responsable d'un domaine metier precis. Ils communiquent soit de maniere synchrone (HTTP via gateway), soit asynchrone (Kafka pour les events de decouplage).
Synch REST via Gateway
bank-auth (:8081), bank-account (:8083), notification (:8084), reporting (:8085)
Asynchrone Kafka
bank-audit-service, bank-fraud-detection-service, bank-notification
Support
bank-config-service (12-Factor), bank-batch-service (lots)
Toutes les requetes passent par Spring Cloud Gateway (:8080) — le seul point d'entree expose. Elle ne se limite pas au routage :
Synchrone — le client appelle un service via la gateway. Un service peut aussi en appeler un autre directement sur son port.
Asynchrone — Kafka comme bus d'evenements. bank-auth-service emet user.registered, les consumers (audit, fraude, notification) reagissent independamment. Decouplage & resilience.
Keycloak comme serveur IAM/SSO. Connecte a PostgreSQL en JDBC pour persister les realms. Les tokens JWT RS256 sont valides asymetriquement au niveau de la gateway via le endpoint JWKS.
Point notable : en cas d'erreur entre l'insertion JPA et la creation du compte Keycloak, un deleteKeycloakUser() assure la coherence — pas de session serveur, tout est stateless.
Rate limiting sur les routes sensibles : protection brute-force sur /api/auth/**.
Le Dockerfile multi-stage (bank-auth-service) :
Stage 1 — build
maven:3.9-eclipse-temurin-21
→ mvn package -DskipTests
Stage 2 — runtime
eclipse-temurin:21-jre-alpine
→ COPY --from=build app.jar
Image Alpine finale (JRE uniquement — pas de JDK). Le docker-compose.aws.yml orchestre postgres:15, keycloak:23.0 (avec realm import), Kafka + Zookeeper (Confluent 7.5.0), et bank-auth-service depuis ECR.
Le pipeline bank-auth-service a 5 stages :
Le job infrastructure/deploy-aws SSH sur EC2, git pull sur le repo infrastructure, login ECR, puis docker compose down + pull + up. Automatise de bout en bout — zero deploiement a la main.
Spring Cloud Gateway, Java 21, Spring Boot 4
REST derriere la gateway ; Kafka pour les evenements
PostgreSQL 15, profils utilisateur cote auth
Keycloak , OAuth2, rate limit sur /api/auth
Tout le trafic externe passe par Spring Cloud Gateway : JWT, rate limit, circuit breaker, correlation ID.
Routage par path : /api/auth, /api/accounts, /api/notifications, /api/reports. Auth et metier separes.
PostgreSQL 15 (authdb), Keycloak sur le meme Postgres en dev/prod via compose. Tokens JWT RS256 cote gateway.
Realm importe au demarrage. Pas de session serveur : validation JWKS. Rollback manuel si incoherence JPA / IAM.
Pipeline GitLab : build, image ECR, SSH vers EC2, git pull sur infrastructure, docker compose up. Pas de deploiement a la main.
docker-compose.aws.yml : Postgres, Keycloak, Kafka/Zookeeper, image bank-auth-service depuis ECR.
Job deploy-aws : SSH vers la VM, git pull sur le repo infrastructure, login ECR, docker compose sur docker-compose.aws.yml.
deploy-aws:
stage: deploy
image: alpine:latest
before_script:
- apk add --no-cache openssh-client aws-cli
- eval $(ssh-agent -s) && ssh-add $SSH_PRIVATE_KEY
script:
- ssh -o StrictHostKeyChecking=no ubuntu@${EC2_HOST} "
export AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID} &&
export AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY} &&
cd /home/ubuntu/infrastructure &&
git pull origin main &&
aws ecr get-login-password ... | docker login ... ${AWS_ECR_REGISTRY} &&
docker compose -f docker-compose.aws.yml down &&
docker compose -f docker-compose.aws.yml pull &&
docker compose -f docker-compose.aws.yml up -d &&
docker system prune -af"
only:
- mainPostgres, Keycloak (realm import), image auth depuis ECR, Kafka + Zookeeper. Aligne avec le fichier du repo.
services:
postgres: postgres:15
keycloak: quay.io/keycloak/keycloak:23.0
command: start-dev --import-realm
volumes: ./realm-export.json:/opt/keycloak/.../import/realm.json
bank-auth-service:
image: ${AWS_ECR_REGISTRY}/bank-auth-service:latest
environment:
SPRING_DATASOURCE_URL: jdbc:postgresql://postgres:5432/authdb
KEYCLOAK_ISSUER_URI: http://keycloak:8080/realms/bank-app
SPRING_KAFKA_BOOTSTRAP_SERVERS: kafka:9092
depends_on: [postgres, keycloak, kafka]
zookeeper: confluentinc/cp-zookeeper:7.5.0
kafka: confluentinc/cp-kafka:7.5.0
KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092
volumes:
postgres_data:Chaque service a son propre README, son Dockerfile et son pipeline CI. Les diagrams ci-dessus viennent directement de cette documentation.