Architecture Microservices¶

C'est quoi un microservice ?¶

Explication simple : Imaginez un centre commercial. Au lieu d'avoir un seul grand magasin qui vend de tout, on a plusieurs boutiques indépendantes côte à côte. Si une boutique ferme ou change son assortiment, les autres continuent de fonctionner normalement. C'est exactement comme ça que fonctionne l'architecture microservices.

Dans notre projet, chaque site (Group, Tech, Immo) est un service indépendant. Chacun peut :

✅ Être démarré ou arrêté séparément
✅ Utiliser sa propre technologie
✅ Être déployé (mis en ligne) indépendamment
✅ Avoir sa propre base de données si nécessaire
✅ Évoluer sans impacter les autres services

Microservices vs Monolithe — comparaison¶

graph TB
    subgraph Monolithe["❌ Architecture Monolithe (une seule app)"]
        M[Application unique\nTout dans le même code\nUn seul déploiement\nErreur = tout tombe]
    end

    subgraph Micro["✅ Architecture Microservices (Darewatch)"]
        S1[drwh_group\nLaravel]
        S2[drwh_tech\nNext.js]
        S3[drwh_immo\nNext.js]
        S1 -.Indépendant.- S2
        S2 -.Indépendant.- S3
    end

    style Monolithe fill:#ffebee,stroke:#e74c3c
    style Micro fill:#e8f5e9,stroke:#27ae60
    style M fill:#e74c3c,color:#fff
    style S1 fill:#27ae60,color:#fff
    style S2 fill:#27ae60,color:#fff
    style S3 fill:#27ae60,color:#fff

Critère	Monolithe	Microservices (Darewatch)
Déploiement	Un seul déploiement pour tout	Chaque service se déploie séparément
Panne	Si une erreur survient, tout tombe	Une panne sur immo n'affecte pas tech
Scalabilité	On scale tout même si seulement une partie est surchargée	On scale uniquement le service surchargé
Technologies	Une seule technologie pour tout	Chaque service choisit sa technologie
Équipes	Toute l'équipe sur le même code	Chaque équipe travaille sur son service

Architecture complète de DAREWATCH¶

graph TD
    User([👤 Visiteur]) --> GW[🔀 Nginx Gateway\nReverse Proxy\nPort 80 / 443]

    GW -->|darewatchgroup.com| G[🏠 drwh_group\nLaravel/PHP\nPort 3001]
    GW -->|tech.darewatchgroup.com| T[💻 drwh_tech\nNext.js\nPort 3003]
    GW -->|immo.darewatchgroup.com| I[🏗️ drwh_immo\nNext.js\nPort 3002]

    G -->|REST/JSON| API[🔧 API Backend\nhttp://api.darewatch.com]
    T -->|REST/JSON| API
    I -->|REST/JSON| API

    API --> DB[(🗄️ Base de données)]

    style User fill:#e8f4f8,stroke:#2196F3
    style GW fill:#2d2e2e,color:#fff,stroke:#555
    style G fill:#e74c3c,color:#fff
    style T fill:#0066FF,color:#fff
    style I fill:#27ae60,color:#fff
    style API fill:#8e44ad,color:#fff
    style DB fill:#f39c12,color:#fff

Flux d'une requête utilisateur¶

Lorsqu'un visiteur accède à tech.darewatchgroup.com, voici ce qui se passe :

sequenceDiagram
    participant U as 👤 Visiteur
    participant N as 🔀 Nginx
    participant T as 💻 drwh_tech
    participant A as 🔧 API Backend

    U->>N: GET https://tech.darewatchgroup.com/services
    N->>T: Redirige vers drwh_tech:3003
    T->>A: GET /api/v1/services
    A-->>T: JSON { services: [...] }
    T-->>N: Rendu HTML de la page services
    N-->>U: Page HTML finale

Pourquoi cette architecture pour Darewatch ?¶

!!! success "Avantages concrets" - L'équipe immo peut mettre à jour le catalogue immobilier sans toucher au site tech - Si le site immo a une panne, le site tech reste opérationnel - On peut scaler (augmenter les ressources de) uniquement le service le plus sollicité - Chaque service peut utiliser la technologie qui lui convient le mieux

!!! warning "Points d'attention" - La communication entre services se fait via l'API (couplage léger) - Il faut maintenir une API contract claire entre les équipes - Le déploiement est légèrement plus complexe (d'où Docker et Nginx)

Les ports de chaque service en local¶

Service	URL locale	Port
drwh_group	http://localhost:8002	8000 / 8002
drwh_tech	http://localhost:4201	4201
drwh_immo	http://localhost:4200	4200
API Backend	http://localhost:3000/api	3000