AkkaはJMS / AMQPメッセージブローカーを廃止しますか？[閉まっている]

先週、Akkaのドキュメントを深く掘り下げ、最終的にアクターシステムとは何か、そしてそれらが解決する問題を理解しました。

私の従来のJMS / AMQPメッセージブローカーの理解（および経験）は、以下を提供するために存在するということです。

• プロデューサーとコンシューマー間の非同期処理。そして
• 持続性、再試行、フォールバックを含むメッセージ配信の保証

しかし、Akkaはこれを提供し、必要なインフラストラクチャと運用オーバーヘッドをすべて排除しませんか？

• Akkaでは、すべてのアクター通信は非同期で非ブロッキングです。そして
• Akkaでは、SupervisorStrategies再試行、フォールバック、およびエスカレーションを達成するために存在します。これも要件である場合、実質的にあらゆるタイプのストアに持続するようにアクターを構成できます。

私のアプリがAkkaを使用している場合、JMS / AMQPブローカー（ActiveMQ、RabbitMQ、Kafkaなど）を写真に取り入れる必要がありますか？つまり、新しいAkkaベースのアプリが新しい JMS / AMQPブローカークラスターの導入を保証するユースケースはありますか？なぜですか？

唯一の議論は、おそらく私のAkkaアプリを別のシステムと統合する必要があるということです。ただし、その場合、Akka-Camelモジュールを使用すると、AkkaはCamelの統合機能の網羅的でほぼ無限のリスト（TCP、FTP、ZeroMQ、リストは延々と続く...）を活用できます。

考え？

俳優モデル

アクターモデルは、大量の同時計算とステートフル処理を処理するアプリケーションを構築するためのコンピューターサイエンス戦略です。それは唯一の戦略ではありませんが、計算をアクターに移動する非常によくテストされた、シンプルで信頼性の高いアプローチです。

Akkaは、アクターモデルを実装するフレームワークであり、すべてのインフラストラクチャと機能が既に構築されたアクターシステムを構築できます（javascriptの代わりにJQueryを使用するなど）。

メッセージング

メッセージシステムは、メッセージを送受信できるアプリケーションです。ベーシックキューから、トピック、パブ/サブ、永続性などの機能を備えた大規模エンタープライズソフトウェアまで、さまざまな種類がありますが、最終目標は同じです。いくつかのバイトをどこかに保存して、後で何らかの順序で取得します。今日の主な使用例は、システムを分離し、異なるスケジュールまたは速度で非同期処理を可能にすることです。RabbitMQ、NATS、Kafkaなどは、すべてメッセージシステムの例です。

比較

アクターモデルと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