akka http: потоки Akka против актеров для создания сервиса отдыха

Когда дело доходит до создания веб-службы REST с 60+ API на akka http. Как я могу выбрать, что мне следует использовать: потоки акка или актеры акка? В своем сообщении Джос показывает два способа создания API на akka http, но не показывает, когда я должен выбрать один из них.


scala akka akka-stream akka-http
person Mutaz    schedule 05.11.2015    source источник

Ответы (2)


arrow_upward
23
arrow_downward

Это сложный вопрос. Очевидно, работают оба подхода. Так что в определенной степени это вопрос вкуса / знакомства. Так что все, что будет дальше, - это мое личное мнение.

По возможности я предпочитаю использовать akka-stream из-за его более высокого уровня и безопасности типов. Но насколько это жизнеспособный подход, во многом зависит от задачи REST API.

Акка-поток

Если ваш REST API - это служба, например отвечает на вопросы на основе внешних данных (например, API курса обмена валют), предпочтительно реализовать его с помощью akka-stream.

Другой пример, где предпочтительнее akka-stream, - это какой-то интерфейс базы данных, где задача REST API - анализировать параметры запроса, переводить их в запрос БД, выполнять запрос и переводить результат в соответствии с запрошенным типом содержимого. пользователем. В обоих случаях поток данных легко отображается на примитивы akka-stream.

Актеры

Примером, когда использование акторов было бы предпочтительнее, может быть то, что ваш API позволяет запрашивать и обновлять ряд постоянных акторов в кластере. В этом случае может быть предпочтительнее либо решение на основе чистого актора, либо смешанное решение (анализ параметров запроса и перевод результатов с использованием akka-stream, все остальное с использованием акторов).

Другой пример, когда решение на основе акторов может быть предпочтительнее, - это если у вас есть REST API для длительных запросов (например, веб-сокетов) и вы хотите развернуть конвейер обработки самого REST API в кластере. Я не думаю, что что-то подобное сейчас возможно вообще с использованием akka-stream.

Резюме

Итак, чтобы подвести итог: посмотрите на поток данных каждого API и посмотрите, четко ли он отображается на примитивы, предлагаемые akka-stream. Если это так, реализуйте это с помощью akka-stream. В противном случае реализуйте с помощью акторов или смешанного решения.

person Rüdiger Klaehn    schedule 05.11.2015
comment
Спасибо Рюдигеру за четкий ответ. Что мне не нравится в смешивании того и другого, так это то, что для оказания противодействия вам нужно полагаться на модель издатель / подписчик по отношению к вашим актерам. Это заставляет вас сильно полагаться на ask шаблон, а не на tell, если вы хотите отправить свой запрос вниз по иерархии акторов. Шаблон «актер на запрос» полезен, учитывая незначительную стоимость нового актера. Я также вижу, что поток очень хорошо работает в качестве агрегатора для базовых вспомогательных сервисов, чтобы легко группировать вспомогательные API. Это особенно важно при разработке для мобильных устройств, где # запросов должно быть минимальным. Что вы думаете? - person Mutaz; 05.11.2015
comment
Честно говоря, я стараюсь использовать akka-stream как можно чаще и использую необработанные акторы только тогда, когда у меня есть особое развертывание или другие потребности. Я думаю, что большое количество вариантов использования хорошо соответствует akka-stream. - person Rüdiger Klaehn; 05.11.2015
comment
Отлично! Кстати, не могли бы вы предоставить простой вариант использования субъектов предложения, было бы предпочтительнее, если бы ваш API позволял запрашивать и обновлять ряд постоянных субъектов в кластере. - person WeiChing 林煒清; 09.07.2018

arrow_upward
11
arrow_downward

Не забывайте о будущем!

Одно дополнение, которое я хотел бы сделать к прекрасному ответу Рудигера Клаена, - это также рассмотреть вариант использования _ 1_. Компонентность Futures и управление ресурсами ExecutionContext делают Futures идеальным для многих, если не для большинства, ситуаций.

Есть отличная запись в блоге, в которой описывается, когда будущее лучше, чем актеры. Кроме того, обратное давление, обеспечиваемое Streams, сопровождается довольно значительными накладными расходами < / а>.

Тот факт, что вы попали в кроличью нору, используя akka-http, не означает, что весь параллелизм в вашем обработчике запросов должен быть ограничен Акторами или Потоками.

Маршрут

Route по своей сути размещает фьючерсы на определение типа:

type Route = (RequestContext) ⇒ Future[RouteResult]

Поэтому вы можете встроить будущее прямо в свой маршрут, используя только функции и фьючерсы, без директив:

val requestHandler : RequestContext => HttpResponse = ???

val route : Route = 
  (requestContext) => Future(requestHandler(requestContext)) map RouteResult.Complete

onComplete Directive

_ 6_ Директива позволяет вам« развернуть »будущее в вашем маршруте:

val route = 
  get {

    val future : Future[HttpResponse] = ???

    onComplete(future) {
      case Success(httpResponse) => complete(httpResponse)
      case Failure(exception)    => complete(InternalServerError -> exception.toString)
    }
  }
person Ramón J Romero y Vigil    schedule 05.11.2015