Мы сделали распределенный реестр

открытие

Эта статья основана на совместном использовании и кратком изложении станции SOFA Meetup Hefei. Она в основном направлена на позиционирование и введение функций центра регистрации. Благодаря анализу истории развития Центра регистрации муравьев я покажу вам, как Центр регистрации муравьев шаг за шагом превратился в настоящее по масштабу и характеру.

Для получения более подробных технических деталей вы можете присоединиться к сообществам SOFA и SOFARegistry, чтобы изучить результаты.

Что такое реестр

Обнаружение службы и регистрация службы

Проще говоря, реестр должен решить проблему взаимного обнаружения между службами в распределенном сценарии.

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

Вообще говоря, он делится на два пункта:

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

процесс вызова

Как показано на рисунке выше, это текущая основная модель реестра, как SOFARegistry, так и Nacos.

Служба A и служба B сообщают свою собственную служебную информацию в центр регистрации через SDK или REST.
Когда службе A необходимо вызвать службу B, она инициирует запрос к реестру, чтобы получить список IP-адресов службы и информацию, связанную со службой B.
После получения списка службы B вы можете получить доступ к службе B с помощью самоопределяемого алгоритма балансировки нагрузки.

сердцебиение

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

Узел службы B отключен от сети или зависает, вызывая тайм-аут пульса; или простои или отключение напрямую вызывают сбой пульса
Реестр вытаскивает проблемный узел из собственного хранилища (здесь вытягивание основано на конкретной реализации: некоторые удаляются напрямую, а некоторые помечаются как неработоспособные)
Служба А получает уведомление от центра регистрации и получает последний список службы Б.

Регистрационный центр ДУББО

Давайте посмотрим, как используется центр регистрации и сам процесс на примере DUBBO.

Во-первых, настройки DUBBO в 2.7 и 3.0 немного отличаются, но все они просты и понятны, и все они здесь.

DUBBO-2.7

DUBBO-3.0

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

протокол (тип протокола), например, zookeeper
host
port

Исходя из этого, процесс регистрации dubbo показан на следующем рисунке

Производитель услуги инициирует регистрационное действие (регистрацию) в реестре через клиент DUBBO.
Потребитель услуги подписывается на информацию через клиент DUBBO (подписка)
Центр регистрации отправляет список услуг потребителю услуг посредством уведомления

Характер реестра

Благодаря предыдущему объяснению и конкретным примерам компонентов DUBBO мы, вероятно, можем обобщить суть реестра.

«Хранение» + «Оперативный»

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

Хроника реестра муравьев

доисторические времена

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

Эпоха жестких нагрузок

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

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

Реестр первого поколения — эволюция от жесткой загрузки к мягкой загрузке

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

Единственная проблема (если все вызовы идут на F5, после зависания F5 многие сервисы будут недоступны)
Проблема пропускной способности (трафик, передаваемый F5, слишком высок, что само по себе станет узким местом в производительности)

В это время Ant представил продукт под названием ConfigServer от Ali Group, который используется в качестве реестра.Архитектура этого реестра очень похожа на архитектуру, упомянутую в начале.Доступ к службам можно получить напрямую через IP, что снижает потребность в Сильная зависимость продуктов балансировки нагрузки снижает единичные риски.

Реестр второго поколения -- ScaleUp? Масштабирование? Это проблема

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

Единая точка риска (сам реестр является автономным приложением)
Узкое место емкости (количество подключений и емкость хранилища данных одного реестра ограничены)

Есть два решения

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

Муравьи и Taobao пошли двумя разными путями, и они также продвинули эволюцию независимой экосистемы позади муравьев.

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

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

Реестр пятого поколения — рождение метаузлов

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

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

Когда возникают все эти проблемы, мы обнаруживаем, что можем ввести узел центра управления метаданными (Meta), чтобы решить проблему управления данными и сеансами. Доступ к данным и сеансу можно получить через 4-уровневую загрузку или 7-уровневую загрузку в мета.

По сравнению с решениями в отрасли есть похожие модели, например, Name Node и Kafka HDFS зависят от ZK, Oceanbase зависит от RootServer, а центр конфигурации Apollo зависит от Euraka.

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

Реестр шестого поколения -- реестр, ориентированный на эксплуатацию и обслуживание

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

Выпуск узлов данных по-прежнему является проблемой из-за большого объема данных.
На только что добавленном узле Сессионного узла может длительное время отсутствовать трафик

Подождите, для этих проблем, на основе SOFARegistry5.x, мы быстро итерировали версию 6.0, которая в основном является реестром для эксплуатации и обслуживания.

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

Улучшить алгоритм хранения данных (consistent-hash -> hash-slot)
Обнаружение служб на уровне приложений

Эволюция алгоритмов хранения

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

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

Таким образом, степень детализации миграции данных может быть основана только на данных, хранящихся в одном узле данных.В случае большого объема данных (один узел 8G) это окажет определенное влияние на реконструкцию данных, и в случае непрерывного простоя данных В случае потери или несогласованности данных могут быть сценарии.

Для улучшенного алгоритма мы обращаемся к механизму алгоритма Redis Cluster и используем хеш-слоты для сегментирования данных.

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

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

Обнаружение служб на уровне приложений

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

Открытый исходный код

SOFARegistry начал процесс открытого исходного кода с ранней стадии проекта.Сравнение с текущим основным реестром выглядит следующим образом.

Мы считаем, что первое, что реестр должен решить, — это проблему доступности, поэтому в вопросе распределенной согласованности мы выбираем модель AP, которая также согласуется с основными реестрами, такими как Euraka и Nacos.

Во-вторых, с точки зрения производительности SOFARegistry, основанный на длинных соединениях, имеет более короткую задержку отправки, которая меньше, чем у Nacos 1.0 (Nacos 1.0 основан на модели Long Polling, а Nacos 2.0 также использует модель длинных соединений).

Что касается протоколов, SOFARegistry использует стек протоколов ant с открытым исходным кодом: потоковый протокол протокола BOLT (аналогичный HTTP2.0), который является более легким, и полнодуплексный режим самого протокола: неблокирующий, который значительно улучшает использование ресурсов.

Feature	Consul	Zookeeper	Etcd	Eureka	Nacos	SOFARegistry
Проверка работоспособности службы	Периодическая проверка работоспособности (http/tcp/script/docker)	Периодическое сердцебиение для поддержания сеанса (сеанса) + TTL	Периодическое обновление(http)+TTL	Периодическое сердцебиение + TTL; поддержка пользовательской проверки работоспособности	Регулярное пульсирование ссылки + неработающая ссылка	Регулярное сердцебиение подключения + чувствительное к отключению
Несколько центров обработки данных	служба поддержки	-	-	-	служба поддержки	служба поддержки
Служба хранения кв	служба поддержки	служба поддержки	служба поддержки	-	служба поддержки	служба поддержки
последовательность	raft	ZAB	raft	окончательная согласованность	В конечном счете непротиворечивый (центр регистрации) Raft (центр конфигурации)	окончательная согласованность
cap	cp	cp	cp	ap	ap+cp	ap
Использование интерфейса (многоязычность)	Поддержка http и dns	клиент	http/grpc	клиент/http	Клиент (многоязычный) http	Клиент (java)
смотреть поддержку	Полный/поддержка длительного опроса	служба поддержки	Поддержка длительного опроса	Не поддерживается (клиент регулярно загружает данные)	служба поддержки	Поддержка (пуш сервера)
Безопасность	acl/https	acl	поддержка https	-	https	acl
весенняя интеграция с облаком	служба поддержки	служба поддержки	служба поддержки	служба поддержки	служба поддержки	служба поддержки

По сравнению с известными Nacos у нас есть большие преимущества в финансовом уровне и распределении (уровень хранения), и мы все еще догоняем с точки зрения простоты использования и нативного облака.

Добро пожаловать к нам

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

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

Проект Trun-Key (стандартный план):GitHub.com/sopoststack/is…
Глубокий проект:GitHub.com/sopoststack/is…

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