​

​Эта статья является третьей статьей в колонке Spring Cloud. Понимание содержания первых двух статей поможет вам лучше понять следующие статьи:

1. Spring Cloud, часть 1 | Обзор предисловия Spring Cloud и его общих компонентов

2. Spring Cloud Часть 2 | Использование и знание реестра Eureka

​

1. Обзор кластера высокой доступности Eureka Registry

В этой распределенной системе микросервисной архитектуры мы должны полностью учитывать высокую доступность каждого компонента микросервиса, и не может быть единой точки отказа.Поскольку центр регистрации Эврика сам по себе является сервисом, то если он имеет только один узел, то он может быть. Если произойдет сбой, мы не сможем зарегистрироваться и запросить службы, поэтому нам нужен реестр службы высокой доступности, который должен решаться кластером реестра. Реестр службы Eureka сам по себе тоже является службой.Его также можно рассматривать как поставщика и потребителя.Мы ранее настроили eureka.client.register-with-eureka=false чтобы реестр не регистрировался сам, но мы можем зарегистрироваться с помощью другие реестры.

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

​

2. Построение высокодоступного кластера реестра Eureka

Кластер высокой доступности реестра Eureka — это взаимная регистрация каждого реестра.

1. Мы копируем application.yml сервера Eureka (springcloud-eureka-server) как application-eureka8701.yml, application-eureka8702.yml и разрешаем службам Eureka 8701 и 8702 регистрироваться друг с другом.

Измените соответствующую конфигурацию application-eureka8701.yml следующим образом:

spring:
  application:
    name: springcloud-eureka-server
server:
  port: 8701
#设置该服务中心的hostname，指定ip,该实例名称不能重复
eureka:
  instance:
    hostname: eureka8701
  client:
    register-with-eureka: true
    fetch-registry: true
    service-url:
      defaultZone: http://eureka8702:8702/eureka

    修改application-eureka8701.yml相应的配置如下

spring:
  application:
    name: springcloud-eureka-server
server:
  port: 8702
#设置该服务中心的hostname，指定ip,该实例名称不能重复
eureka:
  instance:
    hostname: eureka8702
  client:
    register-with-eureka: true
    fetch-registry: true
    service-url:
      defaultZone: http://eureka8701:8701/eureka

2. Скопируйте класс запуска SpringcloudEurekaServerApplication с именем SpringcloudEureka8701ServerApplication, SpringcloudEureka8702ServerApplication, щелкните правой кнопкой мыши класс запуска и выберите, как показано на рисунке.

​

Затем добавьте -Dspring.profiles.active=eureka8701 в класс запуска SpringcloudEureka8701ServerApplication.

​

То же самое верно и для операции класса запуска 8702, которая здесь опущена.

3. Чтобы позволить eureka8701 и eureka8702 иметь возможность корректно обращаться друг к другу и синхронизировать данные, если они не могут получить доступ друг к другу, данные в сервисе Eureka не могут совместно использоваться синхронно, нам нужно поместить их в файл hosts в Каталог C:\Windows\System32\drivers\etc Добавьте две строки конфигурации следующим образом:

127.0.0.1 eureka8701
127.0.0.1 eureka8702

4. Запускаем две службы SpringcloudEureka8701ServerApplication и SpringcloudEureka8702ServerApplication и видим, что регистрация прошла успешно.

​

То же самое верно и для Eureka 8702. На данный момент сервисный кластер Eureka завершен.

Три, Эврика подробное объяснение

1. Модель потребителя услуг

1-1. Получение услуг

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

Его можно изменить с помощью параметра eureka.client.registry-fetch-interval-seconds=30. Значение по умолчанию для этой конфигурации — 30, единица измерения — секунды.

1-2. Сервис оффлайн

Во время работы системы неизбежно завершение работы или перезапуск экземпляра службы, во время выключения службы мы, естественно, не хотим, чтобы клиент продолжал вызывать закрытый экземпляр. Таким образом, в клиентской программе, когда экземпляр службы завершается в обычном режиме, он инициирует REST-запрос службы в автономном режиме к Eureka Server, сообщая сервисному центру: «Я отключаюсь». После получения запроса сервер устанавливает статус службы в DOWN и распространяет автономное событие.

2. Режим регистрации услуги

2-1 Отказ от отказа

Иногда наш экземпляр службы может не работать в обычном режиме, служба может не работать нормально из-за переполнения памяти или сбоя сети, а реестр службы не получил запрос «служба отключена». Чтобы удалить эти экземпляры, которые не могут предоставлять услуги, из таблицы служб, Eureka Server по умолчанию создаст временную задачу при запуске через регулярные промежутки времени (по умолчанию 60 секунд). eureka.server.eviction-interval-timer-in-ms=6000L ) отключает службы, которые не обновляются в текущем манифесте с тайм-аутом (по умолчанию 90 секунд eureka.instance.lease-expiration-duration-in-seconds= 90 )

2-2 Механизм самозащиты сервисного реестра Eureka

Когда мы отлаживаем программы на основе Eureka локально, мы в основном сталкиваемся с такой проблемой.В информационной панели главного сервисного центра появляется красное предупреждающее сообщение, подобное следующему.Во время разработки и тестирования нам нужно часто перезапускать экземпляр микросервиса, но Мы редко перезапускаем сервер eureka вместе (поскольку реестр eureka не будет изменен в процессе разработки) Этот механизм защиты сработает, когда количество сердечных ударов, полученных в течение одной минуты, сильно уменьшится. Вы можете увидеть Renews threshold и Renews(last min) в интерфейсе управления eureka.Когда последний (количество тактовых импульсов, полученных за последнюю минуту) меньше первого (порог тактового сигнала), срабатывает механизм защиты, и появляется красное предупреждение. появляться:

​

На самом деле предупреждение запускает механизм самозащиты Eureka Server.После того, как служба зарегистрирована на Eureka Server, она будет поддерживать пульсирующее соединение, чтобы сообщить Eureka Server, что она все еще жива. Во время работы Eureka Server будет подсчитывать, будет ли уровень отказов сердцебиения клиентских узлов ниже 85% в течение 15 минут.Если он ниже 85%, он активирует механизм самозащиты.При отладке одной машины Это легко удовлетворить, на самом деле, в производственной среде это обычно вызвано нестабильностью сети), Eureka Server защитит текущую регистрационную информацию экземпляра, чтобы эти экземпляры не истекли, и максимально защитит эту регистрационную информацию. Однако, если в течение этого периода защиты возникает проблема с экземпляром, клиент может легко получить фактический экземпляр службы, которого не существует, и вызов завершится ошибкой, поэтому клиент должен иметь отказоустойчивый механизм. Например, если вы можете использовать его, пожалуйста, используйте повторную попытку, автоматический выключатель и другие механизмы.

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

Eureka решает эту проблему через «режим самозащиты» — когда узел Eureka Server теряет слишком много клиентов за короткий промежуток времени (может произойти сбой сетевого раздела), то микросервисный узел будет защищен. Находясь в режиме самозащиты, сервер Eureka защитит информацию в реестре служб и не удалит данные в реестре служб (то есть не выйдет из каких-либо микрослужб). Когда сетевой сбой будет восстановлен, узел Eureka Server автоматически выйдет из режима самозащиты. Таким образом, режим самозащиты является мерой защиты от сетевых аномалий.Его архитектурная философия заключается в одновременном сохранении всех микросервисов (будут сохранены как работоспособные микросервисы, так и неработоспособные микросервисы), а не слепом выходе из любых работоспособных микросервисов. Использование режима самосохранения может сделать кластер Eureka более надежным и стабильным.Конечно, вы также можете использовать элемент конфигурации: eureka.server.enable-self-preservation=fase, чтобы отключить режим самосохранения.

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

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

Например, существует взаимосвязь вызова между двумя экземплярами клиента микрослужбы A и B. A является потребителем, а B — поставщиком, однако из-за сбоя в сети B не смог вовремя отправить в Eureka контрольный сигнал для возобновления контракта. В настоящее время Eureka не может просто удалить B из реестра, потому что в случае удаления A не может получить службу, зарегистрированную B, с сервера Eureka, но служба B в это время доступна; поэтому режим самозащиты Eureka лучше всего подходит для Открой это.

2-3. Соответствующая конфигурация для замыкания самозащиты выглядит следующим образом

• Конфигурация сервера

eureka:
  server:
    enable-self-preservation: false
    #eureka server清理无效节点的时间间隔，默认60000毫秒，即60秒
    eviction-interval-timer-in-ms: 60000 # 单位毫秒

• Конфигурация клиента

# 心跳检测检测与续约时间，测试时将值设置设置小些，保证服务关闭后注册中心能及时踢出服务
eureka:
  instance:
    # 每间隔1s，向服务端发送一次心跳，证明自己依然“存活”
    lease-renewal-interval-in-seconds: 1
    # 告诉服务端，如果我2s之内没有给你发心跳，就代表我“死”了，请将我踢掉
    lease-expiration-duration-in-seconds: 2

• Отключение режима самозащиты Eureka server показывает следующее:

​

Адрес источника обращения:git ee.com/coding-farm…

​

​