Как правильно все перенести в микросервисы и сделать устойчивую архитектуру?

Question

[RSalo]

Всем привет. Пытаюсь понять, как правильнее сделать устойчивую к сбою архитектуру на микросервисах. Предположим, у нас есть какая-то цепочка независимых сервисов внутри системы, которые общаются между собой по API. Как правильнее сделать транзакцию на откат, если в цепочке запросов микросервисов, так называемой "саге" произошел сбой? Делать отдельный экшены на откат к предыдущему сервису? Но такая схема не будет работать, так как изначально сервисы, в которых операция прошла успешно не знают, что в каком-то следующем сервисе произошел сбой. Например, у нас есть два сервиса, первый - отправление на почту пароля пользователя, а второй - регистрации пользователя. Если у нас "ляжет" микросервис с регистрацией пользователя, то первый сервис в любом случае отправит пароль, но не будет знать, что "лежит" второй сервис без непосредственного запроса на него. Есть еще идея, если есть цепочка из микросервисов, то все запросы делать через MQ RPC. И таким образом можем делать разветвленную систему саг, в которых будет постоянный мониторинг запросов других сервисов, и если в одном из них произошел сбой, то делать откат, либо просто ничего не делать. Но тут тогда возникает вопрос, что делать с "ненадежными" микросервисами, которые располагаются на другой стороне и которые не хочется включать в общий пулл MQ или вообще сообщение между ними происходит по другим сценариям? Делать дополнительный anticorruption слой для таких случаев? Буду рад Вашим идеям.

Answer 1

[Иван Шумов]

Итак, куча всего смешана, давайте разбираться. У нас имеется:
- X различных сервисов с различными интерфейсами
- отсутствие транзакционности
- отсутствие гарантии доступности сервисов
- необходимость это все контролировать

Как в реальности это решается:
- Saga Pattern - отличная вещь, появилась именно как микросервисная транзакционность
- нам потребуется оркестрация. Я не очень в курсе что сейчас по on-prem решениям но из моего мира есть AWS StepFunctions. Ищем аналоги для своего энва
- если нет готовых решений то придется строить свою событийную архитектуру на очередях с брокерами и медиаторами
- для проблемы не доступности сервисов придется использовать exponential backoff или exponential retry. Опять, же, в моем мире это решает AWS SNS.

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

Comments

[RSalo]

До облаков пока что не дорос=)
Я планировал оркестрацию делать в самом RabbitMQ через federated exchanges. Если в exchange дереве падает одна из очередей, то посылать другим очередям сигнал о том, что нужно остановиться и сделать rollback. Только что делать с левыми сервисами, которые нужны, но они где-то крутятся на стороне и к ним есть доступ только через API?

[Иван Шумов]

RSalo, RabbitMQ это только брокер, в нем есть только queue и exchange, а отправлять сообщения в API будет consumer и тут-то и собака зарылась же) к тому же если застрянет сообщение то это может стать poison pill.

[RSalo]

Иван Шумов, я надеюсь, что если делать через RPC, то сообщения не должны застревать и будут сами тут же отваливаться, если произошел какой-то фейл или вышел таймаут. Мне нужно будет только reject обработать и всё=) И по поводу exponential backoff и exponential retry - такого не будет, т.к. мне нужно кровь из носа получать результат прямо здесь и сейчас и как можно быстрее давать ответ пользователю.
Спасибо за подсказки. Значит, я двигаюсь примерно в правильном направлении:D

[Иван Шумов]

RSalo, вот с этого и надо было начинать. Если

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

То, все вышеперечисленное выкидывается, а слово "устойчивая архитектура" просто не применимо. И очереди тут тоже не помогут по тому что очереди применяются только тогда когда ответ "сейчас" - не нужен

[RSalo]

Иван Шумов, я понимаю, что есть CAP теорема и всё такое, но как-то же нужно понимать остальным микросервисам в цепочке, что в одном из микросервисов произошел сбой? Вот и зацепился за MQ в попытке как-то решить этот вопрос. Возможно, этот вариант не совсем правильный и есть какие-то правильные решения... Просто не хочу делать еще один сервис над сервисами, который будет выполнять эту работу. Хотелось бы сделать каждый сервис более-менее самостоятельным.
Для краткости иногда пишу сервис, вместо микросервиса.

[Иван Шумов]

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

[RSalo]

Иван Шумов, мне в принципе в обычном дереве запросов микросервисов не особо нужна consistency, мне важно availability и tolerance. Риски по идее должны быть, если бы я делал замкнутую цепочку из систем, когда от результатов нижестоящей очереди зависит работа вышестоящей. А так, мне важно только знать, в каком availability сейчас находятся сервисы.

[Иван Шумов]

RSalo, и пришли мы вообще к другому вопросу в итоге.

Availability достигается за счет redundant components (в простонародье - горизонтальное масштабирование) и тут, как бы, без облаков уже становится тяжко. Хотя это зависит от того сколько девяток в доступности требуется. Я фана ради на AWS проектировал Serverless API на 99.99999% доступности, было забавно и не дорого)

Про tolerance тут есть несколько вариантов, но в целом мы делаем параллельные запросы к разным частям системы с очень короткими тайм-аутами. В вебе тут очень удобно работает GraphQL

[Иван Шумов]

RSalo, доступность сервисов измеряется во времени по результатам времени промежутков даунтаймов. Тут можно прогнозировать доступность, есть формулы расчёта, но надо:
- знать исходную доступность сервисов на которых это построено
- знать сколько доступности съедят ошибки (software failure)
- иметь recovery plan

[RSalo]

Иван Шумов, грубо говоря, я просто пытаюсь сделать обычное получение/сохранение данных внутри системы, где есть цепочка из микросервисов.
- доступность. могут быть или вообще недоступны, либо уходить в таймаут, если ответ не получен в течении нескольких секунд
- сколько доступа съедят ошибки. в корне дерева очередей ждать, пока выполнятся все дочерние очереди либо не будет фейла одной из важной очереди. если я помечаю в header'e очереди, что она должна быть "required" и она фейлится, то реджектить всё дерево очередей и сообщать об этом всему дереву. только надо посмотреть в мануале rabbitmq, могу ли я сделать reject, если уже выполнился consume
- мой план на реджект очереди. если база данных, то у меня в event sourcing'е есть специальная nosql таблица для транзакционных ивентов. я там сохраняю ивенты, которые потом копируются в основную таблицу с ивентами, если успешно выполнились записи в мускуль или какие-то другие операции. если произошла какая-то ошибка, то данные просто остаются в транзакционной таблице и никуда дальше не идут

[RSalo]

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