Asp.Netを使用したマイクロサービス

Question

this great articleを読んだ後、私たちのプラットフォームをマイクロサービスアーキテクチャに移行することを考えました。

私たちのスタックは、サーバー上のAsp.Net Web API（Rest ...）です。 正面に角2があります。

私はこの道を続けなければならないかどうかを確認するために、少しの概念証明をしたかったのです。

私の理解として、Webアプリケーションからいくつかのチャンクを取り出し、マイクロサービスに分割する必要があります。最初は、「ユーザー」と「購入履歴」という2つの画面（それぞれがマイクロサービスには大きすぎますが、これはPOCにすぎません）を取って、それぞれをマイクロサービスとして作成したいと考えています。

私はUIがマイクロサービスの一部でなければならないことを読んだので、それぞれのために新しい角度2つのアプリケーションを作成する必要がありますか？

もしそうなら、残りの部分を使ってレンダリングされたHTMLを呼び出す必要がありますか？

Answer 1

フロントエンドとバックエンドのAPIは、2つのサービス（コンポーネント）です。これはすでに、ある種のマイクロサービスアーキテクチャです。どのようなロジックがどのような種類のロジックを複数のサービスに分割した場合、それらのコンポーネントのどれくらいの大きさがあり、どのようなロジックがあるのでしょうか。

マイクロサービスアーキテクチャごとに、システムの各サービス（コンポーネント）には専用ロジック（ドメイン）があり、関連する問題が解決され、データストアにデータが保存され、個別に開発および展開できます。場合によっては、サービス間でデータストアを共有することができます。

ロジックを異なるサービスに分割する目的は、アプリケーションの開発、メンテナンス、サポート、理解を容易にすることです。サービスが多すぎると、オーバーヘッドが大きくなる可能性があります。サービスを作成するには、追加の開発時間を費やす必要があり、サービスも展開アイテムであり、サービス間の通信にはネットワークのオーバーヘッドがあります。したがって、ロジックをサービスに分割することの長所と短所をすべて慎重に検討する必要があります。いくらかのバランスが見つかるはずです。

「ユーザー」と「購入履歴」が全く異なる場合は、共通のロジックを持たず、異なるデータベースに格納することができ、両方が十分に複雑であるため、2つのサービス。 UI部品についても同様です。主なものは、分割は利益をもたらします - 間接費ではありません。

安心してご使用になることはあなた次第ですが、安心のアーキテクチャはマイクロサービスアーキテクチャには必要ありませんが、頻繁に一緒に使用されます。残りはあなたのサービスのデザイン、APIの公開方法などです。