Это анти-паттерн в Akka HTTP для передачи контекста запроса для завершения? - PullRequest
Новая
       14

Это анти-паттерн в Akka HTTP для передачи контекста запроса для завершения?

0 голосов
/ 08 мая 2019

Представьте, что у меня есть класс JobsEndpoint, который содержит класс JobSupervisor, который имеет двух дочерних актеров, RepositoryActor и StreamsSupervisorActor. Поведение для различных запросов к этому верхнему уровню JobSupervisor необходимо будет выполнить в соответствующем дочернем акторе. Например, запрос на сохранение задания будет обрабатываться исключительно в RepositoryActor и т. Д. *

Итак, мой вопрос: не является ли это паттерном для передачи контекста запроса через этих акторов через сообщения, а затем для завершения запроса, как только это имеет смысл?

Так что вместо этого: 

Request -> Endpoint ~ask~> JobSupervisor ~ask~> RepositoryActor
           Response <- Endpoint <- JobSupervisor <-|return result

Я мог бы передать RequestContext в моих сообщениях, таких как StoreJob(..., ctx: RequestContext), и затем завершить его в RepositoryActor.

1 Ответ

0 голосов
/ 09 мая 2019

Я, правда, давно не пользуюсь Akka, но вижу несколько возможностей для улучшения.

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

Я бы хотел, чтобы конечная точка отправляла сообщение со своим ActorRef в качестве поля для ответа.Таким образом, вам не нужно блокировать актеров Endpoint и JobSupervisor.Всякий раз, когда актер репозитория завершает операцию, он может отправить ответ напрямую в конечную точку без необходимости проходить через посредников.

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

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

1) Трудно ли его создать?Это влияет на тестируемость.Если RequestContext сложно создать, я бы выбрал для извлечения только необходимые элементы, чтобы можно было писать модульные тесты.

2) Можно ли его сериализовать?Если вы развернете свою актерскую систему в кластерной среде, вам нужно будет сериализовать сообщения.Сообщения, которые являются простыми держателями данных, работают лучше всего.

...