web-dev-qa-db-ja.com

マイクロサービスアーキテクチャのフロントエンドとしてSpring MVCを使用することは良い考えですか?

私のマイクロサービスプロトタイプには、現在、フロントエンドとしてSpringブートMVCアプリケーションがあります。アプリケーションは、ビューを完全にバックエンドでレンダリングします。 APIゲートウェイの背後にあるOrderServiceやShippingServiceなどの他のマイクロサービスへの残りの呼び出しを行います。 API Gatewayの背後にあるマイクロサービスのスケーリングは問題ありません。しかし、セッションでフロントエンドMVCをスケーリングすることは、それほど素晴らしいことではないと思います。私はOauth2を実装でき、前面もステートレスに設定できます!?

Angularのような完全なJavaScriptが前に付いたマイクロサービスアーキテクチャの例をよく目にします。ブラウザのJavaScriptクライアントでそれを使用するのは正常ですか?いつサーバー側のレンダリングを使用する必要があり、クライアント側がJavaScriptでレンダリングするのはいつですか?

サーバーサイドレンダリングを使用する理由:すべてのマイクロサービスを自己完結型システムにしたい。 ShippingService(Resource)やOrderService(Resource)などのすべてのサービスには、独自のSpring MVCサーバー側のフロントエンドがあります(サイドと、そのサービスにのみ関連するバックエンド呼び出し用のJavaScriptを提供します)。たとえば、OrderSerivceがダウンしても、配送サービスは完全に使用できます。サービスが利用できないため、OderServiceへのリンクだけは含まれていません。

それ以外の場合、ユーザーにJavaScriptクライアントを提供するWebポータル(Spring MVCアプリケーション)を使用すると同じ動作になりますが、Webポータルがダウンした場合はどうなりますか?

すべての異なるマイクロサービスに関連するすべてのJavaScriptコードはどうですか?常に強い依存関係があるのでしょうか?

また、HTMLをOrderServiceに追加してリンクを提供するだけで、SpringブートMVCアプリを各マイクロサービスに追加するよりも良いかどうかも知りたいです。ユーザーがクリックすると、ブラウザはREST API?の代わりに、OrderSericeによってレンダリングされたHTMLページを表示します。

5
Rocks360

アーキテクチャーの観点からは、ビューに使用するテクノロジーについては心配しません。私はフロントエンドに角度のようなフレームワークを使用することを好みますが、Spring MVCとクライアント側ソリューションの両方で目的を達成できます。

ただし、適切にスケーリングするには、ステートレスなものを作成する必要があります。さらに、クライアントからのすべてのリクエストは、APIゲートウェイ(認証などの処理に最適な場所)を通過する必要があります。

また、各マイクロサービスにSpringブートMVCアプリを追加するのではなく、それがより良いかどうかも知りたいです[...]

それについては、クライアントが別のマイクロサービスと通信しないことを保証できる場合にのみ、各マイクロサービスに対して1つのビューを作成できると思います。別のケースでは、おそらく単一のビューを作成する必要があります。

これがお役に立てば幸いです。

1
Ariel Kohan