私たちは、サービス指向アーキテクチャー（SOA）を使用して、アーキテクチャーを分割する（そして新しいコンポーネントを追加する）ことを検討してきました。サードパーティによって使用される外部APIがいくつかあり、REST HTTPインターフェースを使用して作成しますが、すべてのコンポーネントが制御されており、同じネットワークですが、テクノロジーが異なる可能性があります（主に.netとruby on rails）。
HTTP（REST、SOAPなど）の代わりにメッセージングシステム（redis、rabbitmq、EMS、私が聞いたことのない他の注目すべき例外...）を使用すると、パフォーマンス/機能が大幅に向上しますか？
私はこのトピックに関する良い情報を見つけるのに苦労しました、そして（おそらくあなたが言うことができるように）私はこのサイドエリアにかなり慣れていないので、アドバイスや良いリソースをいただければ幸いです！
Thnaks
メッセージングは、より緩く結合されたアーキテクチャを提供する傾向があります。インフラストラクチャ全体を停止せずに個々のコンポーネントに障害が発生する可能性があるため、より堅牢になる可能性もあります。
欠点は、複雑さ、パラダイムシフトから非同期モデルへの移行、そして場合によってはパフォーマンスです（特に、どこにでもメッセージを保持している場合）。
また、メッセージングシステムが特に堅牢であることを確認する必要があります。ロジックの1つの側面がダウンして、すべてに影響を与えることなく再起動できますが、コアメッセージベースが失われると、すべてのロジックがダウンして、メッセージングがバックアップされるのを待ちます。
幸いなことに、メッセージバスは、人間がいじったり触れたりすることなく長時間実行できます。これは、どのシステムでもエラーと不安定性の最大の原因です。
@Will Hartungが述べたことに加えて、それはあなたがあなたのシステムで何をしようとしているのかにもよると思います。サーバー/サービスがほとんどなく、完全に独立している傾向があるクライアントサーバータイプのアプリケーションがほとんどの場合、RESToverHTTPを介してサービスコントラクトを実装する方がおそらく簡単です。
一方、システム全体が双方向通信を行っている場合、またはプロセス間呼び出しが多い場合（特に、システムのすべての参加者がクライアントとサーバーの両方になる場合）、次に、メッセージングが最善の策です。メッセージングオプションの中で、AMQP/RabbitMQがこれらすべての中で最も機能が豊富で使いやすいことがわかりました。これは、コーディングするための真の非同期プラットフォームを提供します。
メッセージングを使用する主な利点は、メッセージの種類ごとにキューを設定できることです。これにより、システムが拡張および変更されても、キュー/メッセージは同じになりますが、それらを処理するサービスはその下で変更される可能性があります。層の分離を促進します。
最後に、これは私の意見では大きなことです。メッセージングを適切に使用すると、小さな独立したコードが促進されます。これらは、テストと保守の両方が容易であり、一般に、エンタープライズアーキテクチャを簡素化します。HTTPエンドポイントからあまりにも多くのサービスを処理しようとすると、最終的に（1〜2年の間に）追跡できないエンドポイントが多すぎるか、（2）維持できないスパゲッティコードの混乱に終わります。 。
私の会社はメッセージベースのフレームワークを使用することから始めました、そしてそれは私たちにとって非常にうまくいきました。RabbitMQサーバーは、最も信頼性の高いコンポーネントです。メッセージングまたはSOAについて他に質問がある場合は、遠慮なく質問してください。