Service discovery (découverte de services)

Le service discovery est le mécanisme par lequel un service trouve, à l’exécution, les adresses des instances d’un autre service. Il remplace les adresses codées en dur ou les fichiers de configuration statiques dès que les instances vont et viennent — montée en charge, remplacement de machines, déploiements — c’est-à-dire dans toute infrastructure un peu vivante.

Les trois approches

Le DNS est la forme la plus ancienne et la plus universelle : un nom stable (db.interne.example) résolu vers une ou plusieurs adresses. Sa limite est structurelle : le DNS ne sait pas dire si l’instance derrière l’adresse est saine, et les clients mettent les réponses en cache — parfois bien au-delà du TTL, selon la bibliothèque ou le runtime — ce qui retarde la prise en compte d’un changement.

Le registre dédié (Consul, etcd, ZooKeeper) inverse la logique : les instances s’enregistrent elles-mêmes et le registre exécute des health checks, ne renvoyant que les instances saines. Consul expose ce catalogue à la fois par API et par une interface DNS, ce qui permet aux applications non modifiées d’en profiter. Le prix : un composant de plus à opérer, avec ses exigences propres de quorum et de haute disponibilité — un registre en panne peut rendre tous les services introuvables.

La plateforme peut enfin porter la discovery elle-même. Sur Kubernetes, un objet Service fournit un nom DNS stable (via CoreDNS) et une adresse virtuelle qui répartit le trafic vers les pods sains, l’état de santé étant alimenté par les readiness probes. Pour les applications qui vivent dans le cluster, le problème est résolu par construction ; il resurgit dès qu’il faut joindre des services hors du cluster, ou l’inverse.

Ce qui compte en production

Le choix se joue moins sur l’outil que sur deux questions : qui décide qu’une instance est saine (un health check déclaratif, une probe, personne ?), et combien de temps une information périmée peut circuler (TTL, caches clients, délais de propagation). Une migration vers Kubernetes déplace la réponse — la discovery interne devient native, mais la frontière entre le cluster et le legacy reste à outiller, et c’est là que se concentrent les incidents.