私はSpring Frameworkを学んでいます。ですから、私はアーキテクチャが十分に良いアプリケーションを作りたいと思っています。例えば、私のアプリケーションは、ある種のソーシャルネットワークになります。私はこのWebアプリケーションのためにSpring Bootコンテナを使用しています。 このアーキテクチャは正しいですか？スケーラビリティ、将来のコードサポートなどを意味します。メリットとデメリットは何ですか？私は、REST APIとマイクロサービスを使いたいです。 1ページ= 1コントローラ= 1サービス。Spring Webアプリケーションのアーキテクチャ
1サービス、1つのコントローラ、1ページがに自分自身を制限するのは良いことではありません。ページにはさまざまな種類のサービスがあります。あなたのFacebookのプロフィールが1つのコントローラだったと想像してみてください。それは巨大であり、維持することは不可能です。できるだけ論理的に物事を分解してください。場合によっては、複数のコントローラを使用するページを持つことが理にかなっていることがあります。あなたが複雑なページを持っている場合は、複数のコントローラが必要です。非常に単純なページがあれば、1つのコントローラがそれらの多くを処理できます。
必要がないときに、物事を壊さないように提案することはできますか？あなたのすべてのマイクロサービスは、あなたのアプリケーションでコンポーネントになることができます。そうしないと、HTTPリクエストを転送したり受け取ったりするコードを維持するという膨大なオーバーヘッドが発生します。これは非常に貴重なツールでもあります：トランザクション！トランザクションが失われるため、データの維持に矛盾が生じる可能性があります。あなたの一人の人に留意してください。私は95％が完了した仕事をしている仕事を終えようとしています。仕事をしてから8時間を費やしています。午前2時まで働いています。あなた自身を賛成し、あなた自身のためにもっと仕事を作りません。
ほとんどの点はSnickers3192's answerです。 Microservicesはあなたが前もって計画すべきものではなく、アプリケーションが最初に存在する必要があります。モノリスは最初はうまくいきます。 Martin Fowlerはa good piece about the Microservices yes or no questionと書いています。あなたのアプリケーションが成長し、アプリケーションの部分を個別に拡張する必要があるか、独立して開発できるチームが必要であることがわかったら、Microservicesのビジネスケースがあります（そしてFowlerの記事から分かるように、そのようなアーキテクチャをサポートする準備ができている必要があります）。今はそれが大胆です。
言い換えれば：モノリスで始まり、後でMicroservicesに進化する計画をしている場合は、依存関係ツリーに注意する必要があります。アプリケーションのさまざまな部分が互いにアクセスする必要がありますが、それは問題ありませんが、循環依存を導入しないようにしてください。そうしないと、後でMicroservicesを抽出することは悪夢になります。理想的には、使用するサービスインターフェイスを識別し、今すぐローカルで実装することができますが、後でRest APIを呼び出すことによって実装することができます。
あなたのウェブサイトの複雑さによって、お勧めのパターン（1つのコントローラで1つのサービス）がBackends for Frontendsパターンにマップされます。コントローラ間で多くのUIコンポーネントが共有されている場合は、別のアプローチ、たとえばBig Pipe。しかし、1つのコントローラが、特定のページが知る必要があるすべてをバンドルし、それがすべて同じマシン上にあるのかMicroserviceアーキテクチャにあるのかに関係なく、上流のサービスに委譲するのは理にかなっています。
最後に、マイクロサービスを利用する場合は、復元力に注意してください。 Hystrixやイベントドリブンアーキテクチャーのような回路ブレーカーを使用してください。そうしないと、1つのサービスがアーキテクチャ全体を停止させる可能性があります。