Akkaフレームワーク(Java / Scalaサービスプラットフォーム)について多くの絶賛を聞いていますが、これまでのところ、それが適しているユースケースの実際の例は多くありません。ですから、開発者がそれをうまく使っていることについて聞いてみたいと思います。
唯一の制限:チャットサーバーを作成する場合は含めないでください。(なぜですか?これは多くの同様のものの例として乱用されているので)
私はこれまで、2つの実際のプロジェクトで非常にうまく使用してきました。どちらもほぼリアルタイムの交通情報フィールド(高速道路の車のような交通)にあり、複数のノードに分散され、複数の関係者間でメッセージを統合し、信頼性の高いバックエンドシステムを備えています。私はまだクライアントの詳細を自由に説明することはできませんが、OKが得られたら、参照として追加できるかもしれません。
Akkaは、バージョン0.7のときに開始したにもかかわらず、これらのプロジェクトを実際に実行しました。(ちなみにscalaを使用しています)
大きな利点の1つは、ボイラープレーティングをほとんど使用せずにアクターとメッセージからシステムを簡単に構成できることです。手巻きスレッドの複雑さを一切伴わずに非常に適切に拡張でき、オブジェクト間で非同期メッセージをほぼ無料で渡すことができます。
あらゆるタイプの非同期メッセージ処理のモデリングに非常に適しています。私は、他のどのスタイルよりも、このスタイルであらゆるタイプの(Web)サービスシステムを作成したいと思います。(JAX-WSを使用して非同期Webサービス(サーバー側)を作成しようとしたことがありますか?これは多くの配管作業です)。つまり、すべてが同期メソッドを使用して暗黙的に呼び出され、1つのコンポーネントが何かをロックしているために、そのコンポーネントの1つにハングアップしたくないシステムです。これは非常に安定しており、障害に対するlet-it-crash+スーパーバイザーソリューションは実際にうまく機能します。すべてをプログラムでセットアップするのは簡単で、単体テストは難しくありません。
次に、優れたアドオンモジュールがあります。Camelモジュールは実際にAkkaにうまくプラグインし、構成可能なエンドポイントを使用して非同期サービスを簡単に開発できるようにします。
私はフレームワークに非常に満足しており、それは私たちが構築する接続システムの事実上の標準になりつつあります。
免責事項:私はAkkaのPOです
推論と正解(アクター、エージェント、データフローの同時実行性)がはるかに簡単で、STMの形式で同時実行性を制御できる同時実行性のスモーガスボードを提供します。
検討する可能性のあるいくつかのユースケースを次に示します。
それをどのように使用するかの例は、デビット/クレジットカード取引の優先キューにあります。これらは何百万もあり、作業の労力は入力文字列のタイプによって異なります。トランザクションのタイプがCHECKの場合、処理はほとんどありませんが、POSの場合は、メタデータ(カテゴリ、ラベル、タグなど)とのマージやサービスの提供(電子メール/ SMSアラート、不正の検出、資金残高の不足など)。入力タイプに基づいて、ジョブを処理してから作業を実行するために必要なさまざまな特性(ミックスインと呼ばれる)のクラスを構成します。これらのジョブはすべて、さまざまな金融機関からリアルタイムモードで同じキューに入ります。データがクレンジングされると、永続性、分析のためにさまざまなデータストアに送信されるか、ソケット接続またはリフトコメットアクターにプッシュされます。作業アクターは、データを可能な限り高速に処理できるように、常に自己負荷分散を行っています。追加のサービス、永続性モデル、および重要な決定ポイントのstm 。
JVMを通過するErlangOTPスタイルのメッセージは、既存のライブラリやアプリケーションサーバーの肩に乗ってリアルタイムシステムを開発するための優れたシステムになります。
Akkaを使用すると、従来のesbと同じようにメッセージパッシングを高速に実行できます。また、ソリューションに必要な膨大な量のアクタープール、リモートノード、およびフォールトトレランスを管理するためのフレームワーク内のツールも提供します。
Akkaを使用してREST呼び出しを非同期で処理します。非同期Webサーバー(Nettyベース)とともに、ノード/サーバーごとに提供されるユーザー数を、従来のユーザーごとのスレッド要求モデルと比較して10倍向上させることができます。
AWSホスティングの請求額が10分の1に減るということを上司に伝えてください。これは、簡単なことです。ああ...アマゾンにそれを言わないでください...:)
私たちは大規模なTelcoプロジェクトでAkkaを使用しています(残念ながら、多くの詳細を開示することはできません)。Akkaアクターは、Webアプリケーションによってリモートでデプロイおよびアクセスされます。このようにして、Googleプロトバッファーに基づく単純化されたRPCモデルがあり、AkkaFuturesを使用して並列処理を実現します。これまでのところ、このモデルは見事に機能しています。注:JavaAPIを使用しています。
チャットサーバーをレベルアップして抽象化すると、答えが得られます。
Akkaは、Erlangの「クラッシュさせる」という考え方に似たメッセージングシステムを提供します。
したがって、例としては、メッセージングのさまざまなレベルの耐久性と信頼性が必要なものがあります。
Akkaの優れている点は、永続性のための選択肢、STM実装、RESTサーバー、およびフォールトトレランスです。
チャットサーバーの例に煩わされることなく、特定のクラスのソリューションの例と考えてください。
優れたドキュメントがすべて揃っているので、この正確な質問、ユースケース、および例にギャップがあるように感じます。例は自明ではないことを覚えておいてください。
(ビデオを見たり、ソースで遊んだりした経験だけで書かれているので、akkaを使って何も実装していません。)
私たちは仕事でいくつかのプロジェクトでAkkaを使用していますが、その中で最も興味深いのは自動車事故の修理に関連しています。主に英国にありますが、現在は米国、アジア、オーストラレーシア、ヨーロッパに拡大しています。アクターを使用して、衝突修理情報がリアルタイムで提供されるようにし、車両の安全で費用効果の高い修理を可能にします。
Akkaの質問は、実際には「Akkaで何ができないか」です。強力なフレームワークと統合する機能、強力な抽象化、およびすべてのフォールトトレランスの側面により、非常に包括的なツールキットになっています。
Akkaはさまざまな用途に使用できます。
私はウェブサイトで作業していて、そこでテクノロジースタックをScalaとAkkaに移行しました。私たちはそれをウェブサイトで起こったほとんどすべてに使用しました。チャットの例は悪いと思うかもしれませんが、基本的にはすべて同じです。
特にライブアップデートは、チャットの例に要約されるため、簡単です。サービスの部分は、リモートアクターの使用を選択するだけで、アプリがクラスター化されていない場合でも、別のマシンに簡単にデプロイできるため、もう1つの興味深いトピックです。
また、ラップトップからデータセンターに拡張できるという考えで、PCBオートルーターアプリケーションにAkkaを使用しています。あなたがそれに与える力が多ければ多いほど、結果は良くなります。Akkaは位置の透過性も提供するため、通常の同時実行を使用しようとすると、これを実装するのは非常に困難です。
現在、自由時間のプロジェクトとして、アクターのみを使用してWebフレームワークを構築しています。この場合も、単一のマシンからマシンのクラスター全体へのスケーラビリティという利点があります。さらに、メッセージ駆動型のアプローチを使用すると、ソフトウェアサービスが最初から指向されます。あなたはそれらすべての素晴らしいコンポーネントを持っており、お互いに話し合っていますが、必ずしもお互いを知っているわけではなく、同じデータセンター内でさえも同じマシン上に住んでいます。
そして、Google Readerがシャットダウンしたので、もちろんAkkaを使用してRSSリーダーから始めました。それはすべて私にとってカプセル化されたサービスに関するものです。結論として:アクターモデル自体が最初に採用すべきものであり、Akkaは非常に信頼性の高いフレームワークであり、その過程で多くのメリットを享受できます。
twimpact.comの分析とトレンド処理を配布するために、ラクダプラグインとともにakkaを使用しています。1秒あたり50から1000のメッセージを処理する必要があります。キャメルを使用したマルチノード処理に加えて、単一のプロセッサでの作業を複数のワーカーに分散して最大のパフォーマンスを実現するためにも使用されます。非常にうまく機能しますが、輻輳の処理方法をある程度理解している必要があります。
Akka(Java API)を試してみました。私が試したのは、Akkaのアクターベースの並行性モデルをプレーンなJava並行性モデル(java.util.concurrentクラス)のそれと比較することでした。
ユースケースは、文字数の実装を減らす単純な標準マップでした。データセットはランダムに生成された文字列(長さ400文字)のコレクションであり、それらの母音の数を計算します。
Akkaの場合、BalancedDispatcher(スレッド間の負荷分散用)とRoundRobinRouter(関数アクターの制限を維持するため)を使用しました。Javaの場合、実行をフォーク/リデュースして結果を結合する単純なフォーク結合手法(作業を盗むアルゴリズムなしで実装)を使用しました。中間結果はブロッキングキューに保持され、参加さえも可能な限り並行させました。おそらく、私が間違っていなければ、それは、メッセージを受信するAkkaアクターの「メールボックス」の概念を何らかの形で模倣するでしょう。
観察:中程度の負荷(〜50000文字列入力)まで、結果は同等であり、反復ごとにわずかに異なりました。ただし、負荷を約100000に増やすと、Javaソリューションがハングします。この条件下で20〜30スレッドでJavaソリューションを構成しましたが、すべての反復で失敗しました。
負荷を1000000に増やすことは、Akkaにとっても致命的でした。クロスチェックに興味のある人なら誰とでもコードを共有できます。
したがって、私にとって、Akkaは従来のJavaマルチスレッドソリューションよりもスケールアウトが優れているようです。そしておそらくその理由はScalaの内部の魔法です。
問題のあるドメインを、それを渡すイベント駆動型メッセージとしてモデル化できるのであれば、AkkaはJVMに適していると思います。
実行されたテスト:Javaバージョン:1.6IDE:Eclipse 3.7 WindowsVista32ビット。3GBのRAM。Intel Core i5プロセッサ、2.5GHzクロック速度
テストに使用された問題のドメインについて議論することができ、Javaの知識が許す限り公平にしようとしたことに注意してください:-)
音声ダイアログシステム(primetalk)ではAkkaを使用します。内部と外部の両方。単一のクラスターノードで多数のテレフォニーチャネルを同時に実行するには、明らかにマルチスレッドフレームワークが必要です。Akkaは完璧に機能します。以前、java-concurrencyには悪夢がありました。そして、Akkaを使用すると、それはスイングのようなものです—それは単に機能します。堅牢で信頼性があります。24 * 7、ノンストップ。
チャネル内には、並行して処理されるイベントのリアルタイムストリームがあります。特に:-長い自動音声認識-俳優と一緒に行われます。-いくつかのオーディオソース(合成音声を含む)をミックスするオーディオ出力プロデューサー。-テキスト読み上げ変換は、チャネル間で共有される個別のアクターのセットです。-セマンティックおよび知識処理。
複雑な信号処理の相互接続を行うには、SynapseGridを使用します。これには、複雑なアクターシステムでのDataFlowのコンパイル時チェックの利点があります。
私は最近、Akka:Wordcountで正規のmap-reduceの例を実装しました。つまり、これはAkkaのユースケースの1つであり、パフォーマンスの向上です。これは、 JRubyとAkkaのアクターの実験でしたが、AkkaがScalaやJavaだけではなく、JVM上のすべての言語で機能することも示しています。