マイクロサービスベースのウェブアプリのアーキテクチャ
Webアプリケーションがマイクロサービスに分岐するポイントについて混乱しています-それはURLレベルまたはモデルレベルのどちらですか？例として、3ページを提供する一体型のアプリがあるとします。各ページが個別のユースケースを提供していて、独自のマイクロサービスでそれらの裏付けを取りたいとします。ここで、マイクロサービスベースのアーキテクチャを実装する正しい方法は次のうちどれですか。
- 3つの異なるアプリ（マイクロサービス）を作成し、それぞれに1つのページの（ルート、コントローラー、モデル、テンプレート）を含めます。そして、どのページがリクエストされたかに基づいて、その特定のアプリにリクエストをルーティングします。これは、データベースからHTMLへのページ全体が別のアプリによって提供されることを意味します。基本的に、同じWebサイトの異なるページは、バックエンドの異なるアプリによって完全に提供されています。
- 3つのマイクロサービスは、UIのものを処理せず、それらのユースケース（モデル、コントローラー、テンプレートなし）のデータのみを処理し、REST apiを介して公開します。私は1つの公開アプリを持っています。このアプリは、3つの異なるアプリ（マイクロサービス）に対してデータのみを照会し、ブラウザに返されるhtmlページを構築します。この場合、Webアプリのすべてのページは、3つの異なるマイクロサービスを内部で使用する単一のアプリによって提供されます。
問題は、マイクロサービスをモデル化する方法です。
マイクロサービスに関しては、APIを介してロジックを公開する2番目のアプローチが最も適切です。
マイクロサービスをモデル化するときは常に、次の事実に留意してください。
疎結合：サービスが疎結合されている場合、あるサービスを変更しても、別のサービスを変更する必要はありません。このマイクロサービスの要点は、システムの他の部分を変更する必要に関係なく、1つのサービスに変更を加えてデプロイできることです。これは本当に非常に重要です。
Strong Cohesion：関連する動作をまとめて配置し、関連しない動作を別の場所に配置することを望みます。どうして？まあ、私たちが行動を変えたいなら、私たちはそれを一か所で変えて、その変化をできるだけ早くリリースできるようにしたいです。
ソフトウェアエンジニアリングではいつものように、答えは状況によって異なります。現時点では理由は想像できませんが、オプション1は特定のシナリオで役立つ場合があります。
ただし、マイクロサービスの正式な定義を考慮すると、オプション2はそれをよりよく示しています。マイクロサービスを使用する主な利点の1つは、再利用できることです。さまざまなアプリケーションには、情報を提示するためのさまざまな要件とニーズがあります。マイクロサービスがデータのJSON表現を返すようにすると、この情報をフォーマットする方法にさらに柔軟性が与えられます。
マイクロサービスのAPIゲートウェイパターン apigateway は、さまざまなサービスへの呼び出しの配布または転送を開始できる最初のポイントです
現在、2番目のオプションと同様のアーキテクチャを実装しています。作業中に次の複雑さに遭遇しました：（まだ進行中の作業なので、誰でも自由にこれに参加できます）
- 技術的にはまだ、システムに一体型のアプリ（ユーザー向けアプリ）があります。 REST apiで変更が行われるたびに、これらの新しい変更を処理するために前面のアプリを変更する必要があります。新しいマイクロサービスを導入する方法を私に始めないでくださいつまり、本質的に、背後に配置するマイクロサービスが多いほど、API Gatewayはより大きなものになります（ https://www.nginx.com/blog/building-microservices-using-an-api-gateway/ ）
APIゲートウェイにはいくつかの欠点もあります。これは、開発、展開、および管理する必要がある、さらに別の高可用性コンポーネントです。また、API Gatewayが開発のボトルネックになるリスクもあります。開発者は、各マイクロサービスのエンドポイントを公開するために、API Gatewayを更新する必要があります。 API Gatewayを更新するプロセスは、できるだけ軽量であることが重要です。そうしないと、開発者はゲートウェイを更新するために列で待機することを余儀なくされます。ただし、これらの欠点にもかかわらず、ほとんどの実際のアプリケーションでは、API Gatewayを使用するのが理にかなっています。
- 再利用性のために、各マイクロサービスと通信するための固有の動作を定義する抽象化レイヤーを設計しました。各マイクロサービスの1つの具体的な実装。これにより、対応するマイクロサービスとともに「RPCコネクタ」と呼ばれるものを維持する必要があったため、さらに複雑なレイヤーが導入されました。個人的には、これは、それぞれのマイクロサービスを維持することに加えて、コネクターを維持しなければならなかったため、開発者の多くの時間を費やしました。それらのいずれかが古くなっている場合、パブリックアプリは失敗します。また、コネクタの変更には、パブリックアプリの再構築が必要になります（現在、コネクタをjar依存関係として定義しています）。
- これは別の投稿とブログで言及されていますが、独自のデータベースを処理する複数のマイクロサービスを処理する場合、外部キーの関係が混乱します。 （サービスパターンごとのデータベース）前面のアプリが、それらをつなぎ合わせる必要があるという問題に直面しています。 （「このデータは必要ですが、各マイクロサービスでこれらのキーを調べて、誰が何を持っているかを確認する必要があります。」これは正しい方法だとは言いませんが、返された複数の行を処理している場合各IDはマイクロサービスから個別に解決する必要があります。これがどれほど効率的かはわかりません。私は提案を聞いてうれしいです。