7

以前の仕事では AMQP の利点を利用していましたが、rabbitMQ サブプロジェクトの開発には関与していませんでした。私の現在の仕事では、AMQP 実装の 1 つ (おそらく rabbitMQ) の統合を担当したいと考えています。ここでの問題は、AMQP を使用するように上司を説得しなければならないことです。

「RabbitMQ in Action」を読んでいますが、Videla 氏は、AMQP はあらゆるシステムを改善できると書いていますが、自分のプロジェクトを改善する方法がわかりません。間に API 呼び出しを行う 2 つのサーバーのみを使用するため、現在、スケーラビリティの問題はありません。私たちは実際のお金の流れを扱っています。これは、すべての操作の成功確認が必要であることを意味します。つまり、タスクをキューに入れて「忘れる」ことはできません。この場合、AMQP はどのような利点をもたらすでしょうか?

ほとんどスケーリングする必要がない比較的小規模なシステムの実例をいくつか挙げていただけますか? 標準の「ロギング」および「ブロードキャスト メッセージ」の状況は省略してください :)

4

1 に答える 1

8

必要なのはRPCだけのようです。RabbitはRPCで知られていませんが、実際には次の理由で非常に優れた機能を果たします。

  • 多くのメッセージをトランザクション化できます（つまり、すべてを1つのトランザクションにまとめることができます）
  • そのプラットフォーム、言語、プロトコル形式にとらわれない（つまり、バイナリを送信できます）
  • ブローカーのアイデアにより、手順を処理するサーバーを簡単に追加できます。
  • RabbitMQの管理UIを使用して、メッセージのフローとレートを簡単に確認できます。
  • RabbitMQは、アーキテクチャレベルでの制御の反転のようなものです
  • RabbitMQでは、メッセージは契約です...手順ではありません。これはそれを行う正しい方法です。

これを比較してSOAPとしましょう：

  • SOAPはブローカーやルーティングを提供しないため、すべてのサーバーがお互いについて知る必要があります。開発、ステージング、本番用にプラグインのIPアドレスを使用する必要があるのがどれほど面倒かはわかりません。
  • SOAPはトランザクションを提供しません。あなたはそれを自分でしなければなりません。
  • XMLを使用する必要があるSOAP
  • SOAPクライアントよりも信頼性の高いRabbitMQクライアントがあります。SOAPの互換性はPITAです。
  • メッセージとエンドポイントがあるSOAP。場合によっては、これはプロです。

イベントバス/メッセージバスのアイデアを使用するためにRabbitMQを使用する必要はありません。純粋な同期RPCから非同期のイベントバス/メッセージバスに移行するには多くの作業が必要になるため、私は個人的にアプリなしでアプリを作成することはありません。最初からそれを行う方が良いです。

于 2013-02-13T14:21:42.970 に答える