Le Traffic Distributor (TD) est une couche de routage qui se place devant deux environnements ou plus et partage le trafic entrant entre eux selon des règles que vous définissez. Les trois motifs ci-dessous sont ceux pour lesquels il a été conçu.
Déploiement blue/green
Deux environnements portent la même application — un sert le trafic live (blue), l’autre est préparé avec la prochaine version (green). TD pointe tout le trafic vers blue pendant que vous montez green et le validez. Quand vous basculez la règle, chaque requête commence à atteindre green.
Le bénéfice : mise en production sans coupure avec un chemin de rollback instantané. Si green se comporte mal, ramener le primaire de TD vers blue est un seul clic — pas de propagation DNS, pas de reconnexion client au-delà de ce que la couche proxy gère déjà.
C’est la raison la plus fréquente d’installer TD. La bascule est le moment le plus délicat d’une mise en production, et TD la transforme en décision de routage plutôt qu’en événement de déploiement.
Protection par bascule
Deux environnements, souvent dans des régions différentes ou sur des empreintes matérielles différentes. TD traite l’un comme primaire et l’autre comme secours, avec une vérification de santé sur le primaire. Quand le primaire cesse de répondre, TD déplace le trafic vers le secours.
Le bénéfice : tolérance aux pannes de classe matérielle — dégradation de région, défaut d’hôte, voisin bruyant. Votre application continue de servir depuis le secondaire pendant que vous enquêtez sur le primaire.
Combinez ce motif avec le clonage d’environnement pour garder le secours synchronisé — le document Intégration du Traffic Distributor déroule la topologie.
Tests A/B
Deux environnements, deux versions de l’application. TD partage le trafic entrant selon un ratio — 95/5, 50/50, ce que vous définissez — pour comparer les deux versions sur le trafic live.
Le bénéfice : mise en production expérimentale avec signal statistique. Vous mesurez la conversion, la latence, le taux d’erreur ou toute métrique applicative sur les deux branches et décidez de déployer la nouvelle version à 100 %.
La même mécanique couvre les déploiements canari — commencer à 1 % sur la nouvelle version, monter en cadence en surveillant les tableaux de bord.
Ce que ces motifs partagent
Les trois sont des variations du même primitif : TD connaît deux backends ou plus, et décide par requête (ou par session client) quel backend reçoit la requête. La différence porte sur la façon dont la décision est configurée :
- Blue/green — routage un-parmi-deux, vous actionnez l’interrupteur
- Bascule — un primaire, un secours, la vérification de santé actionne l’interrupteur
- A/B — les deux backends servent simultanément, un ratio décide qui obtient quoi
Une fois le primitif compris, les motifs sont interchangeables — un blue/green peut se piloter en canari en réglant un ratio intermédiaire, un A/B peut être promu en bascule complète en mettant le ratio à 100/0, etc.
Intégrer à une application en cours d’exécution
Le plus délicat dans l’adoption de TD n’est pas le routage lui-même — c’est de réorganiser le point d’entrée d’une application déjà en service sans perdre de trafic live. Le document Intégration du Traffic Distributor couvre les deux chemins valides : swap-domains quand l’application utilise un CNAME ou ANAME, swap-public-IPs quand elle utilise un enregistrement A.