Что такое обнаружение сервисов и зачем оно вам нужно?

Насколько я могу судить, "обнаружение сервисов" означает способ для клиента узнать о сервере (или кластере серверов), к которому он хочет подключиться.

Я создал веб-приложения, которые взаимодействуют с другими внутренними процессами, используя протоколы, такие как HTTP и AMQP. В них каждый клиент имеет конфигурационный файл, содержащий имя хоста или любую другую информацию, необходимую для подключения к серверу, который устанавливается во время развертывания с помощью инструмента конфигурации, такого как Ansible. Это просто и, кажется, работает очень хорошо.

Является ли обнаружение службы альтернативой просто помещению информации о сервере в файл конфигурации клиента? Если да, то почему это лучше? Если нет, то какую проблему он решает?

Ответ 1

Давайте начнем с рассмотрения того, что такое сервис-открытие - вот хорошее объяснение: https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/ (эта ссылка должна прояснить возникшую проблему)

А вот пример того, как это используется на практике: Предположим, у вас есть служба B, которая используется службой A. Служба B (как и большинство служб в SOA) на самом деле является кластером приложений типа B. Служба A требует использования одного из узлов кластера B, все же кластер узлов B является динамическим. то есть узлы B создаются и завершаются в зависимости от нагрузки на общую услугу B. Теперь мы хотели бы, чтобы служба A взаимодействовала с действующим узлом B каждый раз, когда ему необходимо использовать службу B. Для этого мы будем использовать инструмент обнаружения службы, чтобы предоставить нам, в любой момент времени, адрес одного из живых B-узлов.

Таким образом, попытка ответить на поставленные выше вопросы и поместить информацию о сервере конечной точки (в частности, адрес конечной точки) в качестве статической конфигурации в файл конфигурации, который читается при запуске службы A, не даст вам динамики Вы хотели бы, чтобы конечные точки службы B могли постоянно меняться.

Ответ 2

Архитектура облачного сервера меняет способ создания веб-приложений, которые мы перемещаем от единичных больших монолитов к разделению их на более мелкие и более мелкие индивидуально развертываемые службы, называемые микросервисами, вместе образующие большое приложение.

Давайте рассмотрим сценарий, когда служба хочет установить связь с другой службой, скажем, службе-A необходимо установить связь со службой-B. Сервис-A должен знать IP-адрес и номер порта Сервис-B. Самым простым решением проблемы является поддержание файла конфигурации, который содержит IP-адрес и порт для Service-B в Service-A. У этого подхода есть несколько минусов

Рассмотрим следующую ситуацию: -

  • Когда количество микро-сервисов в приложении увеличивается
    • Сложно управлять в файле конфигурации
    • Это может привести к ошибкам, когда происходит некое неправильное управление
    • Не хватает гибкости для изменения IP-адреса или порта в более поздний момент времени
    • Он не может использовать способность облака динамически масштабироваться или уменьшаться в зависимости от требований.

Этот простой подход слишком статичен и замораживает облако. Таким образом, приходит новое решение

Альтернативное решение: обнаружение сервисов

Обнаружение службы помогает решить вышеуказанную проблему, предоставляя способ

  • Для регистрации службы, т.е. когда новая служба подключается к сети, она регистрируется в службе обнаружения службы с использованием своего IP-адреса и порта
  • .Помогает сервису найти другие сервисы, т.е. помогает Сервису-A найти Сервис-B
  • Проверка работоспособности для проверки работоспособности экземпляра и удаления его, когда он не в порядке.
  • Отменить регистрацию, когда служба переходит в автономный режим.

Таким образом, это помогает использовать все возможности облака для динамического масштабирования и сжатия в зависимости от требований, а также делает архитектуру слабо связанной друг с другом

Ответ 3

Если у вас есть 2 микросервиса, скажем, A и B, и вы хотите, чтобы A связывался с B, A будет использовать метод (инструмент) обнаружения служб, чтобы найти B в архитектуре микросервисов.

Не только клиент-серверная связь, но и 2 микросервиса, которые могут работать на одном сервере.

Решаемая проблема состоит в том, что 2 микросервиса, работающие на 2 разных узлах кластера, могут обнаруживать друг друга, без обнаружения службы это было бы невозможно.

Вы можете посмотреть, как kurbernetes поддерживает обнаружение служб, скажем, через DNS, используя coreDNS.https://kubernetes.io/docs/concepts/services-networking/service/

Ответ 4

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

Обнаружение сервисов - это не простой способ поместить список сервисов, которые должны быть вызваны в конфигурацию клиента, но сохранить список экземпляров всех сервисов.

Вы можете просто понять, что у нас есть служба регистрации, которая может автоматически управлять списком экземпляров служб, к которым осуществляется доступ. Когда вы добавляете сервис или закрываете сервис, сервис регистрации автоматически обновит ваш список сервисов. Когда вы позвоните, вы получите последний список услуг из регистрационного центра для звонка. Чтобы не влиять на производительность, вы также можете кэшировать список сервисов на клиенте

Ответ 5

В облачной среде, где образы докеров динамически разворачиваются на любом компьютере или комбинации IP + порт, зависимым сервисам становится сложно обновлять во время выполнения. Обнаружение службы создается только для этой цели.

Обнаружение служб - это одна из служб, работающих в архитектуре микросервисов, которая регистрирует записи всех служб, работающих в сетке служб. Все действия доступны через REST API. Поэтому, когда службы запущены и работают, отдельные службы регистрируются в службе обнаружения служб, а службы обнаружения служб поддерживают сердцебиение, чтобы убедиться, что эти службы работают. Это также служит для целей мониторинга услуг. Обнаружение служб также помогает распределять запросы между службами, развернутыми на справедливой основе.