Привет всем, я Санью~~

Сегодня по просьбе друга я расскажу о реализации Nacos как нижнего уровня центра услуг регистрации.

Интересно, похожи ли вы на меня и у вас возникают следующие вопросы при использовании Nacos:

• Что такое временные и постоянные экземпляры? В чем разница?
• Как экземпляр Служить регистрируется на конце Служить?
• Как сохранить связь между экземпляром Служить и терминалом Служить?
• Как достигается Подписка на услугу?
• Как данные синхронизируются между кластерами? КП или АП?
• Как выглядят данные модели Nacos?
• ...

В этой статье исследуется базовая реализация ядра услуг регистрации Nacos путем изучения вышеупомянутых вопросов.

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

Напоминаем перед чтением: эта статья представляет собой еще одну очень длинную статью, очень подходящую для трех ссылок в один клик ~~

Временные и постоянные экземпляры

Временные и постоянные экземпляры В Накосеэтоочень-очень важноконцепция

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

Временный экземпляр

После регистрации Временного экземпляра в центре регистрации он сохраняется только в кеше в разделе Служить и не сохраняется на диске.

этот Служить Внутренний кеш в реестре обычно называетсяРегистрация услугиповерхность

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

Постоянный экземпляр

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

Когда экземпляр «Служить» работает ненормально или отключается от сети,Nacos только установит статус здоровья экземпляра Служить на неработоспособный.,не возьму это у Регистрация Удалить из таблицы услуг

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

Это самое основное различие между двумя

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

У вас может возникнуть вопрос здесь

Почему Nacos разделен на временные и постоянные экземпляры?

В основном из-за различных сценариев применения

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

Постоянный экземплярОн больше подходит для тех, кому нужна эксплуатация и техническое обслуживание.Служить,Это Служить практически постоянно.,Например, MySQL, Redis и т. д.

Экземпляры служб, такие как MySQL и Redis, можно зарегистрировать вручную через SDK.

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

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

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

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

spring
  cloud:
    nacos:
      discovery:
        Слово #ephemeral означает временный. Если для него установлено значение false, это означает Постоянный. экземпляр Понятно        ephemeral: false

Здесь есть еще одна маленькая деталь

В версии 1.x можно иметь оба Временных в одном Служить экземпляр также имеет постоянный экземпляра. Является ли экземпляр Служить постоянным или временным, определяется самим экземпляром Служить.

Но в версии 2.x все экземпляры службы являются либо временными, либо постоянными, что определяется службой, а не конкретным экземпляром службы.

Итак, в2.xМожно сказать, чтовременная службаипостоянное обслуживание

Почему в версии 2.x изменилось, будут ли временные или постоянные атрибуты определяться самим экземпляром, а не службой?

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

Поэтому на самом деле разумнее, чтобы сама служба решила, является ли атрибут временным или постоянным.

Регистрация услуги

В качестве регистрации услугицентр,Регистрация услуги, безусловно, очень важная особенность

Так называемая Регистрация услуги,Это использование клиентского SDK (или консоли), предоставленного центром регистрации, для передачи некоторой метаинформации самого Служить.,Например, в центр регистрации отправляются IP, порт и другая информация.

После получения сообщения «Служить» сторона «Служить» сохранит информацию о «Служить» в таблице «Услуги регистрации», упомянутой ранее.

1. Реализация версии 1.х.

Когда Nacos был в версии 1.x, услуги регистрации были реализованы через интерфейс HTTP.

Код выглядит следующим образом

Вся логика относительно проста, поскольку сам сервер Nacos написан на SpringBoot.

Но реализация в версии 2.x сложнее.

2. Реализация версии 2.х.

2.1. Изменения в протоколах связи.

По сравнению с версией 1.x основным обновлением версии 2.x является изменение протокола связи между клиентом и сервером с версии 1.x Http на версию 2.x gRPC.

gRPC — это высокопроизводительная универсальная среда RPC с открытым исходным кодом, разработанная Google. Базовая реализация версии Java также основана на Netty.

Причина, по которой он был изменен на gRPC, заключается главным образом в том, что HTTP-запросы часто создают и уничтожают соединения, что приводит к потере ресурсов.

Поэтому после версии 2.x в целях повышения производительности протокол связи был изменен на gRPC.

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

Хотя метод связи был изменен на gRPC, сервер версии 2.x по-прежнему сохраняет интерфейс регистрации HTTP, поэтому вы по-прежнему можете зарегистрироваться на сервере версии 2.x с помощью Nacos SDK 1.x.

2.2. Конкретная реализация

Когда клиент Nacos запускается, он устанавливает длительное соединение с сервером через gRPC.

Это соединение будет существовать всегда, и все будущие коммуникации между клиентом и сервером будут основаны на этом длинном соединении.

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

Служить Возьми Служить Пример,То же, что и 1.x,Он также будет сохранен в таблице «Регистрационные услуги».

Помимо регистрации,Когда регистрация является временным экземпляром,2.x также хранит информацию об экземпляре Служить в кеше клиента.,Для операции повтора

Так называемая операция Redo на самом деле представляет собой механизм компенсации. По сути, это запланированная задача, которая по умолчанию выполняется каждые 3 секунды.

Целью этой запланированной задачи является восстановление соединения между клиентом и сервером (соединение разорвано по каким-то аномальным причинам).

Тогда ранее зарегистрированный экземпляр Служить обязательно продолжит регистрироваться на конце Служить (экземпляр Служить будет удален из таблицы услуг регистрации при отключении соединения)

Поэтому очень важной функцией этой операции Redo является функция перерегистрации после переподключения.

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

Маленький Подвести итог

Версия 1.x реализована через протокол HTTP.

В версии 2.x, поскольку связь между клиентом и сервером была изменена на постоянное соединение gRPC, она была изменена на регистрацию через постоянное соединение gRPC.

В версии 2.x больше операций Redo, чем в версии 1.x, когда зарегистрированный экземпляр Служить является Временным. экземпляр Да, происходит сетевое исключение, и после восстановления соединения клиенту необходимо передать Регистрация услуги、Подписка на Переделаны операции типа услуги.

У вас может возникнуть вопрос здесь

Поскольку в версии 2.x имеется механизм повтора, обеспечивающий нормальную связь между клиентом и сервером перед повторной регистрацией, есть ли в версии 1.x аналогичный механизм повтора?

Конечно будут, читайте дальше.

механизм сердцебиения

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

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

После получения запроса служба Nacos Служить удалит этот экземпляр Служить из регистрации. Удалить из таблицы услуг

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

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

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

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

Реализация механизма сердцебиения также различается в версиях 1.x и 2.x.

1.x реализация пульса

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

существовать Регистрация услуги, признанные Временными Например, клиент запустит запланированное задание, которое будет выполняться каждые 5 секунд.

Эта запланированная задача создаст HTTP-запрос, перенесет информацию об этом экземпляре службы, а затем отправит ее на сервер.

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

• Когда время последнего пульса превышает 15 секунд,Но не более 30 лет.,отметит этот экземпляр Служить как нездоровый
• Когда последнее сердцебиение превысит 30 секунд, удалите Служить напрямую из регистрации. Удалить из таблицы услуг

Это версия механизма сердцебиения 1.x, которая по сути представляет собой две запланированные задачи.

Фактически, у Heartbeat 1.x есть и другая функция, то есть функция операции Redo в gRPC, упомянутая в предыдущем разделе, та же самая.

Служить, обрабатывая сердцебиение,Было обнаружено, что информация, переносимая Heartbeat для этого экземпляра Служить, отсутствовала в реестре.,На этом этапе он будет добавлен в таблицу «Услуги регистрации».

Таким образом, сердцебиение также имеет эффект, аналогичный Redo.

2.x реализация пульса

После версии 2.x, поскольку протокол связи был изменен на gRPC, клиент поддерживает длительное соединение с сервером, поэтому после версии 2.x он использует пульс самого длинного соединения gRPC, чтобы поддерживать его работоспособность.

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

Помимо контроля самого соединения, Nacos также имеет активный механизм обнаружения на стороне сервера.

Сервер Nacos также запустит запланированное задание, которое по умолчанию выполняется каждые 3 секунды.

Эта задача проверит соединения, которые не отправляли данные запроса более 20 секунд.

Как только будет обнаружено, что соединение не отправляло запрос более 20 секунд, запрос будет отправлен клиенту, соответствующему соединению.

Если запрос не выполнен или ответ не получен,В это время сторона Служить также подумает, что связь с клиентом ненормальная.,от而将этотклиентконецзарегистрироватьсяиз Служить Примерот Регистрация Удалить из таблицы услуг

Итак, для версии 2.x существует в основном два механизма поддержания активности:

• Само соединение механизма сердцебиения,Просто отключите его напрямую случаи Служить
• Механизм проверки накоинициативы,Терминал Служить проверит соединение, которое не отправляло данные в течение 20 секунд.,Соединение также будет разорвано при возникновении исключения.,Устранить случаи Служить

Маленький Подвести итог

Механизм пульса предназначен только для временного экземпляра.

1.xмеханизм сердцебиения выполняется посредством двух запланированных задач на стороне клиента и на стороне Служить.,Клиент регулярно сообщает информацию о пульсе,Терминал Служить регулярно проверяет время сердцебиения,Помечено как нездоровое через 15 секунд.,Если оно превышает 30 секунд, оно будет удалено напрямую.

1.xмеханизм сердцебиения также имеет функцию повтора, аналогичную 2.x.,Терминал Служить обнаруживает, что информация о сердцебиении Служить не существует.,Служить информация будет добавлена ​​в реестр,Это эквивалентно перерегистрации.

2.xоснован наgRPCдлинный Само соединение механизма Это происходит из-за механизма проверки времени сердцебиения и Служить, и любые отклонения будут немедленно устранены.

проверка здоровья

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

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

Например, экземпляр MySQL,Он определенно не будет сообщать о сердцебиении Nacos.,Так что это приводит к невозможности остаться в живых посредством механизма сердцебиения.

Так это на перманент экземплярситуация,Nacosчерез что-то под названиемпроверка здоровьямеханизм вынесения суждения Служить Примердажив или нет

проверка здоровьяимеханизм сердцебиения Как раз наоборот,механизм сердцебиенияда Служить Пример КСлужить Клиент отправляет запрос

И так называемая проверка здоровья Сразуда СлужитьконецинициативаКСлужить Примеротправлятьпросить,Чтобы определить, активен ли экземпляр Служить

Механизм реализации механизма проверки здоровья в 1.x и 2.x одинаков

В конце Nacos Служить будет создана задача проверки здоровья. Интервал выполнения каждой задачи будет составлять от 2000 до 7000 миллисекунд.

Когда задача запускается,В зависимости от установленной проверки здоровья будет выполняться другая логика.,На данный момент существует три основных способа:

• TCP
• HTTP
• MySQL

TCPиз方式Сразудав соответствии с Служить Примеризipиконецрот, чтобы судитьда Может ли соединение быть успешным?,Если подключение прошло успешно,считается здоровым,В противном случае задача нездорова.

HTTPиз方式Сразуда КСлужить Примеризipиконец口отправлять一个Httpпросить,Путь запроса должен быть установлен,Если вы можете запросить это обычно,Состояние экземпляра описания,Иначе это вредно для здоровья

MySQLиз方式да一种特殊из检查方式,Он может выполнить следующий Sql, чтобы определить, является ли библиотека данных основной библиотекой.

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

обнаружение службы

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

Nacos предоставляет два метода обнаружения:

• инициативазапрос
• Подписка на услугу

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

Подписка на услугуСразудаобратитесь кклиентконец КСлужитьконецотправлять一个订阅Служитьизпросить,Когда информация о подписанном экземпляре Служить изменится, инициатива отправит информацию об экземпляре Служить подписанному клиенту.,Суть в push-режиме

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

А когда Nacos интегрирует Spring Cloud, по умолчанию используется подписка.

Для этих двух методов обнаружения служб реализации версий 1.x и 2.x также различаются.

Запрос к сервису на самом деле очень прост в реализации.

1.x в целом предназначен для отправки Http-запросов к экземплярам службы. 2.x просто заменяет Http-запросы запросами gRPC.

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

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

В клиенте Nacos,лида1.xвозвращатьсяда2.xВседапроходитьSDKвNamingService#subscribeСпособ инициировать подписку

При изменении данных экземпляра Служить,клиентконец Сразу会回调EventListener,Вы можете получить последний пример данных Служить.

Хотя и 1.x, и 2.x используют один и тот же метод, конкретная логика реализации различна.

реализация подписки на сервис 1.x

В версии 1.x логика обработки подписки на услуги обычно состоит из следующих трех этапов:

На первом этапе при запуске клиента он создаст класс PushReceiver.

Этот класс создаст UDP-сокет со случайным портом.

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

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

Тогда все Служить Примерданные存到клиентконециз一个Во внутреннем кэше

И при запросе порт UDP-сокета будет передан серверу в качестве параметра.

После того, как сервер получит этот UDP-порт, он впоследствии отправит данные экземпляра службы клиенту через этот порт.

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

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

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

У вас может возникнуть вопрос здесь

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

На самом деле все очень просто. Это вызвано нестабильной связью по UDP.

Хотя существует Push, из-за неопределенности самого UDP-соединения клиент может не получить информацию об изменениях.

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

Это реализация подписки на услуги в версии 1.x.

Реализация подписки на сервис 2.x

Поговорив о реализации версии 1.х, поговорим о реализации версии 2.х.

Поскольку версия 2.x была заменена методом длинного соединения gRPC, при отправке изменения сервисных данных версии 2.x полностью отказался от метода UDP 1.x.

При изменении экземпляра службы сервер напрямую отправляет информацию о службе клиенту через это длинное соединение.

После того как клиент получит последние данные экземпляра службы, метод обработки тот же, что и в версии 1.x.

Помимо того же метода обработки, 2.x также наследует другие вещи от 1.x.

Например, у клиента по-прежнему будет кэш экземпляров службы.

Механизм запланированного сравнения также сохраняется, но по умолчанию этот механизм запланированного сравнения отключен.

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

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

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

Поэтому реализация функции подписки на сервис в версии 2.х примерно такая, как показано на рисунке ниже.

Здесь есть еще одна деталь, на которую следует обратить внимание.

В версии 1.x можно подписаться на любую услугу

Однако в версии 2.x поддерживаются только временные подписки на службы. Для постоянных служб подписка больше не поддерживается.

Маленький Подвести итог

Запрос службы 1.x запрашивается через HTTP 2.x запрашивается через gRPC;

Подписка на службу 1.x передается через UDP; 2.x реализована на основе длинного соединения gRPC.

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

согласованность данных

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

1. Механизм ответственности экземпляров сервиса

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

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

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

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

Конечно, реестр каждой службы Nacos по-прежнему содержит все данные экземпляра службы.

Я дал ему название этому механизму управления.,Это называется механизм ответственности,из-за менясуществовать1.xи2.xВсе提到Понятноresponsibleэтотслово

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

2. Теорема CAP и теория BASE

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

• Теорема CAP
• БАЗОВАЯ теория

В теореме CAP эти три буквы обозначают следующие значения:

• C,Аббревиатура для согласованности,представляет последовательность,Относится к строгой согласованности каждого узла в распределенной системе.,То есть оно должно быть одним и тем же в каждый момент,В противном случае вся система не сможет обеспечить Служить внешнему миру.
• A,Наличие аббревиатуры,Представляет доступность,Относится ко всей распределенной системе, остающейся доступной внешнему миру.,Даже несмотря на то, что данные, полученные от каждого узла, могут быть разными,Пока ты можешь это получить
• P, аббревиатура «Толерантность к разделам», означает отказоустойчивость раздела.

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

Почему все три не могут быть удовлетворены одновременно?

Для распределенной системы необходимо соблюдать разделение сети.

Так называемый раздел подразумевает развертывание сервисов системы в разных областях сети.

Например, одна и та же система может быть развернута одновременно в Пекине и Шанхае. Тогда они окажутся в разных разделах сети и не смогут получить доступ друг к другу.

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

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

На этом этапе остались только последовательность и доступность, почему они не могут быть удовлетворены одновременно?

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

Например, существует проблема с сетевым разделом. Сетевая область A и сетевая область B на рисунке выше не могут получить доступ друг к другу.

Предположим, что в этот момент запрос отправляется в сетевую область A на рисунке выше, а атрибуту value i в службе присвоено значение 1.

Если наличие гарантировано,В настоящее время, поскольку сети A и B не соединены,,На данный момент успешно изменен только Служить в А.,B не может быть успешно изменен,В настоящее время данные области dataAB несовместимы.,Нет гарантии согласованности данных

Если согласованность гарантирована,В настоящее время, поскольку сети A и B не соединены,,Следовательно, в настоящее время A не может быть успешно изменена.,Необходимо изменить, не удалось,В противном случае это приведет к АБданным несоответствиям.

Хотя A не был успешно изменен, гарантируется, что согласие данных,AB — это все те же данные, что и раньше.,Но в настоящее время вся система не имеет возможности записи.,Не удалось успешно записать данные.

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

Хотя последовательность и доступность не могут быть достигнуты одновременно, можете ли вы подойти к этому вопросу по-другому?

Прежде всего, мы можем обеспечить доступность системы, то есть сначала разрешить системе запись данных, и изменить i в сервисе региона А на 1.

Позже, когда сеть между областями AB будет восстановлена, значение i в области A будет скопировано в область B. Это обеспечит согласованность данных между областями AB.

Разве это не сделает всех счастливыми?

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

Теория BASE в основном включает в себя следующие три пункта:

• В принципе доступен): Даже если система выйдет из строя, она все равно сможет обеспечить Служить внешнему миру.,Он не станет сразу непригодным для использования.
• Мягкое состояние State): допускает противоречивые данные каждого узла.
• Окончательная последовательность (В конечном итоге Consistent）：Хотя каждому узлу разрешеноданныенепоследовательный,Но через определенное время,Данные каждого узла в конечном итоге должны быть согласованными.

Теория BASE на самом деле является продуктом компромисса.

3. AP и CP Накоса

На самом деле в настоящее время Nacos поддерживает как AP, так и CP.

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

Просто возьми Регистрация услуги Например, для Временный например,Nacos будет уделять приоритетное внимание доступности,это АП

для Постоянный экземпляр,Nacos будет уделять приоритетное внимание обеспечению согласованности данных,это КП

Далее давайте поговорим о принципах реализации CP и AP Nacos.

3.1. AP-реализация Nacos.

Для AP Nacos использует протокол Distro, разработанный Alibaba.

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

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

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

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

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

Даже если во время процесса синхронизации данных возникает исключение, экземпляр службы успешно регистрируется в службе Nacos. Извне доступен весь кластер Nacos, что обеспечивает эффект AP.

В то же время, чтобы удовлетворить теорию BASE, Nacos также имеет следующие два механизма, гарантирующие, что данные между конечными узлами в конечном итоге согласованы:

• Механизм повторной попытки при сбое
• Механизм сравнения времени

Механизм повторной попытки при сбоеда Точка в точкуданные Когда синхронизация с другими узлами не удалась,Буду повторять каждые 3 секунды,до успеха

Механизм сравнения времениСразудаобратитесь к,Каждый узел Nacos «Служить» будет периодически отправлять запросы на аутентификацию всем остальным узлам «Служить».

этотпроситьрасскажу всем СлужитьузелЭкземпляры служб, за которые вы несете ответственностьСоответствующий номер версии,Этот номер версии будет меняться по мере изменения экземпляра Служить.

Если номер версии данных других сервисных узлов не совпадает с вашим собственным, это означает, что данные других сервисных узлов не самые свежие.

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

3.2. Реализация CP Nacos.

Реализация CP Nacos основана на алгоритме Raft.

В ранней версии 1.x Nacos реализовала алгоритм Raft вручную.

В версии 2.x Nacos удалила ручную реализацию алгоритма Raft и вместо этого использовала структуру JRaft, основанную на Ant с открытым исходным кодом.

В алгоритме Raft каждый узел в основном имеет три состояния.

• Лидер отвечает за все запросы на чтение и запись. В кластере только один лидер.
• Follower,подчиненный узел,Основная ответственность за копирование данных Лидера.,Гарантия целостности данных
• Кандидат, узел-кандидат, в конечном итоге станет лидером или последователем.

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

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

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

например,有个клиентконец连到из上图вNacosСлужить2узел,после КNacosСлужить2зарегистрироваться Служить

NacosСлужить2полученныйпроситьпосле,Определит, является ли это узлом-лидером,Обнаружил, что я не

в это времяNacosСлужить2Сразу会КLeaderузелотправлятьпросить,После того, как узел Лидер получит запрос,,Справлюсь с этим Регистрация Процесс оказания услуг

Почему сказано, что Рафт гарантирует CP?

Главным образом потому, что у Рафта есть процесс суждения при написании

• первый,Когда лидер обрабатывает запрос на запись,Он не будет напрямую применяться к вашей собственной системе.,Вместо этого сначала отправьте запрос всем подписчикам.,Пусть они сначала обработают запрос
• Когда более половины Последователей успешно обработают запрос на запись, Лидер запишет данные и сообщит клиенту, что запрос успешно обработан.
• Если сигнал от более чем половины успешно обработанных подписчиков не поступает в течение определенного периода времени,,В это время Лидер считает, что написание данных на этот раз — провал.,Запросы на запись не будут обрабатываться,Непосредственно возвращается к ошибке запроса клиента

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

но Здесь есть еще одна маленькая детальнужно внимание

Когда Nacos обрабатывает запрос на запрос экземпляра службы, он не пересылает запрос узлу Leader для обработки, а напрямую проверяет реестр текущего экземпляра службы Nacos.

Это действительно вызовет проблему

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

Таким образом, хотя протокол Raft требует проверки последних данных с узла Leader, Nacos не соблюдает этот протокол, по крайней мере, при чтении данных экземпляра службы.

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

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

модель данных

В Nacos услуга определяется тремя частями информации:

• Пространство имен: используется для мультитенантной изоляции.,по умолчаниюдаpublic
• Группа: Это действительно можно использовать для изоляции от окружающей среды, Регистрация услуг можете указать группу Служить,Например, тестовая среда или среда разработки.,по умолчаниюдаDEFAULT_GROUP
• СлужитьName (ServiceName): Излишне говорить об этом больше.

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

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

Однако в Nacos на самом деле существует концепция кластера в сервисе.

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

В среде SpringCloud вы можете установить его с помощью следующей конфигурации

spring
  cloud:
    nacos:
      discovery:
        cluster-name: sanyoujavaCluster

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

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

В повседневной работе мы можем разделить сервисы, развернутые в одном и том же регионе, на один и тот же кластер. Например, Ханчжоу принадлежит одному кластеру, а Шанхай принадлежит одному кластеру.

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

Подвести итог

На этом этапе мы наконец закончили объяснять принцип реализации Nacos как ядра регистрационного центра.

Эта статья заняла более полумесяца от первоначального исходного кода и поиска информации до окончательного завершения, охватывая 2023 и 2024 годы, и были закодированы десятки тысяч слов.

Не знаю, получили ли вы что-нибудь после прочтения всей статьи.

Но одно можно сказать наверняка: те, кто это видит, должны быть настоящими фанатами.

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

Хорошо, на этом статья заканчивается. Если вы считаете, что эта статья полезна для вас, ставьте лайк, читайте, собирайте, пересылайте и делитесь ею с теми, кто в ней нуждается. Ваша поддержка — моя самая большая мотивация для обновления. Спасибо!

·············· END ·············