AkkaはJMS / AMQPメッセージブローカーを廃止しますか？
先週は Akka docs とfinallyを深く掘り下げて、アクターシステムとは何か、そしてそれらが解決する問題を理解しました。
私の理解（および経験）従来のJMS/AMQPメッセージブローカーは、以下を提供するために存在するということです。
- プロデューサーとコンシューマー間の非同期処理。そして
- メッセージ配信の保証、持続性、再試行、フォールバックを含む
しかし、Akkaは、必要なインフラストラクチャと運用のオーバーヘッドがすべてない状態でこれを提供していませんか？
- Akkaでは、すべてのActor通信は非同期で非ブロッキングです。そして
- Akkaには、再試行、フォールバック、エスカレーションを実行するための
SupervisorStrategiesが存在します。アクターは、これも要件である場合、実質的にanyタイプのストアに永続化するように構成できます。
私のアプリがAkkaを使用している場合、JMS/AMQPブローカー（ActiveMQ、RabbitMQ、Kafkaなど）を画像に組み込む必要がありますか？言い換えると、Akkaベースの新しいアプリがnewJMS/AMQPブローカークラスターの導入を保証するユースケースはありますか？なぜ、またはそうでないのですか？
唯一の議論は、おそらく私のAkkaアプリは別のシステムと統合する必要があるということでしょう。しかし、その場合、 Akka-Camel モジュールを使用すると、AkkaがCamelの包括的でほぼ無限の統合機能のリスト（TCP、FTP、ZeroMQなど）を利用できます。
考え？
俳優モデル
アクターモデルは、多数の同時計算とステートフル処理を処理するアプリケーションを構築するためのコンピュータサイエンス戦略です。これは唯一の戦略ではありませんが、計算をactorsに移動する、非常によくテストされたシンプルで信頼性の高いアプローチです。
Akkaは、アクターモデルを実装するフレームワークであり、すでに構築されたすべてのインフラストラクチャと機能を備えたアクターシステムを構築できます（JavaScriptの代わりにJQueryを使用するなど）。
メッセージング
メッセージシステムは、メッセージを送受信できるアプリケーションです。基本的なキューから、トピック、pub/sub、永続性、その他の機能を備えた大規模なエンタープライズソフトウェアまで、さまざまな種類がありますが、最終的な目標は同じです。いくつかのバイトをどこかに保存し、何らかの順序でそれらを後で再び取得します。今日の主な使用例は、システムを分離し、さまざまなスケジュールまたは速度で非同期処理を可能にすることです。 RabbitMQ、NATS、Kafkaなどはすべてメッセージシステムの例です。
比較
ActorモデルとAkkaフレームワークは、メッセージキューのような優れた方法アプリケーションを構築するである低レベルのツールです。
メッセージキューの代わりにAkkaを使用できますか？承知しました。アクターモデルを既に使用しているソフトウェアを構築している場合、特に同じスレッドまたはアプリケーション内でメッセージを送信するために、外部メッセージキューはおそらく必要ありません。 Akka Remoting機能を使用して、他のマシンで実行されている他のアクターシステムにメッセージを送信することもできます。
しかし、これによりメッセージングシステムは時代遅れになりますか？絶対違う。これらすべてを自分でコーディングできるからといって、特にアクターモデルが問題に適さない場合や、通信するためにさまざまな言語、アプリケーション、外部API、オペレーティングシステム、データベースなどが必要な場合は、必ずしもそうする必要はありません。 （アクターシステムであるかどうかに関係なく）互いに。
2つのシステム間で一部のメッセージを渡すだけの場合は、メッセージキューを使用します。同じアプリケーション内でスケーラブルなステートフル処理と低レイテンシメッセージングが必要な場合は、アクターモデルを使用します。どちらも完全に異なるレベルで存在し、それらをどのように使用するかは、構築するソリューションによって異なります。
SOこの同じ俳優モデルとメッセージングについての素晴らしい答えがあります： https://stackoverflow.com/questions/5693346/when-to-use-actors-instead-of -messaging-solutions-such-as-websphere-mq-or-tibco