Il existe une douzaine de solutions pour effectuer un service de découverte dans l'environnement Mesos.
Nous pouvons les diviser en 3 groupes selon la manière dont les clients trouvent les services :
- Basé sur un proxy
- Lorsqu'entre les clients et le service se trouve un proxy, par exemple, HAProxy (marathon-lb est basé dessus), fabio, traefik, nixy) qui s'occupe d'équilibrer la charge de vos services en fonction du chemin HTTP, de l'en-tête, du domaine, etc. Cette solution est facile à développer et offre la possibilité d'ajuster l'équilibrage de charge en fonction de la demande. D'autre part, nous ajoutons un saut supplémentaire et, en tant que proxy, nous avons la situation MitM.
- Semblable à DNS (demander à un point de terminaison spécial bien connu l'emplacement du service)
- Réseau défini par logiciel :nous pouvons utiliser une adresse IP par conteneur avec SDN afin que chaque conteneur soit exposé avec une adresse IP unique et présente ses services en utilisant les ports par défaut 80 pour HTTP, 443 pour HTTPS, etc. Il s'agit de la technique la plus avancée et la plus récente, bien qu'elle utilise l'ancien DNS pour trouver l'adresse IP du service. Il pourrait être plus difficile à initier qu'au proxy, mais il fonctionnera avec n'importe quel type de trafic.
- Enregistrement de service - où chaque conteneur est enregistré dans le DNS mondial et le client obtient son IP et son PORT à l'aide de requêtes DNS SRV. Consul Mesos DNS fournit ce type de serveur DNS. D'autres protocoles sont également basés sur cette idée (regardez Bonjure). Il essaie de tirer le meilleur parti du SDN et du proxy. Il est relativement facile à configurer et indépendant du protocole.
- Autre
- Tout ce qui ne rentre pas dans les autres types, par ex. solution développée en interne, etcd ou Eureka. Cela pourrait être profondément serré avec une infrastructure et une application fournissant certaines optimisations. Il convient de mentionner qu'il existe quelques tentatives d'utilisation du service de découverte basé sur DHT - Meta Service Discovery
Vous pouvez trouver plus de détails sur les outils qui pourraient être utilisés pour créer le service de découverte ici
Nous pouvons diviser les services de découverte en fonction de la manière dont ils sont remplis avec des entrées de service :
- Mise en commun
- Mesos/Marathon est périodiquement interrogé sur son état. C'est ainsi que fonctionne Mesos DNS. Il s'agit de la méthode la plus simple, mais cela entraînera un retard considérable entre le démarrage/l'arrêt du service et l'entrée des modifications dans la découverte du service. Cela pourrait être minimisé en utilisant la vérification de l'état.
- Basé sur les événements
- Marathon a la capacité de pousser les événements avec des informations sur les changements d'état (il y a une initiative pour inclure le bus d'événements dans Mesos également - doc de conception. De cette façon, marathon-lb fonctionne. Un travail similaire est effectué par marathon-consul mais les données sont transmises à consul.
- Dans l'application/le conteneur
- Les solutions ci-dessus sont asynchrones, il peut donc y avoir une période pendant laquelle l'état de découverte de votre service est obsolète, par exemple. le service a démarré mais n'est pas prêt à répondre aux demandes, ou le service vient de mourir. Même avec le bilan de santé, nous ne pouvions pas supposer que tout se passe avec 0 temps d'arrêt. La solution pour minimiser les temps d'arrêt consiste à laisser l'application s'enregistrer lorsqu'elle est prête à répondre aux requêtes et à se désenregistrer avant qu'elle ne s'arrête (c'est-à-dire un arrêt progressif).
