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

Метод развертывания nacos отличается от метода развертывания Springcloud eureka. Для euraka вам необходимо создать проект Springboot, затем загрузить сервер euraka через gav, а затем развернуть проект. nacos загружает пакет jar прямо с официального сайта Alibaba nacos и запускает сервис.

Eureka Server

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

Схема архитектуры Эврики

1. Регистрация службы (регистрация). Клиент Eureka зарегистрирует свою службу на сервере Eureka, отправив запрос REST. При регистрации предоставьте свои собственные метаданные, такие как IP-адрес, порт, показатели работоспособности, адрес домашней страницы и другую информацию. После того как сервер Eureka получит запрос на регистрацию, он сохранит информацию метаданных в двухслойной карте. Когда регистрироваться? При запуске микросервиса.

2. Продление (продление) услуги. После регистрации услуги Eureka Client будет постоянно уведомлять Eureka Server, указывая, что услуга всегда доступна и предотвращает ее удаление. По умолчанию eureka.instance.lease-renewal-interval-in-секунды каждые 30 секунд отправляет контрольный сигнал для продления услуги.

3. Получить список служб (получить реестр). Когда потребитель службы (клиент Eureka) запускается, он отправляет запрос REST на сервер Eureka, чтобы получить список служб центра регистрации и кэшировать его локально на клиенте. В то же время, из соображений производительности и безопасности, Eureka Server будет обновлять список сервисов в кеше каждые 30 секунд.

4. Вызов услуги: после получения списка услуг потребитель услуги может найти адрес услуги на основе информации об услуге в списке для доступа (дистанционный вызов).

6. Служба в автономном режиме (отмена). Когда клиент Eureka необходимо выключить или перезапустить, он больше не хочет получать запросы в течение этого периода времени. Поэтому необходимо заранее отправить запрос REST на сервер Eureka. сообщите Eureka Server, что он хочет перейти в автономный режим. После получения запроса Eureka Server установит статус службы в автономном режиме (DOWN) и распространит событие автономного режима.

7. Устранение сбоя (выселение). Экземпляр службы может оказаться не в состоянии предоставлять услуги из-за сетевых сбоев и других причин, и в это время экземпляр не отправляет запрос на сервер Eureka Server для отключения службы. Следовательно, также необходим механизм устранения услуг. Eureka Server создаст запланированное задание при запуске. Время от времени (по умолчанию 60 секунд) службы, срок действия которых истек и не были продлены (по умолчанию 90 секунд) eureka.instance.lease-expiration-duration-inсекунды, удаляются. текущий список услуг.

Схема архитектуры Nacos:

Управление сервисами: реализация CRUD сервиса, CRUD доменного имени, проверка состояния сервиса, управление весом сервиса и другие функции.

Протокол согласованности: решает разные данные, разные требования согласованности и разные механизмы согласованности.

OpenAPI: предоставляет стандартный HTTP-интерфейс в стиле Rest, простой в использовании и удобный для многоязычной интеграции.

Консоль: простая в использовании консоль для управления услугами, конфигурацией и другими операциями.

Экземпляры службы Nacos делятся на два типа:

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

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

Настройте экземпляр службы как постоянный экземпляр:

spring:

cloud:

nacos:

discovery:

ephemeral: false # Установить невременный экземпляр

Общие структуры Nacos и Eureka схожи, включая регистрацию служб, получение услуг и ожидание контрольного сигнала, но есть и некоторые различия:

Что общего у Nacos и Eureka

Как регистрация службы поддержки, так и получение услуги.

Метод пульса всех поставщиков услуг поддержки для проверки работоспособности.

Разница между Накосом и Эврикой

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

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

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

Кластер Nacos по умолчанию использует режим AP. Если в кластере есть невременные экземпляры, Eureka использует режим AP.

1. Объем разный.

Порог Nacos предназначен для конкретной службы, а не для всех служб, но порог самозащиты Eureka предназначен для всех служб. nacos поддерживает как CP, так и AP; эврика поддерживает только AP; nacos использует netty, которое представляет собой длинное соединение; eureka использует короткое соединение, которое отправляется регулярно;

2. Различные методы защиты.

Метод защиты Eureka: при подсчете доли неудачных продлений за короткий период времени, если она достигает определенного порога, срабатывает механизм самозащиты. В соответствии с этим механизмом Eureka Server не будет удалять какие-либо микросервисы и ждать нормального состояния. . Выйдите из механизма самозащиты. Переключатель самосохранения (eureka.server.enable-self-preservation: false).

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

3. Различные способы подключения.

nacos поддерживает динамическое обновление, просто добавьте аннотацию @RefreshScope на контроллере (контроллере) и использует соединение Netty, которое является длинным соединением, eureka сама по себе не поддерживает динамическое обновление и должна взаимодействовать с MQ для завершения динамического обновления, и это это короткое соединение, которое отправляется регулярно.

Переключение режима CAP в Nacos

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

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

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

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