Er zijn tientallen oplossingen voor het uitvoeren van detectieservices in de Mesos-omgeving.
We kunnen ze onderverdelen in 3 groepen door de manier waarop de klant diensten vindt:
- Op proxy gebaseerd
- Als tussen clients en service een proxy zit, bijv. HAProxy (marathon-lb is daarop gebaseerd), fabio, traefik, nixy) die zorgt voor de taakverdeling van uw services op basis van HTTP-pad, header, domein enz. Deze oplossing is eenvoudig te ontwikkelen en geeft de mogelijkheid om de loadbalancing op verzoek af te stemmen. Aan de andere kant voegen we extra hop toe en als proxy hebben we een MitM-situatie.
- DNS-achtig (vraag een speciaal bekend eindpunt naar de locatie van de service)
- Software Defined Network - we kunnen IP per container gebruiken met SDN, zodat elke container een uniek IP-adres heeft en zijn services presenteert met standaardpoorten 80 voor HTTP, 443 voor HTTPS enzovoort. Dit is de meest geavanceerde en relatief nieuwe techniek, hoewel het gewone oude DNS gebruikt om het service-IP te vinden. Het kan moeilijker zijn om te introduceren dan proxy, maar het werkt met elk type verkeer.
- Servicerecord - waar elke container is geregistreerd in globale DNS en de client zijn IP en PORT verkrijgt met behulp van DNS SRV-query's. Consul Mesos DNS biedt dit type DNS-server. Ook enkele andere protocollen zijn op dit idee gebaseerd (zie Bonjure). Het probeert het beste van zowel SDN als proxy te krijgen. Het is relatief eenvoudig in te stellen en het is protocol-onafhankelijk.
- Overig
- Alles wat niet in andere typen past, b.v. inhouse ontwikkelde oplossing, etcd of Eureka. Het kan erg krap zijn met infrastructuur en applicatie die enkele optimalisaties bieden. Het is vermeldenswaard dat er enkele pogingen zijn om op DHT gebaseerde ontdekkingsservice te gebruiken - Meta Service Discovery
Meer details over tools die kunnen worden gebruikt voor het maken van Discovery Service vind je hier
We kunnen Discovery Services onderverdelen door de manier waarop ze zijn gevuld met service-items:
- Poolen
- Mesos/Marathon wordt periodiek ondervraagd over de staat. Dit is hoe Mesos DNS werkt. Dit is de gemakkelijkste methode, maar veroorzaakt een enorme vertraging tussen het starten/stoppen van de service en de wijzigingen in de servicedetectie. Dit kan worden geminimaliseerd door gebruik te maken van healthchecking.
- Gebeurtenisgebaseerd
- Marathon heeft de mogelijkheid om evenementen te pushen met informatie over staatsveranderingen (Er is een initiatief om ook de evenementenbus in Mesos op te nemen - ontwerpdocument. Op deze manier werkt marathon-lb. Vergelijkbare taak wordt gedaan door marathon-consul, maar gegevens worden doorgegeven aan consul.
- In app/container
- Bovenstaande oplossingen zijn asynchroon, dus er kan een tijdspanne zijn waarin uw servicedetectiestatus oud is, b.v. service is gestart maar is niet klaar om verzoeken te verwerken, of service is net overleden. Zelfs met healthcheck konden we niet aannemen dat alle dingen gebeuren met 0 downtime. De oplossing om downtime te minimaliseren, is door de applicatie zichzelf te laten registreren wanneer deze klaar is om verzoeken te verwerken, en zich uit te schrijven voordat deze stopt (ook bekend als gracieus afsluiten).