У меня есть веб-сервис Java, который я собираюсь выполнить с нуля в Scala. У меня есть актерский дизайн для нового кода, в котором участвует около 10-20 актеров. Один из сценариев использования имеет поток, как это:Использование шины сообщений в качестве замены обычного сообщения, проходящего между участниками (например, в scala)
Актер
Aполучает сообщениеa, создает десяткиbсообщений, которые будут обрабатываться АктеромB(возможно, несколько экземпляров, для балансировки нагрузки), производя многократныеcсообщения для актераCи так далее.
В приведенном выше сценарии, одно сообщение a может привести к несколько тысяч сообщений отправляются туда и обратно, но я не ожидал более чем горстка a сообщений в день (да, это не занят услуга на данный момент).
У меня есть следующие требования:
- сообщения не должны быть потеряны или повторяются. Я имею в виду, что если система перезапускается в середине обработки сообщений b, необработанные должны быть подняты после перезагрузки. С другой стороны, обработанные не должны быть приняты снова (эти сообщения в конце начнут некоторые большие вычисления, и повторение их будет дорогостоящим).
- Он должен быть легко расширяемым. Я имею в виду, что в будущем я могу добавить в систему некоторые другие компоненты, которые могут читать все сообщения (или их части) и, например, записывать журнал событий или подсчитывать, сколько сообщений было обработано, или сделать что-то новое с сообщениями b (рядом с тем, что уже происходит) и т. д. Обратите внимание, что эти «компоненты» могут быть независимыми приложениями, написанными на других языках.
Я новичок в сообщение шинных технологий, но и от того, что я читал, эти требования звучат для меня как то, что «автобусы сообщения» предложение, как RabbitMQ, Кафка, пустельги, но я также вижу, что AKKA также предлагает некоторые средства для настойчивости. Моя проблема заключается в том, что с учетом огромного диапазона возможностей я теряю технику использования. Я читал, что что-то вроде Кафки, вероятно, является излишним для моего заявления. Но я также не уверен, что настойчивость акки отвечает моим двум требованиям (особенно расширяемость).
Мой вопрос: должен ли я идти на корпоративный автобус сообщений? Что-то вроде Кафки? Или что-то вроде настойчивости акки? Или это будет быстрее и уместнее, если я что-то реализую сам (с поддержкой, скажем, AMQP, чтобы расширять возможности)?
Конечно, конкретные предложения по технологиям также приветствуются, если вы знаете что-то, что подходит для этой цели.
Akka сам по себе поддерживает доставку _at-most-once_ (что означает, что сообщения могут быть потеряны).Если вы добавите в Акка Настойчивость, вы можете достичь доставки _at-minimum-once_ (что означает, что вы можете получить дубликаты), используя атрибут 'AtLeastOnceDelivery'. Тем не менее, вы хотите, чтобы сделать то, что вам нужно. Это не поддерживается Аккой из коробки, и есть те, кто говорит, что это невозможно. См. Например https://dzone.com/articles/you-cannot-have-exactly-once. Однако вы можете приблизиться, но для этого вам нужно работать. –
Спасибо @MarioCamou за ваш комментарий. На самом деле, я видел этот пост. Итак, я должен принять ваше предложение как «построить его самостоятельно»? – Mahdi
Да, я бы лично начал с по крайней мере-раз доставки, а затем имел дело с повторениями и сообщениями не по порядку. Обратите внимание, что даже если вы используете Kafka или очередь сообщений, вы должны учитывать тот факт, что сама очередь сообщений может опуститься (и с помощью Akka Persistence вам также нужно подумать о том, что, если ваш провайдер настойчивости опустится). –