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