Service Mesh et microservices Kotlin : du chaos à l'ordre

Vos microservices Kotlin ont-ils cessé d'être de simples microservices ?

Si vous avez déjà déployé en production un système composé d'une dizaine de services Kotlin, vous connaissez ce moment. Au début, tout est parfait : ktor fonctionne, spring-webflux vole, la base de données répond instantanément. Mais un mois passe, et le monde familier s'effondre. Le trafic commence à boucler, les tentatives se multiplient, les timeouts surgissent là où ils ne devraient pas être, et les logs se transforment en un fouillis d'un million de lignes.

C'est à ce moment que vous commencez à chercher un service mesh. Et c'est la bonne voie. Comprenons comment cette technologie transforme le chaos en ordre, et comment l'intégrer correctement dans l'univers Kotlin.

Qu'est-ce qu'un service mesh et pourquoi en a-t-on besoin en tant que développeur Kotlin ?

Service mesh (maillage de services) est une couche d'infrastructure dédiée à la gestion des interactions entre services. Il prend en charge tout le « sale boulot » : routage, équilibrage, chiffrement, observabilité et circuit breaking. Et tout cela sans modifier le code de vos applications Kotlin.

Pourquoi est-ce crucial pour Kotlin ? Les microservices Kotlin sont souvent écrits avec des frameworks comme Ktor ou Spring Boot. Les deux gèrent très bien la logique métier, mais lorsqu'ils deviennent 20 ou plus, chaque service commence à traîner une tonne de code répétitif : métriques, tracing, mTLS, mécanismes de retry. Le service mesh externalise tout cela au niveau de l'infrastructure.

Imaginez : vous écrivez un simple endpoint REST sur Ktor, et le service mesh ajoute automatiquement le chiffrement, le tracing et l'équilibrage de charge. Magnifique, n'est-ce pas ?

Composants principaux du service mesh

Tout maillage de services repose sur deux composants clés :

\n
• Control plane (plan de contrôle) — le « cerveau » du système. Il collecte la configuration, gère les règles de routage, les politiques de sécurité. Dans Istio, c'est istiod, dans Linkerd, c'est linkerd-controller.
\n
• Data plane (plan de données) — les « muscles ». Un ensemble de proxys sidecar (généralement Envoy) qui se placent à côté de chacun de vos services Kotlin et interceptent tout le trafic entrant/sortant.
\n

Lorsque le service Kotlin A veut appeler le service B, sa requête passe d'abord par le proxy sidecar. Le proxy vérifie les règles, applique le mTLS, équilibre la charge, ajoute des en-têtes pour le tracing — et ensuite seulement envoie la requête plus loin. Votre code n'en a même pas conscience.

Pratique : configurer un service mesh pour un microservice Kotlin

Écrivons un service Kotlin simple avec Ktor et voyons comment le service mesh modifie son comportement.

Étape 1. Écrire l'application en Kotlin

// build.gradle.kts\ndependencies {\n    implementation("io.ktor:ktor-server-netty:2.3.7")\n    implementation("io.ktor:ktor-server-content-negotiation:2.3.7")\n    implementation("io.ktor:ktor-serialization-kotlinx-json:2.3.7")\n    implementation("ch.qos.logback:logback-classic:1.4.14")\n}\n\n// Application.kt\npackage com.example\n\nimport io.ktor.server.engine.*\nimport io.ktor.server.netty.*\nimport io.ktor.server.routing.*\nimport io.ktor.server.response.*\nimport io.ktor.serialization.kotlinx.json.*\nimport io.ktor.server.plugins.contentnegotiation.*\n\nfun main() {\n    embeddedServer(Netty, port = 8080) {\n        install(ContentNegotiation) {\n            json()\n        }\n        routing {\n            get("/health") {\n                call.respond(mapOf("status" to "UP", "service" to "payment"))\n            }\n            get("/api/payments/{id}") {\n                val id = call.parameters["id"] ?: "unknown"\n                call.respond(mapOf("paymentId" to id, "amount" to 150.00))\n            }\n        }\n    }.start(wait = true)\n}\n

Ce service ne sait rien du service mesh. Il se contente de répondre aux requêtes. Mais dès que nous le déploierons dans un cluster Kubernetes avec Istio, tout changera.

Étape 2. Déploiement avec