Сценарий сбоя микросервиса

Question

Я работаю над микросервисной архитектурой. Один из моих сервисов работает с исходной системой, которая используется для публикации данных. Этот микросервис опубликовал данные в Redis. Я использую Redis Pub / Sub. Который в дальнейшем потребляется парой микросервисов.

Теперь, если другой микросервис не работает и не может обработать данные из redis pub / sub, я должен повторить попытку с опубликованными данными при запуске микросервиса. Источник не может pu sh данные снова. Поскольку источник не может выдать sh, данные и ручное вмешательство невозможны, поэтому я должен использовать 3 подхода.

1. Дополнительно Использование данных Redis для хранения и извлечения.
2. Использование базы данных для хранение перед публикацией. У меня есть много исходных и целевых микросервисов, которые используют redis pub / sub. Теперь, если я использую этот подход каждый раз, мне нужно сначала вставить запрос в БД, чем его статус ответа. Теперь мне нужно использовать общую базу данных, сам этот подход добавляет пару дополнительных случаев обработки исключений и выглядит не очень эффективным для меня.
3. Используйте kafka inplace, если redis pub / sub. Поскольку traffi c низок, поэтому я использовал Redis pub / sub и не представляется возможным изменить.

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

Answer 1

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

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

Хотя это немного сложнее для выполнения sh, но вы можете использовать Kafka для потоковой передачи. Правильная настройка групп производителей и потребителей может помочь вам беспрепятственно выполнять работу.

Использование БД для хранения было бы излишним, учитывая ситуацию, когда вы «эти данные должны обрабатывать и сохранять»

НО, в качестве альтернативы, хранение данных в Redis и чтение их в задании cron / задание значительно упростит вашу работу. После успешного выполнения задания вы можете удалить данные из кэша и таким образом сохранить память Redis.

Если вы можете подробнее прокомментировать архитектуру и реализацию, я могу go опередить и соответствующим образом обновить свой ответ , :)

Answer 2

 For the point 2, 
 - Store the data in DB. 
 - Create a daemon process which will process the data from the table.
 - This Daemon process can be configured well as per our needs.
 - Daemon process will poll the DB and publish the data, if any. Also, it will delete the data once published.

Not in micro service architecture, But I have seen this approach working efficiently while communicating 3rd party services.