Akkaの良いユースケース
私は Akka フレームワーク（Java/Scalaサービスプラットフォーム）について絶賛されていますが、実際のユースケースの多くの例はこれまで見ていません良い。だから私は開発者がそれを成功裏に使ったことについて聞くことに興味があるでしょう。
唯一の制限：チャットサーバーを書く場合を含めないでください。 （なぜ？これは似たようなことの多くの例として使われているからです）
私はこれまで2つの実際のプロジェクトでこれをうまく使ってきました。どちらもほぼリアルタイムの交通情報フィールド（高速道路の車のような交通）にあり、複数のノードに分散され、複数の関係者間でメッセージを統合し、信頼性の高いバックエンドシステムを実現します。私がクライアントに詳細を与えることはまだ自由ではありません、私がOKを得た時、多分それは参照として加えられることができます。
Akkaは、バージョン0.7から始まったにもかかわらず、本当にこれらのプロジェクトを成功させました。 （ところで、scalaを使っています）
大きな利点の1つは、ボイラーメッキをほとんど行わずに、アクターとメッセージからシステムを簡単に作成できることです。手作業によるスレッド化の複雑さがなくても非常にうまく拡張でき、オブジェクト間の非同期メッセージ受け渡しもほぼ無料です。
あらゆるタイプの非同期メッセージ処理をモデル化するのに非常に優れています。私は他のどんなスタイルよりもこのスタイルでどんなタイプの（ウェブ）サービスシステムを書くことを好むでしょう。 （JAX-WSを使用して非同期Webサービス（サーバー側）を作成しようとしたことはありますか？それは多くの配管工事です）。つまり、同期メソッドを使用してすべてが暗黙的に呼び出され、1つのコンポーネントが何かをロックしているため、そのコンポーネントの1つにハングアップしたくないシステムはすべてそう言えます。それは非常に安定しており、失敗に対するlet-it-crash +スーパーバイザーの解決策は本当にうまくいきます。プログラムによるセットアップは簡単で、単体テストは難しくありません。
それから優秀な追加モジュールがあります。 Camelモジュールは本当にAkkaにうまくプラグインして、設定可能なエンドポイントで非同期サービスのそのような簡単な開発を可能にします。
私はこのフレームワークに非常に満足しており、それは私たちが構築するコネクテッドシステムの事実上の標準になりつつあります。
免責事項：私はAkkaのPOです
同時性の推論と正しい取得（アクター、エージェント、データフローの同時性）が非常に簡単で、STMの形での同時制御を備えた同時性smorgasbordを提供します。
あなたが考えるかもしれないいくつかのユースケースはここにあります：
- 取引処理（オンラインゲーム、ファイナンス、統計、賭け、ソーシャルメディア、テレコムなど）
- スケールアップ、スケールアウト、フォールトトレランス/ HA
- サービスバックエンド（あらゆる業界、あらゆるアプリケーション）
- サービスREST、SOAP、cometdなど
- メッセージハブ/統合層として機能する
- スケールアップ、スケールアウト、フォールトトレランス/ HA
- スナップイン同時実行性/並列処理（任意のアプリ）
- 正しい
- 操作しやすく理解しやすい
- 既存のJVMプロジェクトにjarを追加するだけです（Scala、Java、Groovy、またはJRubyを使用してください）。
- バッチ処理（あらゆる業界）
- バッチデータソースに接続するためのキャメル統合
- アクターはバッチワークロードを分割して征服します
- 通信ハブ（テレコム、ウェブメディア、モバイルメディア）
- スケールアップ、スケールアウト、フォールトトレランス/ HA
- ゲームサーバー（オンラインゲーム、賭け）
- スケールアップ、スケールアウト、フォールトトレランス/ HA
- BI /データマイニング/汎用クランチ
- スケールアップ、スケールアウト、フォールトトレランス/ HA
- 他のニースユースケースをここに挿入
使い方の例としては、デビットカード/クレジットカード取引の優先キューがあります。私たちは何百万ものこれらを持っています、そして、その作業の努力は入力文字列型に依存します。トランザクションがCHECKタイプの場合、処理はほとんど行われませんが、それがPOSである場合は、メタデータ（カテゴリ、ラベル、タグなど）とのマージやサービス（電子メール/ SMSアラート、不正検出、低資金残高など）入力タイプに基づいて、ジョブを処理してから作業を実行するために必要なさまざまな特性（ミックスインと呼ばれる）のクラスを構成します。これらの仕事はすべて、異なる金融機関からリアルタイムモードで同じキューに入ります。データがクレンジングされると、永続化、分析のために別のデータストアに送信されるか、ソケット接続にプッシュされるか、またはリフトコメットアクターに送信されます。ワーキングアクターは常にデータをできるだけ速く処理できるように作業の自己負荷分散をしています。追加のサービス、永続性モデル、そして stm を使って重要な決定点を決めることもできます。
JVM上で渡されるErlang OTPスタイルのメッセージは、既存のライブラリとアプリケーションサーバの肩の上でリアルタイムシステムを開発するための素晴らしいシステムになります。
Akkaを使えば、伝統的な esb の場合と同じようにメッセージの受け渡しを行うことができます。また、ソリューションに必要な大量のアクタープール、リモートノード、およびフォールトトレランスを管理するためのフレームワーク内のツールも提供されます。
Akkaを使用してREST呼び出しを非同期的に処理します。非同期Webサーバー（Nettyベース）と共に、ユーザー要求モデルごとの従来のスレッドと比較して、ノード/サーバーあたりのユーザー数を10倍改善できます。 。
上司にあなたのAWSホスティング代金が10分の1になるだろうと言って、それは非常に簡単です！ Shh ...でもAmazonに言わないでください…:)
私たちは大規模なTelcoプロジェクトでAkkaを使っています（残念ながら私は多くの詳細を明らかにすることはできません）。 Akkaのアクターは、Webアプリケーションによってリモートでデプロイされ、アクセスされます。このようにして、Google protobufferをベースにした単純化されたRPCモデルを作成し、Akka Futuresを使用して並列処理を実現します。これまでのところ、このモデルは見事に機能しています。 1つ注意：私たちはJava APIを使っています。
チャットサーバーをある程度上に抽象化すれば、その答えがわかります。
AkkaはErlangの "let it crash"の考え方に似たメッセージングシステムを提供しています。
そのため、例として、さまざまなレベルの耐久性とメッセージングの信頼性が必要なものがあります。
- チャットサーバー
- MMOのネットワーク層
- 財務データポンプ
- IPhone /モバイル/あらゆるアプリの通知システム
- RESTサーバー
- WebMachineに似たものがあるかもしれません（推測）
Akkaの良いところは、永続化のための選択肢であり、STMの実装、RESTサーバー、およびフォールトトレランスです。
チャットサーバーの例に煩わされないでください。特定の種類のソリューションの例として考えてください。
それらすべての優れたドキュメンテーションで、私はギャップがこの正確な質問、ユースケースと例であるように感じます。例を忘れないでください。
（ビデオを見たり、ソースを使って遊んだりした経験だけで書かれていますが、私はakkaを使って何も実装していません。）
私たちは仕事中のいくつかのプロジェクトでAkkaを使用していますが、最も興味深いのは自動車の衝突修理に関するものです。主にイギリスにありますが、現在はアメリカ、アジア、オーストラリア、ヨーロッパにまで拡大しています。安全で費用対効果の高い車両修理を可能にするために、衝突修理情報がリアルタイムで提供されるようにするためにアクターを使用します。
Akkaに関する質問は、本当に「Akkaではできないこと」です。強力なフレームワーク、強力な抽象化、およびすべてのフォールトトレランス機能と統合する機能は、非常に包括的なツールキットです。
Akkaはさまざまな種類のものに使用できます。
私はウェブサイトで働いていました、そこで私は技術スタックをScalaとAkkaに移しました。私達はウェブサイトで起こったことのほとんどすべてのためにそれを使いました。チャットの例は悪いと思うかもしれませんが、基本的にはすべて同じです。
- ウェブサイト上のライブアップデート（例：再生回数、お気に入りなど）
- ライブのユーザーコメントを表示する
- 通知サービス
- 検索と他のすべての種類のサービス
特にライブの更新は、Chatの例が示すものに煮詰まっているので簡単です。サービスの部分は別の興味深いトピックです。なぜなら、リモートアクターを使用することを選択することができ、アプリケーションがクラスタ化されていなくても、それを別のマシンに簡単にデプロイできるからです。
ラップトップからデータセンターまで拡張できるという考えで、私はPCB自動ルーティングアプリケーションにもAkkaを使用しています。あなたが与える力が大きいほど、結果は良くなります。 Akkaはロケーションの透明性も提供しているので、これを通常の並行処理を使用しようとすると実装するのは非常に困難です。
現在、私は自由時間プロジェクトとして、アクターだけを使ってWebフレームワークを構築しています。ここでも利点は、単一のマシンからマシンのクラスタ全体へのスケーラビリティです。その上、メッセージ駆動型アプローチを使用すると、ソフトウェアサービスは最初から指向されます。あなたはそれらすべてのNiceコンポーネントを持っていて、お互いに話し合っていますが、必ずしもお互いを知る必要はありません。
そして、Google Readerがシャットダウンしてから、私はRSSリーダーを使い始めた。もちろんAkkaを使っていた。それは私にとってカプセル化されたサービスについてのすべてです。結論としては、アクターモデル自体が最初に採用すべきものであり、Akkaは、信頼性の高いフレームワークであり、その過程で得られる多くの利点を備えた実装を支援します。
twimpact.com の分析およびトレンド処理を配布するために、そのキャメルプラグインと一緒にakkaを使用しています。毎秒50から1000のメッセージを処理する必要があります。ラクダによるマルチノード処理に加えて、最大のパフォーマンスを得るために単一プロセッサ上の作業を複数のワーカーに分散するためにも使用されます。うまく機能しますが、輻輳の処理方法についてある程度の理解が必要です。
私はAkka（Java api）を試していました。私が試したのは、Akkaのアクターベースの同時実行性モデルと単純なJava同時実行性モデル（Java.util.concurrentクラス）のそれを比較することでした。
ユースケースは、文字数の実装を減らす単純な正規マップでした。データセットはランダムに生成された文字列（長さ400文字）の集まりであり、それらの母音の数を計算します。
Akkaでは、BalancedDispatcher（スレッド間のロードバランシング用）とRoundRobinRouter（自分の関数アクターに制限を設けるため）を使用しました。 Javaでは、単純なfork join手法（work stealingアルゴリズムなしで実装）を使用して、mapを実行したり実行を減らしたりして結果を結合します。中間結果はブロッキングキューに保持され、結合をできるだけ並列にします。おそらく、私が間違っていなければ、それはどういうわけか彼らがメッセージを受け取るAkkaアクターの「メールボックス」の概念をまねるでしょう。
観察：中程度の負荷（〜50000文字列入力）までは、結果は同程度で、反復回数が多少異なります。しかし、私が自分の負荷を100000まで増やすと、Javaソリューションがハングするでしょう。私はこの条件下で20-30スレッドでJavaソリューションを構成しましたが、すべての反復で失敗しました。
負荷を1000000に増やすと、Akkaにとっても致命的でした。私はコードをクロスチェックに興味がある人と共有することができます。
したがって、私にとっては、Akkaは従来のJavaマルチスレッドソリューションよりもスケールアウトが優れているようです。そしておそらくその理由はScalaの根底にある魔法です。
問題ドメインを、イベント駆動型のメッセージ通過メッセージとしてモデル化できる場合は、AkkaがJVMに適していると思います。
テストは実行されました：Javaバージョン：1.6 IDE：Eclipse 3.7ウィンドウズビスタ32ビット。 3GBのRAM。 Intel Core i5プロセッサ、2.5 GHzクロック速度
テストに使用された問題ドメインは議論される可能性があり、私は自分のJavaの知識が許す限り公平になるよう努めました:-)
音声対話システムではAkkaを使います（ primetalk ）。内部的にも外部的にも。単一のクラスタノードで多数のテレフォニーチャネルを同時に実行するには、明らかにマルチスレッドフレームワークが必要です。 Akkaは完璧に機能します。私たちは前のJava同時実行性の悪夢を見ました。そしてAkkaでは、それはただのスイングのようなものです - それは単に機能します。堅牢で信頼性があります。 24 * 7、ノンストップ.
チャネル内には、並行して処理されるイベントのリアルタイムストリームがあります。特に： - 長時間の自動音声認識 - 俳優が行います。 - いくつかのオーディオソース（合成音声を含む）をミキシングするオーディオ出力プロデューサー。 - テキスト - 音声変換は、チャンネル間で共有される別々のアクターセットです。 - 意味および知識処理.
複雑な信号処理を相互接続するには、 SynapseGrid を使用します。これには、複雑なアクターシステムでのDataFlowのコンパイル時チェックという利点があります。
最近、 implementation Akkaの正規のmap-reduceの例：単語数を数えました。つまり、これはAkkaの1つの使用例です。パフォーマンスの向上です。これは JRubyとAkkaのアクター の実験に他なりませんが、AkkaはScalaやJavaだけではないことも示しています。 JVM.