Service Mesh et microservices TypeScript : guide complet 2024

Quand il y a trop de microservices

Vous avez écrit votre premier microservice en TypeScript. Il fonctionne. Puis un deuxième, un troisième, un dixième. Et soudain, vous remarquez que vous passez plus de temps non pas à écrire la logique métier, mais à faire en sorte que les microservices puissent simplement communiquer entre eux. Timeouts, retries, équilibrage de charge, chiffrement du trafic, métriques — tout cela doit être implémenté dans chaque service séparément.

C'est là qu'intervient le Service Mesh — une technologie qui déplace toute l'infrastructure de communication du code vers une couche distincte. Et oui, elle fonctionne parfaitement avec les microservices TypeScript. Dans cet article, nous allons voir comment cela fonctionne en pratique, avec des exemples de code réels.

Qu'est-ce que Service Mesh en termes simples

Imaginez que chacun de vos microservices TypeScript est un employé dans un grand bureau. Sans Service Mesh, chaque employé doit lui-même tirer ses câbles, configurer son téléphone et s'assurer de ne pas être écouté. Avec Service Mesh, un service informatique spécialisé s'en occupe, en connectant un « assistant personnel » (sidecar proxy) à chaque employé.

Dans le monde de la technologie, cet assistant s'appelle Envoy Proxy, et toute cette infrastructure est gérée par un orchestrateur comme Istio ou Linkerd. Le plus agréable, c'est que votre code TypeScript reste pratiquement inchangé.

Fonctionnalités clés de Service Mesh

\n
• Traffic Management — routage intelligent, tests A/B, déploiements canary
\n
• Security — chiffrement automatique mTLS entre les services
\n
• Observability — métriques, logs, tracing « prêts à l'emploi »
\n
• Resilience — retries, circuit breaker, timeouts au niveau de l'infrastructure
\n

Pourquoi les microservices TypeScript bénéficient particulièrement de Service Mesh

TypeScript est un langage avec un système de types puissant, mais son environnement d'exécution principal (Node.js) n'est pas toujours réputé pour ses performances d'entrée-sortie. Lorsque vous écrivez un microservice en TypeScript, chaque requête HTTP supplémentaire, chaque implémentation manuelle de retries ou de poignée de main TLS est une charge supplémentaire pour l'Event Loop.

Service Mesh prend cette charge sur lui. Votre code TypeScript reste propre : il se contente de recevoir des requêtes et d'y répondre, tandis qu'Envoy s'occupe de toute la « plomberie ». C'est particulièrement important lorsque vous avez des dizaines de microservices — chacun avec sa propre logique de tentatives et de timeouts.

Exemple pratique : microservice TypeScript sous Service Mesh

Imaginons que nous ayons deux microservices en TypeScript : user-service et order-service. Order-service doit obtenir les données d'un utilisateur. Sans Service Mesh, nous écririons quelque chose comme :

// Sans Service Mesh — gestion manuelle HTTP\nimport axios from 'axios';\n\nclass UserClient {\n    private baseUrl = 'http://user-service:3000';\n    private retries = 3;\n\n    async getUser(id: string): Promise<User> {\n        for (let i = 0; i < this.retries; i++) {\n            try {\n                const response = await axios.get(`${this.baseUrl}/users/${id}`, {\n                    timeout: 5000,\n                    httpsAgent: new https.Agent({ rejectUnauthorized: true })\n                });\n                return response.data;\n            } catch (error) {\n                if (i === this.retries - 1) throw error;\n                await delay(1000 * Math.pow(2, i));\n            }\n        }\n    }\n}

Avec Service Mesh, cela devient :

// Avec Service Mesh — simple requête HTTP\nimport axios from 'axios';\n\nclass UserClient {\n    async getUser(id: string): Promise<User> {\n        const response = await axios.get(`http://user-service/users/${id}`);\n        return response.data;\n    }\n}

Vous avez remarqué la différence ? Toute la complexité — retries, timeouts, chiffrement — est