Проблема здесь является общей проблемой, если мы рассматриваем веб-службы, соединения RMI или любой другой протокол связи. Всегда рекомендуется использовать «примитивные» значения, а затем ссылки, потому что сортировка/разборка или сериализация/неэтериализация всегда являются головной болью. Также подумайте о разных типах сред, сообщающих друг друга. Совместное использование твердых значений - это безопасный способ решения проблемы.
Акка сам по себе является хорошим примером «микросервисов», сообщающих друг другу актеров. Когда я прочитал документацию Акки, одно доброе слово очень хорошо определяет актеров Акки. Актеры похожи на клиентов почтовых ящиков, и вы можете думать, что у каждого клиента есть почтовый ящик. Когда вы передаете переменную, это похоже на то, что вы получили новое электронное письмо.
Короткий результат длинной истории, избегайте совместного использования «зависимых» объектов, которые могут быть признаны недействительными до того, как они будут прочитаны от другого актера. Кроме того, если ваши системные имена actorRefs динамически, не вызывайте их по ссылке.
«Материализация» объясняется в документах akka-streams.
Процесс материализации может быть параметризован, например. создание экземпляра для обработки данных TCP-соединения с конкретной информацией о адресе и информации о соединении. Кроме того, материализация часто создает конкретные объекты, которые могут быть полезны для взаимодействия с процессором обработки после его запуска, например, для его закрытия или для извлечения показателей. Это означает, что функция материализации принимает набор параметров извне и создает набор результатов. Композиционность требует, чтобы эти два набора не могли взаимодействовать, поскольку это создавало бы скрытый канал, с помощью которого могли бы взаимодействовать разные части, что приводило к проблемам порядка инициализации и непостижимым ошибкам выполнения.
Поэтому используйте параметры вместо того, чтобы передавать «соединение».
Откладывание живого ресурса - не большая мысль.Это означает, что если вы используете одно соединение для всей системы, вы должны постоянно поддерживать его. Или, когда вы создаете транзакцию в актер-1 и отправляете ее на актер-2, вы не должны прекращать транзакцию в акте-1, пока актер-2 не завершит свою работу с транзакцией.
Тогда как вы можете понять? Затем вы используете «Будущее» и «Предложение()».
Надеюсь, я понимаю ваш вопрос и надеюсь, что смогу выразить себя.
Из того, что я понял, ваш график не должен ссылаться на «ресурс» напрямую, а скорее содержать функции для поиска ресурса во время материализации. актер ref должен быть в порядке, так как его в значительной степени. – dwegener