Istnieje kilkanaście rozwiązań do wykonywania usługi wykrywania w środowisku Mesos.
Możemy podzielić je na 3 grupy według sposobu wyszukiwania usług przez klienta:
- Na podstawie proxy
- Gdy pomiędzy klientami a usługą znajduje się proxy np. HAProxy (na nim bazuje marathon-lb), fabio, traefik, nixy), które dba o równoważenie obciążenia Twoich usług w oparciu o ścieżkę HTTP, nagłówek, domenę itp. To rozwiązanie jest łatwe do opracowania i daje możliwość dostosowania równoważenia obciążenia na żądanie. Z drugiej strony dodajemy dodatkowy przeskok i jako proxy mamy sytuację MitM.
- DNSlike (poproś specjalny dobrze znany punkt końcowy o lokalizację usługi)
- Sieć definiowana programowo - możemy użyć adresu IP na kontener z SDN, więc każdy kontener ma unikalny adres IP i prezentuje swoje usługi przy użyciu domyślnych portów 80 dla HTTP, 443 dla HTTPS i tak dalej. Jest to najbardziej zaawansowana i stosunkowo nowa technika, chociaż używa zwykłego starego DNS do wyszukiwania IP usługi. Wprowadzenie proxy może być trudniejsze, ale będzie działać z każdym rodzajem ruchu.
- Rekord usługi - gdzie każdy kontener jest zarejestrowany w globalnym DNS, a klient uzyskuje swój adres IP i PORT za pomocą zapytań DNS SRV. Consul Mesos DNS zapewnia ten typ serwera DNS. Również niektóre inne protokoły są oparte na tym pomyśle (spójrz na Bonjure). Stara się jak najlepiej wykorzystać zarówno SDN, jak i proxy. Jest stosunkowo łatwy w konfiguracji i niezależny od protokołu.
- Inne
- Wszystko, co nie pasuje do innych typów, np. własne rozwiązanie, etcd lub Eureka. Może to być bardzo ciasne z infrastrukturą i aplikacją zapewniającą pewne optymalizacje. Warto wspomnieć, że istnieją próby wykorzystania usługi wykrywania opartej na DHT - Meta Service Discovery
Więcej informacji na temat narzędzi, które można wykorzystać do tworzenia usługi wyszukiwania, znajdziesz tutaj
Usługi wykrywania możemy podzielić według sposobu ich wypełnienia wpisami usług:
- Łączenie
- Mesos/Marathon jest okresowo pytany o stan. Tak działa Mesos DNS. Jest to najłatwiejsza metoda, ale spowoduje duże opóźnienie między uruchomieniem/zatrzymaniem usługi, a zmianami w wykrywaniu usług. Można to zminimalizować, stosując kontrolę stanu.
- Na podstawie wydarzeń
- Marathon ma możliwość wypychania zdarzeń z informacjami o zmianach stanu (należy również uwzględnić szynę zdarzeń int Mesos — dokument projektowy. W ten sposób działa marathon-lb. Podobną pracę wykonuje marathon-consul, ale dane są przekazywane do konsul.
- W aplikacji/kontenerze
- Powyższe rozwiązania są asynchroniczne, więc może wystąpić okres, w którym stan wykrywania usług jest przestarzały, np. usługa została uruchomiona, ale nie jest gotowa do obsługi żądań lub usługa właśnie umarła. Nawet z kontrolą stanu nie mogliśmy założyć, że wszystko dzieje się przy 0 przestoju. Rozwiązaniem minimalizującym przestoje jest umożliwienie aplikacji zarejestrowania się, gdy jest gotowa do obsługi żądań, i wyrejestrowanie się przed jej zatrzymaniem (tzw. łagodne zamknięcie).
