Как работать с микросервисом Взаимодействие, когда один из микросервисов не работает

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

Например если у нас есть 3 микросервиса M1,M2,M3 . М1 взаимодействует с М2, а М2 взаимодействует с М3. Если микросервисный кластер M2 не работает, как мы должны справиться с этой ситуацией?

Источник

2 ответа

Решение

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

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

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

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

Ниже приведены важные характеристики:

  • Важность автоматического выключателя и резервного механизма:

    Hystrix, которая реализует схему автоматического выключателя, которая полезна, когда сбой службы может вызвать каскадный сбой вплоть до самого пользователя. Когда звонки на определенную услугу превышают circuitBreaker.requestVolumeThreshold (по умолчанию: 20 запросов) и процент отказов больше, чем circuitBreaker.errorThresholdPercentage (по умолчанию: >50%) в скользящем окне, определяемом как metrics.rollingStats.timeInMilliseconds (по умолчанию: 10 секунд), цепь открывается, и вызов не выполняется.

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

  • Retry:

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

    Вот некоторые свойства, чтобы посмотреть ленты

    sample-client.ribbon.MaxAutoRetries=1

    Максимальное количество следующих серверов для повторной попытки (исключая первый сервер)

    sample-client.ribbon.MaxAutoRetriesNextServer=1

    Можно ли повторить все операции для этого клиента

    sample-client.ribbon.OkToRetryOnAllOperations=true

    Интервал обновления списка серверов из источника

    sample-client.ribbon.ServerListRefreshInterval=2000

    Подробнее:- свойства ленты

  • Образец переборки:

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

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

    Предположим, у вас есть многопоточное приложение на основе запросов (например, типичное веб-приложение), которое использует три разных компонента, M1, M2 и M3. Если запросы к компоненту M3 начинают зависать, в конечном итоге все потоки обработки запросов будут зависать в ожидании ответа от M3.

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

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

Источник

Как уже упоминалось в комментарии, есть много способов сделать это,

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

Случай 2: услуги зависят от M2, зависит от M1, а M3 зависит от M2.

вариант а) M1 может ждать, пока служба M2 не восстановится, делая периодические эхо-запросы или извлекая информацию из реестра или сервера имен, если M2 работает или нет

вариант b) использовать hystrix в качестве реализации автоматического выключателя и корректно обрабатывать аварийный режим в M3 или в вашем оркестраторе (парень, который вызывает эти службы, т. е. M1, M2, M3 по порядку)

Источник
Другие вопросы по тегам