TP010

TP10 : High Scalability on Woodytoys

---

1. Micro-services

Structure des fichiers

TP09-10/
│
├── services/
│   ├── api_misc/
│   ├── api_orders/
│   ├── api_products/
│   ├── database/
│   ├── front/
│   ├── reverse-proxy/
│   ├── build_push.sh
│   └── docker-compose.yml
└── libs/
    └── ...

Adaptation des containers

Dockerfiles créés

• Dockerfile api_misc
• Dockerfile api_orders
• Dockerfile api_products

Configuration Docker Compose

api_misc:
  image: pasrptheoo/woody_api_misc
  restart: always
  networks:
    woody_net:
      aliases:
        - api_misc
  deploy:
    replicas: 1

api_orders:
  image: pasrptheoo/woody_api_orders
  restart: always
  networks:
    woody_net:
      aliases:
        - api_orders
  deploy:
    replicas: 1

api_products:
  image: pasrptheoo/woody_api_products
  restart: always
  networks:
    woody_net:
      aliases:
        - api_products
  deploy:
    replicas: 1

Configuration Nginx

La configuration Nginx a été modifiée pour router les requêtes vers les micro-services appropriés selon leur URL :

server {
  listen 8080;

  location /api/misc {
    proxy_pass http://api_misc:5000/;
  }
  
  location /api/orders {
    proxy_pass http://api_orders:5000/;
  }
  
  location /api/products {
    proxy_pass http://api_products:5000/;
  }

  location /api/ {
    proxy_pass http://api_misc:5000/;
  }

  location / {
    proxy_pass http://front:80;
    # Limitation pour simuler un trafic élevé
    limit_rate 300k;
  }
}

---

2. Communication Asynchrone

Implémentation avec Redis Pub/Sub

Au lieu de RabbitMQ, l'équipe a opté pour Redis en mode Pub/Sub pour gérer le traitement asynchrone des commandes longues.

Flux de communication

Émetteur : api_orders

• Qui émet : Service api_orders
• Quand : Dès qu'une commande est créée
• Canal : orders
• Contenu : JSON avec order_id et nom du produit

Récepteur : api_products

• Qui reçoit : Service api_products
• Comment : Thread d'écoute en arrière-plan
• Action : Validation coûteuse puis sauvegarde

Configuration Redis

redis:
  image: redis:latest
  networks:
    woody_net:
      aliases:
        - redis
  deploy:
    replicas: 3

Modifications du code

Dans api_orders

# Avant (synchrone)
- process_order(order_id, product)

# Après (asynchrone)
+ r.publish("orders", json.dumps({
+   "order_id": order_id,
+   "order": product
+ }))

Dans api_products

def listen_for_orders():
    pubsub = redis_client.pubsub()
    pubsub.subscribe('orders')
    for msg in pubsub.listen():
        if msg['type'] == 'message':
            data = json.loads(msg['data'])
            process_order(data["order_id"], data["order"])

---

3. API Gateway

Protection contre l'utilisation abusive

La protection est assurée par rate limiting au niveau Nginx :

Configuration

limit_req_zone $binary_remote_addr zone=gateway:1m rate=5r/s;
limit_req zone=gateway;
limit_req_status 429;

Fonctionnement

• Limite : 5 requêtes par seconde par adresse IP
• Action : Code 429 (Too Many Requests) en cas de dépassement
• Objectif : Préserver la disponibilité contre les pics de trafic et attaques DDoS

Procédure de validation

Test avec délai normal (0.2s)

for i in {1..10}; do 
  curl -s -o /dev/null -w "%{http_code}\n" -L http://localhost:8080/api/ping
  sleep 0.2
done

Résultat : Toutes les requêtes passent (200)

200
200
200
200
200
200
200
200
200
200

Test avec délai réduit (0.1s) - Dépassement du rate limit

for i in {1..10}; do 
  curl -s -o /dev/null -w "%{http_code}\n" -L http://localhost:8080/api/ping
  sleep 0.1
done

Résultat : Alternance entre succès et rate limiting

200
429
200
429
200
429
200
429
200
429