Принцип и сравнение нескольких компонентов регистрации и обнаружения служб в распределенных

Основные принципы и сравнение Eureka, Consul и Zookeeper.

предисловие

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

решенная проблема

В распределенной системе компоненты регистрации и обнаружения служб в основном решают две задачи: регистрация служб и обнаружение служб.

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

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

Мониторинг. В приложении микрослужбы служба находится в динамической ситуации, и для обработки недопустимых экземпляров службы требуется определенный механизм. Вообще говоря, экземпляр службы и реестр поддерживают связь через пульс после регистрации.Если пульс отсутствует, соответствующий экземпляр службы будет удален реестром.
Балансировка нагрузки: может быть несколько экземпляров одной и той же службы одновременно, и балансировка нагрузки службы должна выполняться правильно.

CAP

Принцип CAP означает, что в распределенной системе согласованность, доступность и устойчивость к разделам не могут быть установлены одновременно.

Непротиворечивость: требуется, чтобы все резервные копии данных в распределенной системе находились в одном и том же состоянии в один и тот же момент времени.
Доступность: после выхода из строя некоторых узлов в системном кластере система по-прежнему может отвечать на запросы пользователей.
Отказоустойчивость раздела: система может допустить сбой связи в сетевом интервале.

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

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

В компонентах регистрации и обнаружения службы, которые мы представим далее, Eureka удовлетворяет AP, а Consul и Zookeeper удовлетворяют CP.

Eureka

Eureka — это компонент регистрации и обнаружения служб, разработанный на языке Java и основанный на Restful Api с открытым исходным кодом от Netflix. К сожалению, в настоящее время Eureka имеет открытый исходный код только для версии 1.X, а версия 2.X объявлена закрытой.

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

Схема его архитектуры показана ниже:

Служба приложений: как клиент Eureka, он действует как поставщик услуг, предоставляет бизнес-услуги, регистрирует и обновляет свою собственную информацию на сервере Eureka, а также может получать информацию о других службах из реестра сервера Eureka.
Eureka Server: играет роль реестра сервисов и предоставляет функции для регистрации и обнаружения сервисов.Каждый Eureka Cient регистрирует свою информацию на Eureka Server, а также может получать информацию о других сервисах через Eureka Server с целью обнаружения и вызова других сервисов. .
Клиент приложения: как клиент Eureka, он действует как потребитель услуг и получает информацию о других службах, зарегистрированных на нем, через сервер Eureka, чтобы найти необходимую услугу и инициировать удаленный вызов в соответствии с информацией.
Репликация: Синхронная копия информации реестра в Eureka Server для обеспечения согласованности информации об экземпляре службы в реестрах в разных кластерах Eureka Server. Обеспечивает возможную согласованность данных.
Сделать удаленный вызов: Удаленный вызов между службами.
Регистрация: зарегистрируйте экземпляр службы, и клиентская сторона зарегистрирует свои собственные метаданные на стороне сервера для обнаружения службы.
Продлить: Продлить контракт, поддерживать и обновлять действительность метаданных экземпляра службы в реестре, отправляя пульс на сервер. Если сервер не получает информацию о пульсе клиента в течение определенного периода времени, служба по умолчанию будет отключена, а информация об экземпляре службы будет удалена из реестра.
Отмена: служба отключается, и клиент активно отменяет метаданные экземпляра службы с сервера, когда он закрывается. В это время данные экземпляра службы клиента будут удалены из реестра сервера.

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

Consul

Consul — это сервисное программное обеспечение для публикации и регистрации сервисов, разработанное HashiCorp на основе языка Go, которое поддерживает распределенную высокую доступность нескольких центров обработки данных, использует алгоритм Raft для обеспечения согласованности сервисов и поддерживает проверки работоспособности.

Consul принимает дизайн модели «главный-подчиненный», так что количество кластеров может быть увеличено в больших масштабах, а кластеры вызываются через RPC (HTTP и DNS). Его структурная схема выглядит следующим образом:

Клиент: как прокси (экземпляр, не являющийся микрослужбой), он будет перенаправлять все запросы RPC на сервер. Поскольку служба относительно не имеет гражданства, она не содержит никакой регистрационной информации.
Сервер: как прокси с расширенными функциями, он будет отвечать на запросы RPC, участвовать в выборах Raft, поддерживать статус кластера и пересылать запросы лидерам и т. д.
Leader-Server: все серверы в центре обработки данных являются частью набора узлов Raft. Лидер будет отвечать за все запросы и транзакции (такие как регистрация службы), и эти транзакции также будут реплицироваться на все остальные узлы.
Центр обработки данных. Центр обработки данных — это частная сетевая среда с низкой задержкой и высокой пропускной способностью. В каждом дата-центре будет кластер Consul, обычно рекомендуется 3-5 серверов (учитывая доступность и компромиссы производительности алгоритма Raft), при этом лидер может быть только уникальным, а количество клиентов не ограничена, что может быть легко расширено.

Алгоритм плота

Алгоритм Raft делит Серверы на три типа: Лидер, Последователь и Кандидат. Лидер обрабатывает все запросы и транзакции и синхронизирует транзакции с подписчиками. Последователь будет пересылать все запросы и транзакции RPC ведущему для обработки и принимает синхронизацию транзакций только от ведущего. Согласованность данных реализуется на основе данных в лидере.

Когда узел первоначально запущен, конечный автомат Raft узла будет находиться в состоянии Follower, ожидая пульса от узла Leader. Если пульс узла-лидера не получен в течение определенного периода времени, узел инициирует выборы.

Когда узел-последователь выбран, он изменит свое состояние на «Кандидат», а затем отправит запрос другим узлам-последователям в кластере, чтобы узнать, выбирает ли он себя в качестве лидера. Получив одобрение более чем от половины узлов кластера, узел становится лидером, начинает получать обработку транзакций и запросы от клиента и синхронизирует транзакции с другими узлами-последователями. Узел-лидер будет периодически отправлять пульсации последователям, чтобы поддерживать их статус.

протокол сплетен

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

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

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

Zookeeper

Изначально Zookeeper был службой распределенной координации с открытым исходным кодом от Yahoo.Это важный компонент Hadoop и Hbase, предоставляющий такие функции, как данные/публикация и подписка, балансировка нагрузки и распределенная синхронизация.

Zookeeper также основан на архитектуре master-slave и создает хорошо масштабируемый сервисный кластер.Его сервисная архитектура выглядит следующим образом:

Лидер-Сервер: Лидер отвечает за инициирование и разрешение голосования, а также за обновление статуса данных в системе.
Сервер: в сервере есть два типа: подписчик и наблюдатель. Подписчик принимает запрос клиента и возвращает результат (запрос на транзакцию будет передан Лидеру для обработки), а также участвует в голосовании в процессе выборов; Наблюдатель выполняет те же функции, что и Подписчик, но не участвует в голосовании. процесс, его существование заключается в повышении скорости чтения системы
Клиент: инициатор запроса, сервер и клиент могут взаимодействовать через длинное соединение. Например, инициирование регистрации или запрос информации о кластере и т. д.

Заб протокол

Протокол ZooKeeper Atomic Broadcast специально разработан для Zookeeper для достижения согласованности данных в распределенных системах и разработан на основе алгоритма Paxos. Он использует одного лидера для приема и обработки всех запросов транзакций от клиентов и рассылает изменения состояния данных сервера на все серверы в форме предложений транзакций. В то же время это гарантирует, что при выходе из строя лидера кластер сможет нормально работать. Заб включает в себя два основных режима: восстановление после сбоя и широковещательная рассылка сообщений.

Восстановление после сбоя: ведущий сервер не работает или ведущий сервер теряет связь с более чем половиной последователей из-за проблем с сетью, после чего он переходит в режим восстановления после сбоя для выбора нового лидера. Алгоритм выбора лидера должен не только сообщать лидеру, что он был избран в качестве лидера, но также должен позволять всем остальным серверам в кластере быстро воспринимать нового избранного лидера. Когда избран новый лидер и более половины серверов в кластере завершили синхронизацию состояния с лидером, протокол Zab выйдет из режима аварийного восстановления и перейдет в режим широковещательной рассылки сообщений.
Широковещательная рассылка сообщений: процесс широковещательной рассылки сообщений протокола Zab аналогичен двухэтапному процессу подготовки, который является атомарным протоколом широковещательной рассылки. При получении запроса на транзакцию (например, на регистрацию услуги) от Клиента (все запросы на транзакцию будут перенаправлены Лидеру) Лидер сгенерирует соответствующее Предложение для транзакции и присвоит ему глобально уникальный ZXID. Существует отдельная очередь для отправки и получения сообщений между сервером-лидером и каждым ведомым, и лидер отправляет сгенерированное предложение в очередь. Последователь извлекает предложение из очереди на потребление транзакции и отправляет ACK лидеру после завершения потребления. Когда Лидер получает голоса ACK, отправленные более чем половиной Последователей, он отправит Коммит всем Подписчикам, чтобы уведомить их о совершении транзакции, а сам Лидер также зафиксирует транзакцию и вернет ее соответствующему клиенту, если обработка успешно. Подписчик доступен только после синхронного потребления всех предложений в очереди.

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

Сходства и различия

Наконец, мы примерно понимаем сходства и различия между Eureka, Consul и Zookeeper через таблицу. Какой тип компонентов регистрации и обнаружения службы выбрать, можно определить в соответствии с требованиями вашего собственного проекта.

имя компонента	язык	CAP	алгоритм консенсуса	Проверка работоспособности службы	Внешний вид интерфейса	Интеграция с Spring Cloud
Eureka	Java	AP	никто	Настраиваемая поддержка	HTTP	интегрированный
Consul	Go	CP	Raft	служба поддержки	HTTP/DNS	интегрированный
Zookeeper	Java	CP	Paxos	служба поддержки	клиент	интегрированный