デカップリングのための高速応答を備えたバスとRESTサービス？

Question

いくつかのバックエンドモジュールがREST APIを公開しているため、そのモジュールの1つはAPIを介して他のモジュールを呼び出し、即時応答が必要です。

解決策は、この「トップ」モジュールからREST APIを直接呼び出すことです。問題は、カップリングを作成し、ネイティブにスケーリングまたはフェイルオーバーをサポートしていないことです。

バス（JMS、ESB）の種類は、モジュールが認識しているエンドポイントの必要性を避けることによってモジュールをデカップリングすることを可能にします。彼らはバスに「話す」だけです。

バス経由での高速応答を可能にするために、あなたは何を使用しますか（クラウドにデプロイできるので、別の制約はありません）。

また、REST APIを使用するのは妥当か、JMSリスナーのほうが良いでしょうか？ 私はJMS、キャメル、ESBについて考えました。あなたはそのようなアーキテクチャを使用している企業について知っていますか？

ps：モジュールは、たとえばtomcatインスタンス上で実行されているjava warである可能性があります。

Answer 1

あなたのトップモジュールが他のモジュールを呼び出すことを「知っている」なら、あなたはカップリングしていることが望ましくありません。代わりに、トップモジュールがリンク、フォーム、および/または中間モジュールからの応答からのリダイレクトを介して他のモジュールに向かう場合、JMSソリューションと同じ量の結合があります。

あなたは、このようなF5やVarnishなどのキャッシングリバースプロキシを追加し、（前ではなく）スケーラビリティとフェイルオーバーを必要とする。これは、JMSベースのソリューションよりもスケーラビリティと復元力に優れています。あなたが他のモジュールからの応答を集約および/または変換したい状況で

UDPATE

、あなたは単にcomposed serviceを作成しています。トップモジュールは、中間モジュールを呼び出し、バックエンドモジュールへの1回以上の呼び出しを行い、結果を合成し、適切な応答を送信します。個別のJMSベースのソリューションと比較して、各ホップ（つまり、Top - > Varnish - > Middle - > Varnish - > Backend）の間でHTTPキャッシュを使用すると、データをキャッシュするのがはるかに簡単で効率的です。