Équilibrage de charge et passerelles

Question centrale

Lorsqu'un seul serveur ne peut plus supporter la charge, comment répartir le trafic de manière « intelligente » vers plusieurs instances de serveurs ? L'équilibrage de charge est le « distributeur » des systèmes distribués modernes. Cet article explore en profondeur la philosophie de conception et les pratiques d'ingénierie de l'équilibrage de charge à travers des cas réels (caisse de salon de thé, tri de colis, circulation routière).

1. Pourquoi « l'équilibrage de charge » ?

1.1 Partons d'un cas réel : l'évolution de l'architecture d'un site web

Une startup a rencontré de graves problèmes de performance lors de la croissance rapide de sa base d'utilisateurs :

Reconstitution du scénario :

Étape 1 : Serveur unique
Utilisateur → Serveur (1 cœur, 2 Go)
       ↓
  1000 utilisateurs actifs/jour → Heures de pointe : 1000 visiteurs simultanés
       ↓
Problème : CPU à 100 %, temps de réponse lent, pannes fréquentes

Le problème fatal du serveur unique

Goulot d'étranglement de performance : CPU à 100 %, temps de réponse > 5 secondes
Point unique de défaillance : si le serveur tombe en panne, tout le site est indisponible
Évolution difficile : seule la mise à niveau verticale est possible (ajouter CPU, mémoire), coûteuse et limitée

Architecture améliorée (avec équilibrage de charge) :

Étape 2 : Serveurs multiples + Équilibreur de charge
Utilisateur → Équilibreur de charge (Nginx)
       ↓
     ├→ Serveur 1 (1 cœur, 2 Go)
     ├→ Serveur 2 (1 cœur, 2 Go)
     └→ Serveur 3 (1 cœur, 2 Go)

Résultats après amélioration

Performances améliorées : 3 serveurs traitent en parallèle, temps de réponse < 1 seconde
Haute disponibilité : si un serveur tombe en panne, les autres continuent de servir
Évolution horizontale : besoin de plus de performance ? Ajoutez simplement des serveurs

1.2 Analogie avec la vie quotidienne : le salon de thé

Imaginez que vous gérez un salon de thé à la mode :

1 caisse : les clients font la queue, les suivants s'impatientent, mauvaises avis
3 caisses : le personnel répartit les clients entre les caisses, efficacité multipliée par 3

L'équilibreur de charge est le « distributeur de caisses » :

Utilisateurs (clients) → Demandent un service
Équilibreur de charge (distributeur) → Répartit les requêtes vers différents serveurs
Serveurs (caisses) → Traitent les requêtes

传统架构单点

🖥️

Web Server

负载: 95% 🔥

→

负载均衡架构分布式

⚖️L4 Load Balancer

🖥️

📦四层负载均衡 (L4)

工作原理

基于传输层信息（IP地址+端口）进行流量分发。不关心应用层内容，只做"快递分拣"，因此性能极高。

典型产品

LVS (Linux Virtual Server)HAProxy (TCP模式)AWS NLBAzure Load Balancer

适用场景

需要极高吞吐量的场景
TCP/UDP流量分发
不需要内容识别的场景
微服务间通信

性能对比一览

类型

处理层

性能

灵活性

成本

硬件负载均衡

L4/L7

$$$$$

四层负载均衡

L4 (传输层)

七层负载均衡

L7 (应用层)

$$$

软件负载均衡

L4/L7

2. Qu'est-ce que l'équilibrage de charge ?

2.1 Équilibrage de charge couche 4 (L4) : ne regarde que le numéro de porte

Fonctionne au niveau transport (TCP/UDP), comme un livreur qui ne regarde que votre numéro de porte (adresse IP + numéro de port), sans se soucier de ce qui se passe chez vous.

Caractéristiques :

Vitesse extrême : ne fait qu'une simple redirection d'adresse, n'analyse pas le contenu des paquets
Cas d'utilisation : connexions à la base de données, cache Redis, serveurs de jeux à connexion longue
Produits représentatifs : LVS (Linux Virtual Server), AWS NLB, Azure Load Balancer

Principe de fonctionnement

Requête client → Équilibreur de charge L4 → Serveur backend
              ↓
         Ne regarde que IP + Port
              ↓
         Transfert rapide (sans dépaqueter le contenu)

2.2 Équilibrage de charge couche 7 (L7) : examine le contenu du colis

Fonctionne au niveau applicatif (HTTP/HTTPS), comme un livreur qui, au-delà du numéro de porte, ouvre le colis pour examiner son contenu et décider comment le livrer en conséquence.

Caractéristiques :

Routage intelligent : peut effectuer un routage fin basé sur le chemin URL, les en-têtes HTTP, les cookies, etc.
Fonctionnalités avancées : terminaison SSL, cache de contenu, compression, WAF de sécurité
Cas d'utilisation : applications Web, passerelles API, architectures microservices
Produits représentatifs : Nginx, HAProxy, AWS ALB, Envoy

Principe de fonctionnement

Requête client → Équilibreur de charge L7 → Analyse le contenu HTTP
              ↓
         Examine URL, Header, Cookie
              ↓
         Routage intelligent vers un serveur spécifique

2.3 Comparaison L4 vs L7

Dimension	Équilibrage L4	Équilibrage L7
Couche de travail	Transport (TCP/UDP)	Applicatif (HTTP/HTTPS)
Critère de décision	Adresse IP + numéro de port	URL, Header, Cookie, Body
Vitesse de traitement	Extrêmement rapide (mode noyau)	Assez rapide (analyse en espace utilisateur)
Richesse fonctionnelle	Transfert de base	Terminaison SSL, cache, compression, WAF
Scénario typique	Base de données, jeux, connexions longues	Applications Web, passerelles API, microservices
Produits représentatifs	LVS, AWS NLB	Nginx, HAProxy, AWS ALB

3. Problème central n°1 : comment éviter que les serveurs « en panne » continuent à recevoir des requêtes ?

3.1 Vérifications de santé : ne laissez pas un serveur « malade »拖垮 le système

Imaginez que l'une de vos caisses tombe en panne, mais que le distributeur ne le sait pas et continue d'envoyer des clients vers elle. La file d'attente s'allonge, les clients se plaignent.

Le contrôle de santé (Health Check) est la « sentinelle » qui empêche cette situation. Il effectue régulièrement un « bilan de santé » de chaque serveur, retire immédiatement ceux qui sont « malades » et les réintègre une fois « guéris ».

3.2 Contrôle de santé actif vs passif

Contrôle de santé actif (Active Health Check) : l'équilibreur de charge « frappe à la porte » pour demander au serveur « Es-tu toujours là ? »

Envoie régulièrement des requêtes de sondage (par ex. HTTP /health, TCP ping)
Un délai de réponse ou un code d'erreur indique que le serveur est défectueux
Avantage : résultat de détection fiable
Inconvénient : génère du trafic de sondage supplémentaire

Contrôle de santé passif (Passive Health Check) : l'équilibreur de charge « observe » les réponses du trafic réel

Statistiques sur le temps de réponse et le taux d'erreur des requêtes réelles
Des échecs consécutifs indiquent que le serveur est défectueux
Avantage : aucun trafic supplémentaire
Inconvénient : nécessite suffisamment de trafic pour porter un jugement

Tableau des seuils

Indicateur	Seuil de santé	Seuil de défectuosité	Description
Code d'état HTTP	200-399	400+ ou timeout	Les 4xx/5xx sont considérés comme des échecs
Connexion TCP	Établie avec succès	Délai de connexion	Vérifier si le port est accessible
Temps de réponse	< 500 ms	> 2000 ms	Le délai est généralement fixé entre 2 et 5 secondes
Échecs consécutifs	-	3	Éviter les faux positifs dus à un incident isolé
Intervalle de vérification	-	5 s	Trop fréquent augmente la charge

Piège courant : seuils trop « sensibles »

Une équipe avait fixé le seuil de temps de réponse du contrôle de santé à 100 ms, alors que le temps de réponse moyen de leur application oscillait entre 80 et 120 ms. Résultat : les serveurs étaient fréquemment marqués comme « défectueux », le trafic oscillait sans cesse entre serveurs sains et défectueux, et la disponibilité globale du système diminuait.

La bonne approche : le seuil doit être fixé à 2 à 3 fois le temps de réponse au 99e percentile, laissant une marge suffisante pour les variations normales.

4. Problème central n°2 : comment s'assurer que le « client habituel » trouve toujours le même « caissier » ?

4.1 Persistance de session : le « client habituel » trouve toujours le même « caissier »

Imaginez que vous êtes un habitué du salon de thé, toujours accueilli par le même employé qui connaît vos préférences (moitié de sucre, sans glace). Le service est rapide et attentionné. Mais si à chaque visite vous avez un nouvel employé, vous devez tout répéter, l'efficacité en prend un coup.

La persistance de session (Session Persistence/Sticky Session) résout précisément ce problème : s'assurer que les requêtes d'un même utilisateur sont toujours routées vers le même serveur backend.

应用场景：

👤

用户A

👥

用户B

👨‍💼

用户C

请求

↓

⚖️负载均衡器

🍪

Cookie 插入

通过HTTP Cookie保持会话

会话映射表

sess_abc123→Server 1

sess_def456→Server 2

sess_ghi789→Server 1

↓

🖥️

Server 1

10.0.1.10

✓

选中

🖥️

Server 2

10.0.1.11

✓

🖥️

Server 3

10.0.1.12

✗

↑

三种会话保持机制对比

🍪Cookie 插入

✓不受客户端IP变化影响

✓首次请求即可保持会话

✗客户端需支持Cookie

✗存在Cookie被禁用的风险

#️⃣IP Hash

✓无需客户端支持任何机制

✓无状态，LB重启不影响会话

✗客户端IP变化会丢失会话

✗难以做到真正的负载均衡

📝粘性会话

✓结合Cookie和IP两种方式优势

✓支持会话复制和故障转移

✗实现复杂，需要应用支持

✗会话复制带来性能开销

4.2 Comparaison de trois mécanismes de persistance de session

Mécanisme	Principe de mise en œuvre	Avantage	Inconvénient	Cas d'utilisation
Insertion de cookie	L'équilibreur de charge insère un cookie dans la réponse, les requêtes ultérieures portent ce cookie	Insensible aux changements d'IP, la persistance est établie dès la première requête	Le client doit supporter les cookies, qui peuvent être désactivés	Panier e-commerce, maintien de la connexion
Hachage IP	Calcul de hachage sur l'IP du client, mappage vers un serveur spécifique	Aucun support client requis, sans état	Un changement d'IP fait perdre la session, répartition difficilement uniforme	Environnements sans cookie, WebSocket
Table de sessions sticky	L'équilibreur de charge maintient une table de mappage session → serveur	Supporte la réplication de session et le basculement	Consomme la mémoire de l'équilibreur de charge, nécessite une synchronisation supplémentaire	Scénarios exigeant une haute disponibilité stricte

Recommandations d'utilisation

Insertion de cookie : recommandée en priorité, bonne compatibilité
Hachage IP : uniquement pour les scénarios spéciaux comme WebSocket
Table de sessions sticky : combinée aux cookies, offre une capacité de basculement

5. Problème central n°3 : comment réaliser un déploiement sans interruption ?

5.1 Déploiement bleu-vert : publication sans interruption par « basculement instantané »

Idée fondamentale : maintenir simultanément deux environnements de production identiques (environnement bleu et environnement vert), mais un seul est exposé au public.

🔵

蓝环境

v1.0.0

100% 流量

🟢

绿环境

v1.1.0

0% 流量

用户流量

👤

↓

⚖️

负载均衡器

当前指向: 🔵 蓝环境

↓

🔵蓝环境v1.0.0

🖥️B1●

🖥️B2●

🖥️B3●

🟢绿环境v1.1.0

🖥️G1●

🖥️G2●

🖥️G3●

蓝绿部署流程

绿环境部署

在绿环境部署新版本，进行冒烟测试

→

切换流量

将负载均衡器指向绿环境，流量瞬间切换

→

监控观察

观察绿环境运行状态，确认无异常

→

蓝环境升级

在蓝环境部署新版本，为下次切换做准备

蓝绿部署优缺点

✅优点

零停机时间：流量切换在毫秒级完成，用户无感知
快速回滚：发现问题可立即切回原环境，风险可控
完整的预发布测试：新环境可完整测试后再接管流量
数据一致性：无需处理新旧版本同时运行时的兼容问题

❌缺点

资源成本高：需要同时维护两套完整环境，服务器成本翻倍
数据库兼容性挑战：如果涉及数据库Schema变更，需要特别处理兼容性
预热问题：新环境启动后可能需要时间预热缓存、连接池等
不适合有状态服务：对于长连接、会话保持要求高的场景处理复杂

Flux de travail :

État initial : l'environnement bleu exécute v1.0 (production), l'environnement vert est en attente.
Déploiement de la nouvelle version : déployer v1.1 dans l'environnement vert, effectuer des tests de fumigation internes.
Basculement du trafic : pointer l'équilibreur de charge vers l'environnement vert, le trafic bascule instantanément vers v1.1.
Surveillance : observer l'état de l'environnement vert, confirmer l'absence d'anomalies.
Conservation de l'ancienne version : l'environnement bleu conserve v1.0 pendant un certain temps (par ex. 24 heures), comme assurance de rollback rapide.

Analyse des avantages et inconvénients

Avantages	Inconvénients
Temps d'indisponibilité nul, le basculement s'effectue en quelques millisecondes	Coût de ressources élevé, nécessite la maintenance simultanée de deux environnements
Rollback rapide, retour à l'environnement précédent dès qu'un problème est détecté	Les modifications de schéma de base de données nécessitent un traitement de compatibilité particulier
Le nouvel environnement peut être testé exhaustivement avant de prendre le trafic	Non applicable aux services avec état (comme les connexions longues WebSocket)

5.2 Publication canari : stratégie de déploiement progressif en « petites étapes rapides »

Le nom « publication canari » vient de la pratique historique des « canaris de mine » — les mineurs emmenaient un canari dans la mine ; si le canari montrait des signes anormaux, cela indiquait une fuite de gaz toxique et les mineurs évacuaient immédiatement. Dans la publication logicielle, la publication canari consiste à faire tester d'abord la nouvelle version par un petit nombre d'utilisateurs, puis à étendre progressivement la portée si aucun problème n'est détecté.

流量分配比例拖动滑块调整新旧版本流量占比

稳定版 v1.0.090%

金丝雀 v1.1.010%

实时流量模拟总请求: 0 | 稳定版: 0 | 金丝雀: 0

用户请求

→

负载均衡器

⚖️

Canary:10%

→

后端服务

稳定版 v1.0.0

📦S1

📦S2

📦S3

金丝雀 v1.1.0

🧪C1

🧪C2

金丝雀发布最佳实践

📊渐进式放量

1% → 5% → 10% → 25% → 50% → 100%
每个阶段观察至少15-30分钟
关键指标：错误率、延迟、吞吐量

🎯精准用户选择

内部员工/测试用户先行
按地域：选择特定区域用户
按用户属性：VIP用户或普通用户
按设备类型：iOS/Android/Web

🛡️自动回滚机制

错误率超过阈值自动回滚
P99延迟异常触发告警
关键业务指标下降自动回滚
一键回滚：30秒内恢复旧版本

📈监控与指标

基础设施：CPU、内存、磁盘、网络
应用指标：QPS、错误率、延迟分布
业务指标：转化率、订单量、收入
用户体验：页面加载时间、交互延迟

Idée fondamentale :

Trafic limité en premier : rediriger d'abord 1 % du trafic vers les serveurs de la nouvelle version.
Surveillance des indicateurs : suivre en continu le taux d'erreur, la latence et les indicateurs clés de l'activité.
Augmentation progressive : si tout est normal, augmenter progressivement la proportion à 5 %, 10 %, 25 %, 50 %, 100 %.
Rollback rapide : dès qu'une anomalie est détectée, basculer immédiatement tout le trafic vers l'ancienne version.

Avantages de la publication canari

Avantage	Description
Risque maîtrisé	Même si la nouvelle version a un bug critique, seuls quelques utilisateurs sont affectés
Validation réelle	Testée dans le véritable environnement de production, plus fiable que l'environnement de test
Itération rapide	L'équipe peut publier de nouvelles fonctionnalités plus fréquemment et en toute confiance
Économie de ressources	Pas besoin de préparer deux environnements complets comme pour le déploiement bleu-vert

6. Problème central n°4 : comment permettre au système de « respirer » tout seul ?

6.1 Mise à l'échelle automatique : le système s'adapte comme un restaurant qui « ajuste son personnel »

Imaginez que vous gérez un restaurant :

Heure de pointe du déjeuner : 10 serveurs sont nécessaires, mais à 15 h en période creuse, 2 suffisent
Si vous gardez 10 serveurs en permanence : les coûts salariaux explosent
Si vous n'en gardez que 2 : aux heures de pointe, les clients s'impatientent et partent

La mise à l'échelle automatique (Auto Scaling) permet au système de s'adapter comme un restaurant — ajouter automatiquement des serveurs quand la charge est élevée, en retirer quand elle est basse.

扩容指标：

实时监控实时

💻CPU使用率

45%

扩容阈值: 70%缩容阈值: 30%

🧠内存使用率

60%

扩容阈值: 75%缩容阈值: 40%

⚡QPS

650req/s

扩容阈值: 1000/s目标: 800/s

🖥️运行实例

3个实例

最小: 2最大: 10

扩缩容历史最近 5 次操作

📈

扩容: 2 → 3 实例

CPU使用率超过70%