メッセージング（JMSベースのブローカー/キュー）が過剰な場合はいつですか？

Question

JMSベースのブローカーは、システムのデカップリングに非常に便利なツールです。しかし、不変的に、建築と膨張との間の細い線が交差する。ブローカーを理論的に理解している人として、実践的な経験がない人は、「肥えない」ためにどのような助言をすることができますか？ブローカが間違って使用されないように、パフォーマンス要因、設計上の考慮事項、およびシステムの特性を理解しておく必要があります。例えばロギングサービスにイベントをプッシュするためにブローカーを使用することは過度のようです（私の友人の1人は実際にそれをほぼ提案しました）。もう1つの例 - 監査サービス（複数のバックエンドシステムの監査）を作成するときは、（非同期の）メッセージングが良い解決策です。賛否両論？

Answer 1

これはすべての規模の問題です。

すべてのサービスが同じボックスで実行されているか、複数のボックスで実行されていてもすべてがデータベースと通信している限り、メッセージングは​​実際の問題を解決せず、複雑さを増します。

複数のサーバー（場合によっては複数のデータセンター）上で稼動し、（データベースだけでなく）互いに通信する必要のあるサービスが多数ある場合、メッセージングが必要になります。

あなたのサービスのリリーススケジュールが異なる場合もあります。特に、多数のチームが異なるチームによって開発されている場合は特にそうです。互換性を確保し、ダウンタイムを最小限に抑えることが大きな負担となります。非同期メッセージングは​​、そこにあるソリューションの一部です。

最後に、非同期イベントをロギングサービスにプッシュすることは、上記の条件を前提として意味があります。全社規模のロギングサービスを使用して複数のサーバー上で複数のサービスを実行している場合は、ログキューが理にかなっています。