Строительство модульных систем Akka

Мы строим многокомпонентную систему на основе Akka-кластеров. Каждый компонент является отдельным Play! проект, и в начале он присоединяется к кластеру Akka, а компоненты начинают искать действующих участников.

Проблема

У меня есть две проблемы с этой настройкой:

  • Написание тестового кода очень сложно (мы еще этого не выяснили), особенно при написании тестов, которые полагаются на нескольких участников, поступающих из разных компонентов. Как мы можем решить зависимость и создать надлежащий кластер в тестовом коде (между двумя игровыми приложениями!)

  • Во время разработки каждый разработчик должен запускать несколько экземпляров Sbt для загрузки системы (разные проекты воспроизведения), и это полностью поглощает всю память системы, и разработка становится невероятно медленной.

Что я ищу

Я думал о том, чтобы использовать свойство "role" кластера для выборочной загрузки, это означает, что существует только один проект и компоненты Play (модули) и загрузка загрузочного проекта. Я сканирую текущий "Роли" этого экземпляра и на основе этого я запускаю или останавливаю определенные компоненты/актеры.

Это упростит тестирование, но я точно не знаю, как это сделать в Play, особенно, что некоторые компоненты фактически предлагают API RESTful (Play Controllers), и я не знаю, как включать/отключать маршруты и контроллеры при загрузке время игры.

Есть ли какой-либо документ или что-то, что показывает правильный способ создания модульной распределенной системы или каких-либо подсказок? (что-то также относится к тому, как следует настраивать SBT?

Редактировать 1: Проект живет в одном репозитории и имеет одну сборку sbt (несколько проектов)

Ответы

Ответ 1

Это хороший вопрос, и я отвечаю на него по частям, хотя я не специалист по игре.

1 - Написание тестов

Я бы рекомендовал тестировать модули отдельно, чтобы избежать экспоненциального взрыва необходимых тестовых случаев. Для этого актеры - очень хорошая абстракция, потому что вы можете тривиально высмеять любого актера, введя TestProbe вместо реального ActorRef. В кластере вам обычно нужно искать службы на других узлах, а это означает, что в тесте вы создаете свой зонд и вводите его путь (probe.ref.path) вместо пути, который вы искали бы в производственной системе.

Второй аспект касается интеграционных тестов, для которых вы хотите участвовать в нескольких сервисах. В этом случае вам не нужно запускать "правильный" кластер с несколькими JVM, вы можете просто развернуть несколько ActorSystems в своем тесте и связать их с "localhost".

2 - Развертывание разработки

Нет необходимости запускать несколько экземпляров sbt, вы можете просто создать подходящий Основной класс, который запустит все необходимые ActorSystems в рамках одного и того же процесса, как и для тестов, упомянутых выше.

3 - Node Управление ролями

Актерсистема, управляемая Play, обычно имеет роль "frontend". В дополнение к этому вы можете запускать больше систем с разными ролями, которые сами по себе не являются приложениями Play. Запуск различных действий - запуск различных сервисов и инициирование различных действий - имеет смысл на основе роли node, мы делаем это сами в тестах и ​​реальных приложениях.

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