[Примечание редактора] В этой статье сравниваются три инструмента обнаружения служб, Zookeeper, etcd и Consul, и обсуждается лучшее решение для обнаружения служб только для справки.
Если вы используете предопределенные порты, чем больше у вас служб, тем больше вероятность возникновения конфликтов, ведь невозможно, чтобы две службы прослушивали один и тот же порт. Управление переполненным списком, скажем, всех портов, используемых сотнями служб, само по себе является сложной задачей, и добавление к этому списку потребует все большей базы данных и количества служб. Поэтому мы должны развернуть сервис без указания порта, и пустьDockerНазначьте нам случайный порт. Единственная проблема заключается в том, что нам нужно узнать номер порта и сообщить об этом другим.
Все становится сложнее, когда мы начинаем развертывать службу в распределенной системе на одном из серверов, мы можем выбрать способ предопределить, какой сервер запускает какую службу, но это может вызвать много проблем. Мы должны изо всех сил стараться максимально использовать ресурсы сервера, но если место развертывания каждой службы предопределено, добиться максимального использования ресурсов сервера практически невозможно. Другая проблема заключается в том, что автоматическое масштабирование сервисов будет очень затруднено, не говоря уже об автоматическом восстановлении, например, в случае сбоя сервера. С другой стороны, если мы развертываем службу на сервере с минимальным количеством запущенных контейнеров, нам нужно добавить IP-адрес в список данных, которые должны быть доступны для обнаружения и где-то храниться.
Есть много других примеров, когда нам нужно хранить и обнаруживать некоторую информацию, связанную с сервисом на работе.
Чтобы иметь возможность найти службу, нам нужны как минимум два следующих полезных шага.
- регистрация службы—— Информация, хранящаяся на этом шаге, включает как минимум информацию о хосте и порте работающей службы.
- обнаружение службы- Этот шаг позволяет другим пользователям обнаружить информацию, сохраненную на этапе регистрации службы.
В дополнение к вышеперечисленным шагам нам также необходимо рассмотреть другие аспекты. Если служба перестает работать и развертывается или регистрируется новый экземпляр службы, следует ли отменить регистрацию службы? Что делать, если существует несколько копий одного и того же сервиса? Как мы можем сделать балансировку нагрузки? Что если сервер выйдет из строя? Все эти вопросы тесно связаны с этапами регистрации и обнаружения. На данный момент мы ограничены областью обнаружения служб (обычное название, связанное с описанными выше шагами) и инструментами для задач обнаружения служб, большинство из которых используют высокодоступные распределенные хранилища ключей и значений.
инструмент обнаружения служб
Основная цель инструмента обнаружения сервисов состоит в том, чтобы сервисы находили друг друга и взаимодействовали друг с другом. Для этого инструмент должен знать о каждом сервисе. Это не новая концепция. До Docker было много подобных инструментов. Однако контейнеры приносят Это совершенно новый уровень спроса на инструменты.Основная идея обнаружения службы заключается в том, чтобы каждый новый экземпляр (или приложение) службы мог идентифицировать текущую среду и хранить соответствующую информацию. Сама хранимая информация реестра обычно представлена в формате пар ключ/значение, и, поскольку обнаружение служб часто используется в распределенных системах, эта информация должна быть масштабируемой, отказоустойчивой и распределенной по всем узлам кластера. Основная цель этого хранилища состоит в том, чтобы предоставить всем заинтересованным сторонам, по крайней мере, информацию, такую как IP-адреса службы и порты для связи между ними, эти данные часто распространяются на другие типы инструментов обнаружения информационных служб, которые имеют тенденцию предоставлять некоторую форму API для регистрация услуг и поиск информации об услугах.
Допустим, у нас есть две службы, одна из которых является поставщиком, а другая — потребителем первой службы. После развертывания поставщика услуг его информацию необходимо сохранить в реестре обнаружения служб. Затем, когда потребитель пытается получить доступ к поставщику услуг, он сначала запрашивает реестр услуг и вызывает поставщика услуг с полученным IP-адресом и портом. Чтобы отвязаться от конкретной реализации поставщика услуг в реестре, мы часто используем какой-то прокси-сервис. Таким образом, потребители всегда запрашивают информацию у прокси-сервера с фиксированным IP-адресом, а прокси-сервер, в свою очередь, использует обнаружение службы, чтобы найти информацию о поставщике услуг и перенаправить запрос, что мы делаем позже в этой статье через обратный прокси-сервер. Теперь важно понять процесс обнаружения службы на основе трех ролей (потребитель службы, поставщик и прокси).
Инструменты обнаружения сервисов ищут данные, по крайней мере, мы должны быть в состоянии узнать, где сервисы? Является ли служба работоспособной и доступной? Как выглядит конфигурация? Поскольку мы строим распределенную систему на нескольких серверах, инструмент должен быть достаточно надежным, чтобы гарантировать, что сбой одного из узлов не поставит под угрозу данные, и в то же время на каждом узле должна быть одна и та же копия данные, кроме того, мы надеемся, что у нас будет возможность запускать службы в любом порядке, убивать службы или заменять новые версии служб, мы также должны иметь возможность перенастраивать службы и видеть, как данные изменяются соответственно.
Давайте взглянем на некоторые общие варианты для достижения целей, которые мы поставили выше.
Ручная настройка
Большинство сервисов по-прежнему управляются вручную, и мы заранее определяем, где развернуть сервис, как его настроить, и надеемся, что какой бы ни была причина, сервис продолжит работать до конца дня. Такая цель не может быть легко достигнута. Развертывание второго экземпляра службы означает, что нам нужно запустить полный ручной процесс, нам нужно ввести новый сервер или выяснить, какой сервер использует ресурсы, а затем создать новый набор конфигурации и запустить службу. Ситуация может усложняться, например, время отклика при ручном управлении становится медленным из-за аппаратного сбоя. Еще одна болевая точка — наглядность, мы знаем, что такое статическая конфигурация, ведь она готовится нами заранее, однако в большинстве сервисов много динамически генерируемой информации, которую нелегко увидеть, и для нас нет единого места. При необходимости обращайтесь к этим данным.Время реакции неизбежно замедляется, а восстановлением после сбоя и мониторингом может стать очень трудно управлять, учитывая множество движущихся компонентов, которые необходимо обрабатывать вручную.
Хотя в прошлом было оправдание не выполнять эту работу или когда количество сервисов/серверов было небольшим, с появлением инструментов обнаружения сервисов этого оправдания больше не существует.
Zookeeper
ZookeeperОдин из старейших проектов такого типа, созданный в Hadoop и помогающий поддерживать различные компоненты в кластере Hadoop. Он очень зрелый, надежный и используется многими крупными компаниями (YouTube, eBay, Yahoo и т. д.). Формат хранения данных аналогичен файловой системе: при работе в кластере серверов Zookeper будет делиться состоянием конфигурации между всеми узлами, каждый кластер выбирает лидера, а клиенты могут подключаться к любому серверу для получения данных.Основным преимуществом Zookeeper является его зрелость, надежность и многофункциональность, однако у него также есть свои недостатки, виновниками которых является принятие Java-разработки и сложность. Хотя Java великолепна во многих отношениях, она все еще слишком тяжела для такого типа работы, а использование Zookeeper Java и ее значительное количество зависимостей делает ее очень ресурсоемкой. Из-за этих проблем, описанных выше, Zookeeper становится очень сложным, и его обслуживание требует больше знаний, чем мы ожидаем от этого типа приложений. Отчасти это связано с тем, что обилие функций превращает его из преимущества в недостаток. Чем больше функций есть в приложении, тем больше вероятность того, что эти функции не понадобятся, поэтому мы в конечном итоге заплатим цену сложности за эти ненужные функции.
Zookeeper проложил путь к значительным улучшениям в других проектах, и «игроки больших данных» используют его, потому что лучшей альтернативы нет. Сегодня Zookeeper стареет, и у нас есть варианты получше.
etcd
etcdЭто система хранения пар ключ/значение, использующая протокол HTTP, которая представляет собой систему конфигурации распределенного и функционального уровня, которую можно использовать для создания системы обнаружения служб. Его легко развернуть, установить и использовать, а также он обеспечивает надежные функции сохранения данных. Это безопасно и хорошо документировано.etcd — лучший выбор, чем Zookeeper, из-за его простоты, однако он требует некоторых сторонних инструментов для обеспечения обнаружения служб.
Теперь, когда у нас есть место для хранения информации, связанной с обслуживанием, нам также нужен инструмент, который может автоматически отправлять информацию в etcd. Но после этого зачем нам вручную отправлять данные в etcd? Даже если мы хотим вручную отправить информацию в etcd, мы обычно не знаем, что это за информация. Имея это в виду, сервис может быть развернут на сервере с минимальным количеством контейнеров с назначенным случайным портом. В идеале этот инструмент должен отслеживать контейнеры Docker на всех узлах и обновлять etcd всякий раз, когда запускается новый контейнер или останавливается существующий.Одним из инструментов, который может помочь нам в этом, является Registrator.
Registrator
RegistratorВ настоящее время он поддерживает etcd, Consul и SkyDNS 2, автоматически регистрируя и отменяя регистрацию сервисов, проверяя, находится ли контейнер в сети или отключен.Registrator и etcd — это простая, но мощная комбинация, которая может работать со многими передовыми технологиями. Всякий раз, когда мы открываем контейнер, все данные будут храниться в etcd и распространяться на все узлы в кластере. Мы решим, какая информация принадлежит нам.
В приведенной выше головоломке по-прежнему отсутствует часть, нам нужен способ создания файлов конфигурации с данными, хранящимися в etcd, путем запуска некоторых команд для создания этих файлов конфигурации.
Confd
Confdэто легкий инструмент управления конфигурацией, обычно используемый для обновления файлов конфигурации с использованием данных, хранящихся в etcd, consul и некоторых других реестрах данных, его также можно использовать для перезагрузки приложений при изменении файлов конфигурации. Другими словами, мы можем перенастроить все службы с информацией, хранящейся в etcd (или другом реестре).Заключительные мысли о комбинации etcd, Registrator и Confd
Когда etcd, Registrator и Confd объединены, можно получить простой и мощный способ автоматизировать обнаружение всех наших сервисов и необходимую настройку. Эта комбинация также показывает эффективность правильного сочетания «маленьких» инструментов, эти три мелочи могут сделать именно то, что нам нужно для достижения того, что мы хотим, с чуть меньшим размахом мы не сможем достичь цели, стоящей перед нами. нас, а с другой стороны, если бы они были разработаны с учетом большего масштаба, мы бы добавили ненужную сложность и накладные расходы на серверные ресурсы.Прежде чем мы вынесем окончательный вердикт, давайте посмотрим на другую комбинацию инструментов с той же целью, ведь мы не должны довольствоваться несколькими вариантами без альтернатив.
Consul
ConsulЭто строго согласованное хранилище данных, использующее сплетни для формирования динамического кластера. Он предоставляет иерархическое хранилище ключей и значений, которое может не только хранить данные, но и может использоваться регистратором для различных задач, от отправки уведомлений об изменениях данных до выполнения проверок работоспособности и пользовательских команд, в зависимости от их выходных данных.В отличие от Zookeeper и etcd, Consul реализует встроенную систему обнаружения сервисов, поэтому нет необходимости создавать собственную систему или использовать стороннюю систему. В дополнение к функциям, упомянутым выше, эта система обнаружения также включает проверки работоспособности узла и запущенные на нем службы.
Zookeeper и etcd предоставляют только хранилище очередей необработанных ключей/значений, что требует от разработчиков приложений создания собственных систем для предоставления возможностей обнаружения служб. Consul предоставляет встроенную систему обнаружения сервисов. Клиентам нужно только зарегистрировать службу и выполнить обнаружение службы через интерфейс DNS или HTTP. Два других инструмента требуют решения, созданного вручную, или прибегают к помощи сторонних инструментов.
Консул предоставляет встроенную встроенную поддержку для различных центров обработки данных, где система сплетен может работать не только на отдельных узлах в рамках одного кластера, но и между центрами обработки данных.
У Consul есть еще одна приятная функция, которая отличает его от других инструментов: его можно использовать не только для обнаружения развернутых сервисов и узлов, на которых они находятся, но также с помощью HTTP-запросов, TTL (время жизни) и пользовательских команд. Легко расширяемая проверка работоспособности. Особенности.
Registrator
RegistratorСуществует два протокола Consul, из которых протокол consulkv дает результаты, аналогичные протоколу etcd.Помимо обычного IP и порта, хранящихся в протоколе etcd или consulkv, в протоколе Registrator consul хранится больше информации, мы можем получить информацию о узле, на котором запущен сервис, а также идентификатор и имя сервиса. Мы также можем хранить дополнительную информацию по определенным тегам с помощью некоторых дополнительных переменных среды.
Consul-template
confd можно использовать с Consul так же, как и etce, но у Consul есть собственная служба шаблонов, которая больше подходит для Consul.Из информации, полученной от Консула,Consul-templateэто очень удобный способ создания файлов, который имеет дополнительное преимущество, заключающееся в возможности запуска произвольных команд после обновления файла, как и в случае с confd, также можно использовать Consul-templateПерейти шаблоныФормат.
Проверка работоспособности Consul, веб-интерфейс и дата-центр
Мониторинг работоспособности узлов и служб кластера так же важен, как и их тестирование и развертывание. Хотя мы должны работать над созданием стабильной среды, которая никогда не дает сбоев, мы также должны осознавать, что неожиданные сбои могут произойти в любое время, и быть готовыми принять соответствующие меры. Например, мы можем отслеживать использование памяти, и если оно достигает определенного порога, то в качестве меры предосторожности переносим некоторые службы на другой узел в кластере, прежде чем произойдет «катастрофа». С другой стороны, не все потенциальные сбои могут быть своевременно обнаружены и устранены. Один сервис может выйти из строя, а целый узел может перестать работать из-за аппаратного сбоя. В этом случае мы должны быть готовы действовать как можно скорее, например, заменить узел новым и перенести неисправный сервис. В Consul есть простой, элегантный, но мощный способ проверки работоспособности, помогающий пользователю определить, какие действия следует выполнять при достижении определенного количества порогов работоспособности.Если пользователь погуглит «etcd ui» или «etec dashboard», пользователь может увидеть, что доступно лишь несколько решений, и может спросить, почему мы не представили его пользователю, причина проста, etcd — это просто хранилище пары ключ/значение, вот и все. Представление данных через пользовательский интерфейс не очень полезно, так как мы можем легко получить эти данные через etcdctl. Это не означает, что пользовательский интерфейс etcd бесполезен, но, учитывая его ограниченную сферу использования, он не будет иметь большого значения.
Consu — это не просто хранилище пар ключ/значение, как мы уже видели, в дополнение к хранению простых пар ключ/значение, у него есть концепция сервиса и данных, которым он принадлежит. Он также может выполнять проверки работоспособности, что делает его хорошим кандидатом на панель мониторинга, где мы можем видеть состояние наших узлов и запущенных служб. Наконец, он поддерживает концепцию нескольких центров обработки данных. Сочетание всех этих функций позволяет нам увидеть потребность в дашбордах с другой точки зрения.
Через веб-интерфейс Consul пользователи могут просматривать все сервисы и узлы, отслеживать состояние проверки работоспособности, а также читать и устанавливать данные пар «ключ-значение», переключая центры обработки данных.
Заключительные мысли о консуле, регистраторе, шаблоне, проверках работоспособности и веб-интерфейсе
Consul и инструменты, которые мы обсуждали выше, во многих случаях обеспечивают лучшее решение, чем etcd. Это решение, разработанное с душой для сервисной архитектуры и обнаружения, простое и мощное. Он предоставляет полное и краткое решение, которое во многих случаях является лучшим инструментом для обнаружения служб и проверки работоспособности.в заключении
Все эти инструменты основаны на схожих принципах и архитектурах, они работают на узлах, требуют кворума для работы, строго согласованы и все обеспечивают некоторую форму хранилища ключей/значений.ZookeeperОдин из старейших из них, возраст показывает его сложность, использование ресурсов и цели с максимальным усилием, он был разработан для другой эпохи, чем другие инструменты, которые мы оценивали (даже если они не слишком стары).
etcd,RegistratorиConfdэто очень простая, но очень мощная комбинация, которая может решить большинство, если не все, потребности в обнаружении сервисов. Это также показывает, что мы можем достичь мощных возможностей обнаружения сервисов, комбинируя очень простые и специфические инструменты, каждый из которых выполняет очень специфическую задачу, взаимодействует через хорошо спроектированные API-интерфейсы, имеет возможность работать относительно автономно, как архитектурно, так и функционально.МикросервисыСпособ.
ConsulРазница в том, что вам не нужны сторонние инструменты, может быть встроенная поддержка нескольких центров обработки данных и проверки работоспособности, это не означает, что вы не используете сторонние инструменты. На самом деле, в этом блоге мы не будем вводить в то же время повышение производительности, выбрав те ненужные функции инструмента, попробуйте комбинацию различных инструментов. Используйте правильные инструменты, чтобы получить наилучшие результаты. Если орудие не требует введения эксплуатационных характеристик, то эффективность работы но будет снижаться, с другой стороны, если орудие не обеспечивает характеристик, необходимых для работы безрезультатно. Consul хороший баланс веса, так как несколько вещей достигли цели.
То, как Consul использует слухи для распространения информации о кластере, упрощает его настройку по сравнению с etcd, особенно для крупных центров обработки данных. Возможность хранить данные как службу делает ее более полной и полезной, чем простая функция хранения ключей/значений в etcd (даже у Consul есть такая возможность). В то время как мы можем достичь той же цели в etcd, вставив несколько ключей, служба Consul достигает более компактного результата, обычно требуя только одного запроса для получения всех данных, связанных с службой. Кроме того, Регистратор очень хорошо реализует два протокола Консула, объединяя их в один, особенно добавляя в головоломку Consul-template. Консул Веб Пользовательский интерфейс — это вишенка на торте, обеспечивающая визуальный подход к службам и проверкам работоспособности.
Не могу сказать, что Consul явно выигрывает, но у него есть небольшое преимущество перед etcd. Обнаружение сервисов как концепция и как инструмент является очень новым, и мы можем ожидать много изменений в этой области. Непредвзято, вы можете принять советы в этой статье с долей скептицизма, попробовать разные инструменты и прийти к собственному выводу.
Оригинальная ссылка:Service Discovery: Zookeeper vs etcd vs Consul(Перевод: Ху Чжэнь)
=================================================================
Введение переводчика: Ху Чжэнь, бывший главный архитектор и технический директор начинающей интернет-финансовой компании, теперь отвечает за техническое управление и архитектурный дизайн в команде архитекторов Центра финансовых технологий Ping An.