Има дузина решения за извършване на услуга за откриване в средата на Mesos.
Можем да ги разделим на 3 групи според начина, по който клиентите намират услуги:
- Въз основа на прокси
- Когато между клиенти и услуга се намира прокси, например HAProxy (marathon-lb се базира на него), fabio, traefik, nixy), който се грижи за балансирането на натоварването на услугите ви въз основа на HTTP път, заглавка, домейн и т.н. Това решение е лесно за разработване и дава възможност за настройка на балансирането на натоварването според заявка. От друга страна добавяме допълнителен хоп и като прокси имаме MitM ситуация.
- DNSlike (попитайте специална добре позната крайна точка за местоположението на услугата)
- Софтуерно дефинирана мрежа – можем да използваме IP за контейнер със SDN, така че всеки контейнер да бъде изложен с уникален IP и да представя услугите си, използвайки портове по подразбиране 80 за HTTP, 443 за HTTPS и т.н. Това е най-напредналата и сравнително нова техника, въпреки че използва обикновен стар DNS за намиране на IP адрес на услугата. Може да е по-трудно да се въведе от прокси, но ще работи с всякакъв тип трафик.
- Сервизен запис – където всеки контейнер е регистриран в глобалния DNS и клиентът получава своя IP и PORT чрез DNS SRV заявки. Consul Mesos DNS предоставя този тип DNS сървър. Също така някои други протоколи се основават на тази идея (вижте Bonjure). Опитва се да получи най-доброто от SDN и прокси. Сравнително лесно се настройва и не зависи от протоколите.
- Други
- Всичко, което не се вписва в други типове, напр. вътрешно разработено решение, etcd или Eureka. Може да е много трудно с инфраструктура и приложение, осигуряващи някои оптимизации. Струва си да се спомене, че има някои опити да се използва услуга за откриване, базирана на DHT - Meta Service Discovery
Можете да намерите повече подробности за инструментите, които биха могли да се използват за създаване на Discovery Service тук
Можем да разделим Discovery Services по начина, по който са попълнени със записи за услуги:
- Обединяване
- Mesos/Marathon периодично се пита за състояние. Ето как работи Mesos DNS. Това е най-лесният метод, но ще причини огромно забавяне между стартиране/спиране на услугата и промените влизат в откриването на услугата. Това може да бъде сведено до минимум чрез проверка на здравето.
- Въз основа на събития
- Marathon има възможност да изпраща събития с информация за промени в състоянието (Има инициатива да се включи и шината на събития в Mesos — документ за проектиране. По този начин работи marathon-lb. Подобна работа се извършва от marathon-consul, но данните се предават на консул.
- В приложение/контейнер
- Решенията по-горе са асинхронни, така че може да има период от време, когато състоянието на откриване на услугата ви е остаряло, напр. услугата стартира, но не е готова да обслужва заявки или услугата току-що умря. Дори с healtcheck не можехме да приемем, че всички неща се случват с 0 престой. Решението за минимизиране на престоя е да оставите приложението да се регистрира, когато е готово да обслужва заявки, и да дерегистрира, преди да спре (известно още като грациозно изключване).
