Дизайн на основе событий — Futures, Promises vs Akka Persistence

У меня есть несколько вариантов использования, которые требуют запуска предопределенных событий на основе определенных действий пользователя.

например скажем, когда NewUser создается в приложении, ему придется вызывать CreateUserInWorkflowSystem и FireEmailToTheUser асинхронно. Есть много других бизнес-кейсов такого рода, когда события будут предопределены на основе варианта использования. Я могу использовать Promises/Future для моделирования этих событий, как показано ниже.

if 'NewUser' then 
    call `CreateUserInWorkflowSystem` (which will be Future based API)
    call `FireEmailToTheUser` (which will be Future based API)
if 'FileImport' then
   call `API3` (which will be Future based call)
   call `API4` (which will be Future based call)

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

Это использовало простые Futures/Promises API. Однако я думаю, что здесь подойдет Akka Persistence и блокирующие вызовы могут по-прежнему наталкиваться на Futures. С персистентностью Akka будет легко обрабатывать сбои, поскольку она предоставляет их из коробки и т. д. Я понимаю, что персистентность Akka все еще находится на экспериментальной стадии, но это не кажется большой проблемой, поскольку typesafe обычно держит эти новые фреймворки в экспериментальном состоянии перед продвижением в будущем выпуске и т. д. (то же самое было и с макросами). Учитывая эти требования, как вы думаете, Futures/Promises или постоянство Akka здесь лучше подходят?


scala akka akka-persistence
person Vikas Pandya    schedule 24.06.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Это вопрос, основанный на мнении — не лучший тип для SO. Во всяком случае, пытаюсь ответить.

На самом деле это зависит от того, что вам удобнее и каковы ваши требования. Если вам нужно масштабировать систему позже одной JVM — используйте Akka. Хотите сделать его более простым — используйте фьючерсы.

Если вы используете фьючерсы, вы можете хранить все состояния и действия для выполнения в очереди заданий/БД. Это вполне разумно.

Если вы используете Akka Persistence, то, очевидно, это поможет вам с настойчивостью. Akka упростит контроль, восстановление и повторные попытки. Если ваше действие CreateUserInWorkflowSystem терпит неудачу, результат распространяется на наблюдающего субъекта, который, вероятно, перезапускает неудавшийся субъект и заставляет его повторять попытку N раз. Если ваш супервайзер терпит неудачу, его супервайзер поступит правильно, иначе в конечном итоге все приложение выйдет из строя, и это хорошо. С Futures вам придется реализовать этот механизм самостоятельно и убедиться, что приложение может аварийно завершать работу, когда это необходимо.

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

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

person yǝsʞǝla    schedule 24.06.2014