Как обнаружение сервисов не является частью централизованной конфигурации?

Я ищу инструменты консенсусного типа, такие как ZooKeeper, Consul и Eureka, и все они, похоже, продают тот же набор решений:

  • Обнаружение службы
  • Динамическое централизованное управление конфигурацией
  • Примитивы синхронизации
  • Алгоритмы консенсуса

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

Мое понимание (пока) обнаружения служб заключается в том, что оно позволяет узлам динамически искать, находить удаленные службы и подключаться к ним. Таким образом, если приложение использует AuthService для аутентификации, авторизации, оно будет использовать обнаружение служб, чтобы найти узел AuthService в, скажем, http://auth103.example.org:9103 и использовать его.

Мое понимание систем динамической конфигурации состоит в том, что они предоставляют централизованную инфраструктуру для узлов, чтобы динамически получать обновления с серверов конфигурации, а также публиковать обновления на них. Поэтому, если экземпляр приложения решает, что ему необходимо обновить конфигурацию для всех других экземпляров, он свяжется со службой конфигурации и обновит, скажем, numPurgerThreads config. Затем служба конфигурации обновит все другие экземпляры приложения, чтобы они правильно обновили свои соответствующие конфигурации.

Но разве это не одна и та же проблема?

В обоих случаях вы:

  1. Подключитесь к какой-либо службе поиска
  2. Запросить данные; или
  3. Публикуйте в нем данные, которые затем передаются другим узлам.

Обнаружение служб - это динамическая конфигурация, верно?!?!

На самом деле я стремлюсь к следующему: Не могу ли я просто реализовать одну службу конфигурации с одним из этих инструментов, который по совпадению также решает проблему обнаружения служб? Или есть причина, по которой мне нужно, скажем, 1 кластер Consul для управления конфигурацией / KV, а другой, скажем, кластер Consul для обнаружения служб?


service-discovery consul distributed-computing apache-zookeeper consensus
person smeeb    schedule 23.06.2015    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Что ж, если вы посмотрите на это так, это все просто разновидности баз данных или хранилищ данных, если хотите, как вы это описываете:

Connect to a lookup service of some sort
Query it for data; or
Publish data to it, which then ripples out to other nodes

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

В частности, в случае обнаружения службы хорошей функцией может быть обнаружение сбоя - например, k / v-магазин, позволяющий удалять служебные данные, когда служба больше не подключена. Таким образом, вы можете зарегистрировать службу в своем средстве обнаружения служб и знать, что, когда служба выйдет из строя или потеряет соединение, она больше не будет присутствовать в сохраненных данных.

person igorbel    schedule 23.06.2015

arrow_upward
0
arrow_downward

Чтобы прояснить несколько терминов, (imo) динамические системы конфигурации могут обновлять свое состояние во время выполнения, в отличие от статических, где все определяется заранее (т.е. файлы конфигурации). Централизованный CM означает, что все данные конфигурации хранятся в одном месте. Итак, централизованный CM может быть как статическим, так и динамическим, не так ли?

IMO, обнаружение служб имеет компонент, которого нет в CM, и это протокол для автоматического обнаружения служб.

Думаю, вам понадобится динамический CM (хранилище KV) для реализации обнаружения служб, но вы не можете реализовать хранилище CM, просто используя обнаружение служб (протокол). Возьмем, к примеру, DHCP (надеюсь, мы согласны с тем, что это протокол обнаружения служб?) - Dynamic Host Configuration Protocol ', поэтому он имеет аспект конфигурации, но также и протокол, который представляет собой немного больше, чем простое хранилище KV. Кстати, он децентрализован, просто чтобы проиллюстрировать предыдущий момент, что CM не обязательно должен быть централизованным.

Таким образом, обнаружение службы имеет аспект конфигурации, но CM не (обязательно) имеет аспект обнаружения службы. Означает ли это, что SD - это подмножество CM? Я бы сказал нет.

person milan    schedule 23.07.2015