Очереди работы Akka.Net

У меня есть существующая среда распределенных вычислений, построенная на основе MassTransit и RabbitMQ. По сути, есть менеджер, который отвечает работой на основе запросов. Каждый рабочий возьмет определенное количество предметов в зависимости от характеристик физической машины. Затем рабочий отправляет сообщения о завершении, когда все готово. Он работает довольно хорошо и кажется хорошо масштабируемым, поскольку единственным связующим звеном является служебная шина.

Недавно я оценил Akka.Net, чтобы посмотреть, будет ли это более простой системой для реализации того же шаблона. Посмотрев на него, я был несколько озадачен тем, для чего именно он используется. Кажется, что если бы я хотел сделать что-то подобное, менеджер должен был бы знать о каждом воркере заранее и напрямую отправлять ему работу.

Я считаю, что что-то упускаю, потому что эта модель, похоже, плохо масштабируется.


distributed-computing masstransit akka.net
person Telavian    schedule 30.06.2015    source источник

Ответы (2)


arrow_upward
17
arrow_downward

Служебные автобусы, такие как MassTransit, созданы как надежные службы обмена сообщениями. Обеспечение доставки сообщений является первоочередной задачей.

Фреймворки акторов также используют сообщения, но это единственное сходство. Обмен сообщениями является лишь средством достижения цели и не так надежен, как в случае сервисных шин. Они больше ориентированы на создание высокопроизводительных, легко распределяемых системных топологий, сосредоточенных на субъектах как основной единице работы. Концептуально актор близок к паттерну Active Record (однако это сильное упрощение). Они также очень легкие. Вы можете иметь миллионы из них, живущих в памяти исполняющей машины.

Что касается производительности, Akka.NET может отправлять более 30 млн сообщений в секунду на одной ВМ (проверено на 8 ядрах) — намного больше, чем любая служебная шина, но характеристики также существенно различаются.

На JVM теперь кластеры akka могут подниматься до 2400 машин. К сожалению, мы не смогли проверить, каковы ограничения реализации .NET.

Вы должны решить, что вам действительно нужно: библиотека обмена сообщениями, фреймворк акторов или их комбинация.

person Bartosz Sypytkowski    schedule 01.07.2015

arrow_upward
6
arrow_downward

Я согласен с ответом @Horusiath. Кроме того, я бы сказал, что в большинстве случаев вы можете заменить сервисную шину для системы обмена сообщениями акторной модели, такой как akka, но они не относятся к одному классу.

Обмен сообщениями — это лишь одна из возможностей Akka, и хотя это отличная функция, я бы не сказал, что она основная. Анализируя ее как альтернативу, вы должны сначала рассмотреть преимущества самой модели, а затем посмотреть, достаточно ли хороши возможности обмена сообщениями для вашего варианта использования. Вы по-прежнему можете использовать выделенную внешнюю служебную шину для распределения сообщений по разным кластерам и, например, поддерживать обмен сообщениями с akka.net внутри кластеров.

Но дело в том, что если вы решите использовать Akka.net, вы не будете использовать его только для обмена сообщениями.

person Natan    schedule 01.07.2015