web-dev-qa-db-ja.com

マイクロサービスアーキテクチャでの呼び出しを減らすためのベストプラクティス

異なるホストにデプロイされた複数のアーティファクト（アプリケーション）があります（簡単にするために、それらをA、B、Cと呼びます）。現在、バックエンドへの呼び出しの数を減らす必要があるため、ある種の統合パターンを探しています。 A、B、Cを個別に呼び出す必要はなく、すべての情報を収集してクライアントに返すDを1回呼び出すだけです。私はそれをある種のアグリゲーター・アプリケーションと考えています。

私はマイクロサービスに関するSam Newmanの本を読み、「Backend for frontends」というパターンに従って何かを実装しようとしています。つまり、すべてのチャネル（モバイル、Web）が独自のRESTfulインターフェースを持っています。また、内部呼び出しについては話しますが、実装の詳細については話しません。

私はすべてのアプリケーションにJava（RestEasy）を使用しており、Retrofitを使用して内部呼び出しを送信することを考えました。これにより、問題の一部が解決される可能性があります。他に確認すべきフレームワークはありますか？

さらに、何らかの自動再ルーティングを設定したいのですが、これが適切な方法かどうかわかりません。私はそれを例で説明しようとします：検証されたユーザーのみが使用できるエンドポイントGET/customer/username/sometool/instructionsがあります。顧客が確認されない場合、エンドポイントはGET/customer/username/verificationを呼び出すことで取得できるアップグレードに関する情報を返す必要があります。だから私はさまざまなオプションを考えました：

  1. / customer/username/sometool/instructionsは例外を返し、例外マッパーはエラーコード（「顧客未確認」のようなもの）を読み取り、例外マッパーは/ customer/username/verification->欠点から情報を収集する必要があることを知っています：exceptionマッパーはやがて全能になる
  2. / customer/username/sometool/instructionsは、顧客が既に確認されているかどうかをチェックし、確認されていない場合は/ customer/username/verificationを呼び出して情報を収集します->欠点：命令に実際には属さないロジックを命令エンドポイントに追加します
  3. messageResponseWriterが呼び出される前にインターセプトされる注釈を処理するアグリゲーターモジュール。次のようなもの：@OnFailure（errorCode = "notverified" invoke = "/ customer/username/verification"）->欠点：再び、アグリゲーターは全能になります

これはどのように実装すべきだと思いますか？

javaarchitecturesoamicroservices
3
Daniel

お探しのパターンは API Gateway のようです。 「Edge」または「EdgeService」とも呼ばれます。これは、クラスターへの単一のエントリーポイントとして、およびサービス呼び出しの結果を集約するために使用できます。その他の使用例には、中央認証および/または承認、ルーティング、監視、および復元力が含まれます。

一部の人々はゲートウェイを介して外部コールのみをルーティングし、他の人々はゲートウェイを介して内部コールもルーティングします。

ここでいくつかのテクノロジーを調べます：

Zuul Netflixスタックから。集計用のフィルターを作成しました。

Amazon APIゲートウェイ -AWSで実行している場合（Lambdaを使用すると非常に便利です）。

コング 。

3
Oswin Noetzelmann

バックエンド（A、B＆C）への呼び出しを減らすための最初の要件のパターンは、統合パターンほどではありませんが、通常は「ファサード」と呼ばれます。これは、単に、モバイルアプリのような与えられたクライアント。そのファサードは、内部で他のモジュールまたはシステム（A、B＆C）への呼び出しを調整して、その役割を果たします。これはメディエーターと呼ばれることもあるかもしれません。これは、単純なファサードに加えて、さまざまなデータ構造（クライアント側とサーバー側の構造）間のマッピングを実行します。

REST APIを使用する必要があるため、サーバーではなくクライアント側にクライアント認証のロジックを実装しないでください。RestfulサーバーAPIインターフェースは、サーバーの状態を考慮しないことを意味します。つまり、クライアントがトークンやシークレットなどの情報を渡さない限り、クライアントが認証されているかどうかはわかりません。エラーの場合のルーティングは、クライアントレベルで実装する必要があります。Angular2の例はたくさんあります。この種の実装を示します。

クライアントをモジュール方式で実装する場合、つまり、アプリの一部の情報を送受信するさまざまなコントローラーを使用する場合、エラーマッパーが非常に強力になる恐れはありません。それらは非常に明示的なエラー管理を備えている必要があり、アプリの特定の側面を担当するだけなので、過度に大きくなることはありません。

私はそれがあなたのシステムで少し始めるのを助けることを願っています！

よろしく、ラース

1
Lars

イベントを介したデータ共有について警告します。すぐに、特定のデータの所有者が誰であるかを理解できなくなります。データの単一の真の情報源は、必然的にあいまいになります。

イベント駆動型アーキテクチャは、イベントを使用して他のサービスに何が起こったのかを通知するため、独自のプロセスを開始できます。イベントはデータ送信用ではありませんでした。多くの場合、これは サービス境界が間違っている であることを意味します。あなたの質問がフロントエンドに関するものであることを私は理解していますが、おそらく 私の主張を強調する投稿 は有用な読み物でしょう。

0
Zapadlo