Existuje tucet řešení pro provádění vyhledávací služby v prostředí Mesos.
Můžeme je rozdělit do 3 skupin podle toho, jak klient služby nachází:
- Na základě proxy
- Když mezi klienty a službou sedí proxy, např. HAProxy (je na něm založen marathon-lb), fabio, traefik, nixy), který se stará o vyrovnávání zátěže vašich služeb na základě HTTP cesty, hlavičky, domény atd. Toto řešení se snadno vyvíjí a dává možnost vyladit loadbalancing na základě požadavku. Na druhou stranu přidáme další hop a jako proxy máme situaci MitM.
- DNSlike (požádejte speciální dobře známý koncový bod o umístění služby)
- Softwarově definovaná síť – můžeme použít IP na kontejner s SDN, takže každý kontejner je vystaven s jedinečnou IP a prezentuje své služby pomocí výchozích portů 80 pro HTTP, 443 pro HTTPS a tak dále. Toto je nejpokročilejší a relativně nová technika, i když k nalezení IP služby používá obyčejný starý DNS. Může být těžší zavést než proxy, ale bude fungovat s jakýmkoli typem provozu.
- Záznam služby – kde je každý kontejner registrován v globálním DNS a klient získá jeho IP a PORT pomocí DNS SRV dotazů. Consul Mesos DNS poskytuje tento typ serveru DNS. Také některé další protokoly jsou založeny na této myšlence (podívejte se na Bonjure). Snaží se získat to nejlepší z SDN i proxy. Je relativně snadné jej nastavit a není protokolární.
- Jiné
- Cokoli, co se nehodí do jiných typů, např. vlastní vyvinuté řešení, etcd nebo Eureka. Mohlo by to být velmi těsné s infrastrukturou a aplikací poskytující určité optimalizace. Za zmínku stojí, že existují pokusy o použití vyhledávací služby založené na DHT – Meta Service Discovery
Více podrobností o nástrojích, které lze použít k vytvoření Discovery Service, naleznete zde
Služby zjišťování můžeme rozdělit podle způsobu, jakým jsou naplněny položkami služeb:
- Sdružování
- Mesos/Marathon je pravidelně dotazován na stav. Takto funguje Mesos DNS. Toto je nejjednodušší metoda, ale způsobí velké zpoždění mezi spuštěním/zastavením služby a změnami, které se dostanou do zjišťování služby. To by se dalo minimalizovat pomocí Healthchecking.
- Na základě události
- Marathon má schopnost posílat události informacemi o změnách stavu (Iniciativa je zahrnuta i do sběrnice událostí int Mesos — design doc. Tímto způsobem funguje marathon-lb. Podobnou práci provádí marathon-konzul, ale data jsou předávána konzul.
- V aplikaci/kontejneru
- Výše uvedená řešení jsou asynchronní, takže může nastat časový úsek, kdy je stav zjišťování služby zastaralý, např. služba byla spuštěna, ale není připravena obsluhovat požadavky, nebo služba právě zemřela. Ani s healtcheck jsme nemohli předpokládat, že všechny věci se stanou s nulovým prostojem. Řešením, jak minimalizovat prostoje, je nechat aplikaci, aby se sama zaregistrovala, když je připravena obsluhovat požadavky, a odregistrovat se, než se zastaví (také znám jako elegantní vypnutí).