マイクロサービスJavaのRESTful APIに基づくアーキテクチャ

Question

WebServiceを実装するための最善のアーキテクチャ。一方の側から要求を受け取り、保存して拡張し、新しいパラメータで別のサービスを呼び出します。 これには特別なDesign Patternがありますか？

Answer 1

あなたはそれが"pipes and filters"の仕事のように聞こえると言いましたが、そこから始めるのはあまりありません！

あなたは、着信メッセージのいずれかの検証や変換を行う必要がある場合：

は、より正確な答えを得るために、あなたは自分自身いくつかのより詳細な質問聞きしたいのでしょうか？すべてのリクエストを同じ方法で処理したいのですか、または異なるタイプがありますか？外部サービスは変更される可能性がありますか？そうであれば、頻繁にこれを行いますか？最終的なWebサービス呼び出しが失敗した場合（データベースレコードをロールバックする必要がありますか？）は何をしたいですか？どのように失敗/応答を報告したいのですか？これを報告する必要がありますか？特定の要求の進行状況を追跡するメカニズムが必要ですか？

Answer 2

デザインパターンを探しているので、プロジェクトのコンテキストでmicroservicesオーケストレーションと振り付けの賛否両論を比較したいと思うかもしれません。

Answer 3

呼び出しシステムに即座に応答する必要がない場合は、実現可能であればevent-drivenアプローチを使用することをお勧めします。したがって、RESTサービスの代わりに、メッセージブローカーがあり、特定のイベントに対してサービスがサブスクライブされます。これはメッセージブローカーの背後にある消費者を隠し、システムの結び付きを弱めます。

Spring Cloud Streamで実装できます。シンク（マイクロサービス作成イベント、中間変換を可能にするトランスフォーマ - マイクロサービス、さらに処理の最終結果を受け取るソース - マイクロサービス）があります。

もう1つの可能なケースは、キャメルです。基本的にはすべての統合パターンが組み込まれているため、REST APIまたはイベントに基づいてソリューションを実装するのは問題ではありません。