30

Web アプリケーションがマイクロサービスに分岐するポイントについて混乱しています。それは URL レベルですか、それともモデル レベルですか? 例として、3 つのページを提供するモノリシック アプリがあるとします。各ページが個別のユースケースを提供していて、それぞれのページを独自のマイクロサービスでサポートしたいとします。マイクロサービスベースのアーキテクチャを実装する正しい方法は次のうちどれですか。

  • 3 つの異なるアプリ (マイクロサービス) を作成し、それぞれにページの 1 つの (ルート、コントローラー、モデル、テンプレート) が含まれています。そして、リクエストされたページに基づいて、リクエストをその特定のアプリにルーティングします。これは、データベースから HTML までのページ全体が別のアプリによって提供されることを意味します。基本的に、同じ Web サイトのさまざまなページは、バックエンドのさまざまなアプリによって完全に提供されています。
  • 3 つのマイクロサービスは UI を処理せず、ユースケース (モデル、コントローラー、テンプレートなし) のデータのみを処理し、REST API を介して公開します。私は公開アプリを 1 つ持っています。このアプリは、3 つの異なるアプリ (マイクロサービス) に対してデータのみを照会し、ブラウザーに返される html ページを構築します。この場合の Web アプリ内のすべてのページは、内部で 3 つの異なるマイクロサービスを利用する単一のアプリによって提供されています。

ここに画像の説明を入力

4

4 に答える 4

9

問題は、マイクロサービスをモデル化する方法です。

マイクロサービスに関しては、API を介してロジックを公開する 2 番目のアプローチが最も適切です。

マイクロサービスをモデル化するときは、常に次の事実に留意してください。

  • 疎結合: サービスが疎結合の場合、あるサービスを変更しても別のサービスを変更する必要はありません。このマイクロサービスの要点は、システムの他の部分を変更する必要がなくても、1 つのサービスを変更して展開できることです。これは本当に非常に重要です。

  • 強い結束: 関連する行動を一緒に座らせ、無関係な行動を別の場所に配置したいと考えています。なんで?そうですね、振る舞いを変えたいのなら、一箇所で変えられるようにして、その変更をできるだけ早くリリースしたいと思っています。

于 2014-12-22T00:13:06.253 に答える
5

ソフトウェア エンジニアリングではいつものように、答えは場合によるということです。今のところ理由は想像できませんが、オプション 1 は特定のシナリオで役立つ可能性があります。

ただし、マイクロサービスの正式な定義を考慮すると、オプション 2 の方が適切です。マイクロサービスを持つ主な利点の 1 つは、それを再利用できることです。アプリケーションが異なれば、情報を提示する際の要件とニーズも異なります。マイクロサービスがデータの JSON 表現を返すようにすると、この情報をフォーマットする方法がより柔軟になります。

于 2014-11-25T13:08:23.260 に答える
1

現在、2 番目のオプションと同様のアーキテクチャを実装しています。作業中に次の複雑さに遭遇しました。

  • 技術的には、システムにはまだモノリシック アプリ (ユーザー向けアプリ) があります。REST API で変更が行われるたびに、それらの新しい変更を処理するために前面アプリを変更する必要があります。その背後にある新しいマイクロサービスをどのように導入するかについて、私を始めさせないでください。要するに、背後に配置するマイクロサービスが多いほど、API ゲートウェイは大きくなります。( https://www.nginx.com/blog/building-microservices-using-an-api-gateway/ )

API ゲートウェイにはいくつかの欠点もあります。これもまた、開発、展開、および管理が必要な高可用性コンポーネントです。また、API Gateway が開発のボトルネックになるリスクもあります。開発者は、各マイクロサービスのエンドポイントを公開するために API ゲートウェイを更新する必要があります。API Gateway を更新するプロセスは、できるだけ軽量であることが重要です。そうしないと、開発者はゲートウェイを更新するために列に並ぶ必要があります。これらの欠点にもかかわらず、ほとんどの実際のアプリケーションでは、API ゲートウェイを使用することは理にかなっています。

  • 再利用性のために、各マイクロサービスと通信するための独自の動作を定義する抽象化レイヤーを設計しました。マイクロサービスごとに 1 つの具体的な実装。これにより、「RPC コネクタ」と呼ばれるものとそれに対応するマイクロサービスを維持する必要が生じたため、別の複雑なレイヤーが導入されました。個人的には、それぞれのマイクロサービスを維持することに加えて、コネクタを維持する必要があったため、これは開発者の多くの時間を浪費しました。それらのいずれかが古くなっている場合、パブリック アプリは失敗します。また、コネクタの変更には、パブリック アプリの再構築が必要になります (現在、コネクタは jar 依存関係として定義されています)。
  • これは別の投稿やブログで言及されていますが、独自のデータベースを処理する複数のマイクロサービスを扱う場合、外部キーの関係が混乱します。(サービス パターンごとのデータベース) 正面向きのアプリは、それらをつなぎ合わせる必要があるという問題に直面しています。(「このデータが必要ですが、各マイクロサービスでこれらのキーを調べて、誰が何を持っているかを確認する必要があります。」)これが正しい方法だと言っているわけではありませんが、返された複数の行を扱っている場合は、各 ID は、マイクロサービスから個別に解決する必要があります。ただし、これがどれほど効率的かはわかりません。提案をいただければ幸いです。
于 2018-03-17T08:55:25.500 に答える