Технические заметки одного Евтуховича

Рассказ о серых трудовых буднях инженера программных систем

Service Discovery

| Комментарии

Продолжая разговор о микросервисной архитектуре, нельзя не упомянуть о Service Discovery. К сожалению, в русском языке до сих пор так и не появилось адекватного перевода этого термина. Дословное «обнаружение сервисов» звучит слишком топорно и неизящно, а «каталог сервисов» хоть и неплох, но имеет много других значений.

Русская википедия про Service Discovery (далее — sd) не знает ничего и дает вместо этого список протоколов для sd, английская, впрочем, тоже.

Что же, я попробую рассказать об этом простыми словами.

Во-первых, зачем нужен sd? Допустим, в вашем окружении (ландшафте) есть какое-то количество сервисов, которые должны знать друг о друге — адреса, порты и какую-то дополнительную информацию. Если таких сервисов немного, то несложно прописать эту информацию в конфигурации конкретных сервисов. Когда сервисов становится больше, они начинают чаще появляться, исчезать, переезжать, то поддерживать актуальной конфигурацию для разных окружений становится все сложнее. В какой-то момент вы понимаете, что вам необходимо динамически масштабировать количество экземпляров конкретных сервисов, и тут уже ручная работа становится просто невозможной — необходимо использовать sd. Я в очередной раз акцентирую внимание, что как только вы затаскиваете новую сущность в ваш проект, он становится от этого только сложнее, и sd в этом смысле не исключение. Как только вы понимаете, что не сможете жить без sd, вам необходимо мало того, что поддерживать сам сервис sd, но также надо допилить все ваши сервисы, чтобы они умели с этим sd взаимодействовать, желательно динамически и без перезапуска сервиса. С другой стороны, из всех конфигурации конкретного окружения вам теперь надо знать только адрес sd-сервиса.

Допустим у нас есть два сервиса — А и Б, и сервиса Б использует сервис А. Конкретный экземпляр сервиса А стартует, стучится к sd и говорит: «Я сервис А, нахожусь по такому-то адресу». После этого стартует экземпляр сервиса Б и говорит: «А где у нас запущен сервис А?». В ответ он получает список всех адресов экземпляров сервиса А. Соответственно, сервис Б подписывается на обновления от sd, и если сервис А меняет свое расположение, сервис Б практически мгновенно узнает об этом от sd.

Фактически, sd является непротиворечивым хранилищем информации об связях всех сервисов между собою. Именно поэтому, наверное, все системы sd являются распределенными, чтобы отказ оборудования не приводил к полной остановке всех сервисов (почитайте про CAP-теорему на досуге). Также это позволяет с помощью sd организовать HA и failover (переключение на резерв в случае отказа), но это тема для отдельного разговора.

Сейчас существует много реализаций sd, но я бы рекомендовал начать знакомство с Consul. Я могу заблуждаться (и очень глубоко), но, по моему скромного мнению, он является стандартом де-факто для Service Discovery.

И как всегда, даже здесь нас ожидает инженерный компромис — чтобы сделать систему проще в одном месте, нам надо сделать ее сложнее в другом.

И, конечно, микросервисная архитектура, где количество различных сервисов, а также динамика их изменения, просто огромны, немыслима без Service Discovery.

Комментарии