Noms des auteurs :

• De Henau Dudley
• Gendebien Jonas
• Clarembaux Robin

Date de réalisation : mai 2025

Expliquez comment vous avez divisé votre infrastructure en différents micro-services, en illustrant par un schéma.

J'ai créé 3 micro-services pour tester :

• api
• api_produits
• api_etc

Tout est routé vers api, sauf :

• /products/NOM_DU_PRODUIT pour ajouter un produit (route avec paramètre)
• /products/last pour obtenir le dernier produit (route sans paramètre)

Cela m’a permis de tester les deux types de routes.

J'ai ajouté 2 autres services api_produits et api_etc en utilisant la même image Docker, mais lancés comme des services différents dans le docker-compose.yml.

J'ai modifié le fichier de configuration de reverse proxy pour ajouter les redirections vers les différents services API.

server {
    listen 8080;

    # Route spécifique prioritaire : /api/products/last
    location ^~ /api/products/last {
        proxy_pass http://api_produits:5000/api/products/last;
    }

    # Route générique pour les produits avec paramètre
    location ~ ^/api/products/(.*) {
        proxy_pass http://api_produits:5000/api/products/$1;
    }

    # Redirection des autres appels API
    location /api {
        proxy_pass http://api:5000;
    }

    # Redirection du trafic vers le frontend
    location / {
        proxy_pass http://front:80;

        # Limitation du débit pour simuler une situation de trafic élevé
        limit_rate 300k;
    }
}

Nous avons utilisé RabbitMQ comme système de messagerie asynchrone dans notre architecture microservices Docker Swarm.

• Le service api expose une route GET /api/orders/do?order=...
• Cette route publie un message dans une file orders via RabbitMQ
• Le message contient l’ID de commande et le produit commandé, au format UUID:nom_du_produit
• Un worker dédié écoute cette file et traite chaque commande indépendamment

rabbitmq:
  image: rabbitmq:3-management
  ports:
    - "15672:15672"
  networks:
    - woody-net

• Le nom du service RabbitMQ doit être accessible dans le réseau Swarm (host='rabbitmq')
• L’interface Web est exposée sur le port 15672 pour vérification et debug

• Nous avons ajouté du code Python pour publier le message dans RabbitMQ lors de l’appel à /api/orders/do

• Création d’un service worker séparé qui consomme les messages de la queue orders
• Ce worker appelle la fonction process_order() existante pour simuler un traitement métier (validation, DB...)

• Rate limiting configuré dans Nginx :

  • limit_req_zone $binary_remote_addr zone=client_ip_10rs:1m rate=1r/s;
  • limit_req_zone $http_apikey zone=apikey_200rs:1m rate=200r/s;

• Application combinée dans les endpoints critiques :

  • limit_req zone=client_ip_10rs burst=5 nodelay;
  • limit_req zone=apikey_200rs burst=20 nodelay;

• Réponse HTTP en cas d'abus : 429 Too Many Requests

• Test syntaxique : nginx -t

• Tests de charge :

  • ab -n 100 -c 5 http://54.36.180.56/api/ping

• Vérification comportementale via Postman et navigateurs