Play を akka-cluster バックエンドや Cassandra のような NoSql ストアと組み合わせた例はあまり見たことがありません。そのため、このようなシステムの実装には不確実性があります。
設定を抽象的に説明するのではなく、具体的にするために、play と akka が活躍できるクラス全体の問題を表す例を考え出しました。
考慮してください: データベースに支えられた (Cassandra クラスターを使用できます) 遠征アプリで、旅行中に興味のあるポイントをお勧めします。ユーザーには、アカウント、入力設定、およびいくつかの設定があります。旅行履歴などを含む旅行ダッシュボード ビューがあります。計画では、Web アプリに Play と Angular を使用する予定です。Web アプリのほとんどは、データベースからユーザー データと POI データを取得し、ビューをテンプレート化して更新する単純なケースです。ただし、エリア内の POI を計算してランク付けするアルゴリズムにより、akka-cluster とアクター モデルは魅力的なソリューションになります。ユーザー データ (毎日更新) と POI データ (場所によって更新) を入力として必要とし、そのデータに基づいてアルゴリズムを実行します。
概要: - リクエストを処理し、リクエストを満たすためにデータベースに支えられたサービスを呼び出すプレイ フロントエンド (ユーザー データ、テンプレートなどを取得する) - フロントエンド (またはクライアント) からリクエストを取得してポイントをランク付けする akka クラスター バックエンド好み、年齢、履歴などのユーザー データに基づいて、その地域に関心のあるユーザーを特定します。これには、アクターを介したデータベース アクセスも必要です。
議論の一部には、選択したデータストアに最適なものが必ず含まれる場合がありますが、ここでは高レベルのソリューションを示します。
Play は単に「データを取得する」リクエストと「データ x、y、z に基づいて計算を行う」リクエストの両方をバックエンドに転送するだけで、すべてのデータ アクセス義務を akka クラスタに委任します。これにより、マルチテナンシーの混乱が解消されます
再生側でテンプレートにデータストア データを入力するためのすべての基本的なリクエストを保持し、CPU を集中的に使用する計算にのみクラスターを使用します。play フロントエンドは計算リクエストを転送します。これは、両方が cassandra クラスターにアクセスできることを意味します (怖い?)
Play アプリは計算以外のすべてを実行し、Akka-http はクライアント用の計算 API を公開します (Angular、両方のマイクロサービスが同じ cassandra クラスターにアクセスできます)
Akka-httpとangularで遊びをなくして休息サービスにする
レベルが高すぎる質問でしたら申し訳ありません。何かご意見は？