В настоящее время я много думаю о решении некоторых бизнес-задач, но я не могу найти подходящее решение, поэтому я прошу некоторый вклад / совет.
Позвольте мне описать нашу текущую настройку и то, что мы хотим заархивировать.
Текущая настройка:
- у нас есть несколько микроуслуг, где 2 из них обрабатывают наши основные бизнес-требования для создания контрактов, обновления контрактов и обновления всех объектов, которые принадлежат этим контрактам. Микросервис переполнен, и лично я больше не буду называть его микросервисом.
- некоторые другие службы, которые также обновляют эти контракты
В настоящее время в большинстве случаев все в порядке, поскольку эти службы не работают на в то же время, и мы «в безопасности», что они не пишут в одно и то же время (наше хранилище данных не поддерживает транзакции)
Будущие настройки / что мы хотим заархивировать:
Мы находимся в процессе разработки новой функции, в которой нам приходится полагаться на асинхронные операции c во всей системе. Мы будем иметь обновления для тех же объектов, когда эти асин c операции разрешатся и важен порядок сообщений. Мы подумали, что шина сообщений (rabbitmq) является хорошей идеей, потому что в настоящее время мы используем ее для простого варианта использования, и в последние несколько лет она работала безупречно, без простоев или чего-то подобного.
Для новой функции, которую мы имеем написать еще несколько хранилищ данных, которые не поддерживают транзакции, как наша текущая. Возврат обновлений к этим хранилищам данных затруднен (может быть, это не так хорошо для саг ...?)
Таким образом, контракты создаются, обновляются ... новая функция также может работать одновременно с контрактом или объектами, принадлежащими контракты - если мы не позаботимся сейчас, я предполагаю, что это будет очень сильно взорваться нам в лицо, и мы потеряем данные.
Я рассмотрел какой-то корпоративный шаблон, такой как cqrs / eventsourcing, sagas, чтобы назвать лишь несколько, но большинство из них на самом деле не имеют хорошего фреймворка / инструментария в экосистеме узлов, и создать что-то из земли в настоящее время невозможно - мы должны использовать то, что доступно сейчас и работает в производстве.
Идея Звучание саги очень многообещающе, но в большинстве случаев доступна только информация высокого уровня о том, как должны работать саги, но большинство видео / блогов / ... фокусировка на счастливом патенте не дает очень хорошего понимания того, как обрабатывать ошибки, как справляться с грязными читает, как обращаться с изоляцией ...
Я знаю его вероятности Трудно дать конкретный совет, не зная больше о наших системах ...
Но я был бы очень признателен, если бы кто-то поделился некоторыми соображениями по поводу:
-
- это саги (организованные) хорошая идея для нашего варианта использования, насколько вы можете судить по моему краткому обзору. если нет: есть ли у вас адив?
- Вы использовали их с узлом?
- если да, довольны ли вы этим?
- как ваши настройки (высокоуровневое представление)
хорошие инструменты в nodejs экосистема
- может быть, некоторые хорошие посты / видео в блоге, где основное внимание уделяется тому, как обрабатывать эти транзакции, ошибки ...
- по-прежнему сохраняют порядок сообщений без изменений, даже если нам приходится задерживать сообщения из-за таймаутов, ошибок ...
- обработать параллелизм
как вы решили