Похоже, что именно здесь маршрутизаторы вступают в игру в соответствии с документами (https://getakka.net/articles/clustering/cluster-routing.html) и различными учебными пособиями и примерами кода, которые я прочитал. Однако, кажется, что здесь пропущено, как заставить NodeB
вызывать актерарасположен в NodeA
. В микросервисной системе «сервис / субъект», выполняющий эту работу, вероятно, будет полностью расположен на другом узле.
Так что, мне кажется, мне нужно было бы разместить маршрутизатор на каждом узле вЯ заинтересован в использовании broadcast-pool
, но с маршрутизаторами на основе пула они развертывают на своих маршрутах:
Маршрутизаторы кластерного пула отличаются от групповых маршрутизаторов тем, что они развертывают свои маршрутыудаленно на их целевые узлы, в отличие от маршрутизации сообщений на заранее заданные пути актеров, которые могут существовать или не существовать на удаленных машинах.
Таким образом, может показаться, что дублирующие маршрутизаторы на основе пула также дублируют развертывания черезузлы.
Таким образом, это означает, что вы хотите, чтобы только один маршрутизатор на основе пула избежал этого развертыванияНет дублирования?Я предполагаю, что max-nr-of-instances-per-node
ограничит это?
В моем случае я хочу использовать роли для назначения того, что доступно, где:
akka {
actor{
provider = cluster
deployment {
/deviceA {
router = broadcast-pool
cluster {
enabled = on
allow-local-routees = off
use-role = deviceA
}
}
}
}
}
Помимо этого, если мой актер работает на NodeB
и хочет вызвать другого участника, расположенного на другом узле (микросервисы), если маршрутизатор не определен на NodeB
, могу ли я использовать ActorSelection
, чтобы получить дескриптор на маршрутизаторе?Я предполагаю, что мне понадобится полный путь к тому месту, где определен маршрутизатор, чтобы сделать это: akka.tcp://...
Я предполагаю, что другой моей альтернативой будет настройка NodeB
, чтобы знать, где находятся определенные узлы
Context.ActorSelection("akka.tcp://MySystem@locationOfRouter:8000/user/deviceA").Tell(new MyMessage("UsefulInformation"));
Я полагаю, что NodeB
уже нужно знать, где подключиться к начальным узлам, поэтому в этом случае у меня будет полный путь, и я смогу просто определить маршрутизатор на начальных значениях, а затем использовать актервыбор, чтобы получить управление на этих маршрутизаторах, что потребовало бы жесткого кодирования этих путей.Я предполагаю, что такой подход менее желателен.
Я мог бы также делать вещи совершенно неправильно, и, возможно, этот подход был бы лучше: Distributed Publish Subscribe in Cluster
https://getakka.net/articles/clustering/distributed-publish-subscribe.html
Так какв нем конкретно говорится, что:
Как отправить сообщение актеру, не зная, на каком узле он работает?
Это похоже на крик в пустотуи надеясь на лучшее, особенно если кому-то нужен ответ, например, вызов актера, который извлечет некоторые дополнительные данные для возврата отправителю.