Как вы разрабатываете свое программное обеспечение, которое обновляет несколько микросервисов, если один из них выходит из строя?

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

Что делать, если у меня есть три микросервиса, и два из них хороши, а один умирает прямо посреди POST? Двое получат ПОЧТУ, а один - нет. Я не думаю, что могу совершать транзакции, потому что я отправляю свои запросы в службу.

Как мне дизайн для этого? Я не хочу потерянные данные в различных базах данных.

— Джонни
источник

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

— Майк

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

— Тим Седерквист

Разве не использовалось бы что-то вроде «администратора очередей», что, как я полагаю, вызвало бы Redis узкое место? Или хотя бы иметь высокий потенциал тоже? Я не знаю иного пути, как ты описал.

— Джонни

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

— htm11h

Это для чего-то вроде rabbitmq?

— джонни

Ответы:

Некоторые варианты.

Используйте постоянный канал связи

Вместо HTTP поместите сообщения в очередь, которая является высокодоступной и постоянной. Например, Кафка. Пока целевой сервер становится доступным в какой-то момент, он получит сообщение.

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

Откат и повторите

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

Обнаружить и компенсировать

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

Рассмотреть варианты дизайна

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

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

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

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

— Кейси Спикман
источник

Для этого ли RabbitMQ?

— джонни

Является ли RabbitMQ ответом на ваш вопрос? Нет. Это может быть частью решения, которое отвечает вашим потребностям, но оно не решит вашу проблему в одиночку.

— Кейси

Просто записка. Я думаю, что RabbitMQ не сохраняет сообщения. Он потребляется и удаляется из очереди, поэтому НЕТ. Если вам нужно упорство и повторите попытку, RabbitMQ не поможет.

— Laiv

Я думаю, что вы описываете проблему консенсуса: вы не хотите фиксировать, пока каждый участник распределенной транзакции не скажет, что операция прошла успешно. Простым решением этого является двухфазный коммит. По сути, он выполняет этап транзакции в каждой системе, пока каждый не сообщит, что подготовка прошла успешно (этап 1). Если каждый участник транзакции возвращает успех, каждому из них предлагается совершить транзакцию; если какой-либо из них возвратил ошибку, выдается откат (этап 2). Это может привести к появлению более сложного решения Three Phase Commit. Вы можете прочитать намного лучшее описание каждого здесь:

http://the-paper-trail.org/blog/consensus-protocols-two-phase-commit/

http://the-paper-trail.org/blog/consensus-protocols-three-phase-commit/

— iarejenius
источник