Когда какой-либо из микросервисов не работает, взаимодействие между сервисами становится очень важным, поскольку изоляция отказов, отказоустойчивости и отказоустойчивости являются одними из ключевых характеристик для любой архитектуры на основе микросервисов.
Полностью согласившись с ответом @jayant, в вашем случае Реализация правильного механизма отката имеет больше смысла, и вы можете реализовать требуемую логику, которую вы хотите написать, основываясь на сценарии использования и зависимостях между M1, M2 и M3.при необходимости вы также можете вызывать события в вашем резервном хранилище.
Поскольку вы используете новичок в микросервисе, вам необходимо знать ниже общие методы и шаблоны архитектуры для обеспечения устойчивости и отказоустойчивости в отношенииситуация, которую вы подняли в своем вопросе.И здесь вы используете Spring-Boot, вы можете легко добавить Netflix-OSS в ваши микросервисы.
Netflix выпустила Hystrix , библиотеку, предназначенную для управления точками доступа к удаленным системам, службам и сторонним библиотекам, обеспечивая большую устойчивость к задержкам и сбоям.
Itвключают в себя следующие важные характеристики:
Важность автоматического выключателя и резервного механизма:
Hystrix, который реализует схему автоматического выключателя что полезно, когда сбой службы может вызвать сбой каскадирования вплоть до самого пользователя.Когда вызовы определенной службы превышают circuitBreaker.requestVolumeThreshold (по умолчанию: 20 запросов) и процент отказов превышает circuitBreaker.errorThresholdPercentage (по умолчанию:> 50%) в скользящем окне, определяемом metrics.rollingStats.timeInMilliseconds (по умолчанию: 10 секунд),Разомкнутая цепь и звонок не сделан.
В случае ошибки и разрыва цепи разработчик может предоставить запасной вариант.Откаты могут быть прикованы цепью, так что первый откат делает другой деловой вызов.check Резервная реализация Hystrix
Повтор:
При сбое запроса вы можете захотеть получить запросповторить попытку автоматически. Лента выполняет эту работу за нас. В распределенной системе повторная попытка системы микросервисов может инициировать несколько других запросов или повторных попыток и запустить каскадный эффект
здесьнекоторые свойства для просмотра ленты
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 обрабатываются медленно, у нас возникает аналогичная проблема, если нагрузка достаточно высокая.Подробности реализации можно найти здесь
Итак, вот некоторые факторы, которые необходимо учитывать при обработке взаимодействия микросервиса, когда один из микросервисов не работает.