論理アーキテクチャと物理アーキテクチャ
ヒント
このコンテンツは eBook の「コンテナー化された .NET アプリケーションの .NET マイクロサービス アーキテクチャ」からの抜粋です。.NET Docs で閲覧できるほか、PDF として無料ダウンロードすると、オンラインで閲覧できます。
ここで一度立ち止まって、論理アーキテクチャと物理アーキテクチャの違いと、マイクロサービスベースのアプリケーションの設計に適用する方法について考察することをお勧めします。
まず、マイクロサービスを構築するために、特定のテクノロジを使用する必要はありません。 たとえば、マイクロサービスベースのアーキテクチャを作成するために Docker コンテナーは必須ではありません。 このようなマイクロサービスは、プレーン プロセスとして実行することもできます。 マイクロサービスは論理アーキテクチャです。
さらに、マイクロサービスが物理的に単一のサービス、プロセス、またはコンテナー (簡単に言うと、eShopOnContainers の最初のバージョンで採用されるアプローチ) として実装できる場合でも、ビジネス マイクロサービスと物理サービスまたはコンテナーとの間のこのパリティは、数十から数百のサービスで構成される大規模で複雑なアプリケーションを構築する場合は必ずしも必須ではありません。
ここに、アプリケーションの論理アーキテクチャと物理アーキテクチャの違いがあります。 システムの論理アーキテクチャと論理的境界は、物理または展開アーキテクチャと 1 対 1 でマップされるとは限りません。 マップされない可能性はありますが、多くの場合はマップされます。
特定のビジネス マイクロサービスまたは境界コンテキストを指定している場合でも、ビジネス マイクロサービスごとに単一のサービス (ASP.NET Web API など) または単一の Docker コンテナーを作成して実装する方法が最善というわけではありません。 単一のサービスまたはコンテナーを使用して各ビジネス マイクロサービスを実装する必要がある、というルールを持つことは厳格すぎます。
そのため、ビジネス マイクロサービスまたは境界コンテキストは、物理アーキテクチャと一致する (または一致しない) 可能性がある論理アーキテクチャです。 重要な点は、コードと状態を独立してバージョン管理、展開、およびスケーリングできるようにすることで、ビジネス マイクロサービスまたは境界コンテキストを自律的にする必要があることです。
図 4-8 に示すように、カタログ ビジネス マイクロサービスは、いくつかのサービスまたはプロセスで構成されている可能性があります。 また、複数の ASP.NET Web API サービス、または HTTP やその他のプロトコルを使用するその他の種類のサービスである可能性があります。 さらに重要な点は、これらのサービスが同じビジネス ドメインに対して一貫性がある限り、サービスは同じデータを共有できることです。
図 4-8 複数の物理サービスを持つビジネス マイクロサービス
Web API サービスは Search サービスと同じデータをターゲットにしているため、この例のサービスは同じデータ モデルを共有します。 そのため、ビジネス マイクロサービスの物理的な実装では、機能を分割して、必要に応じてこうした各内部サービスを拡大縮小することができます。 通常は Web API サービスに Search サービスよりも多くのインスタンスが必要な場合や、その逆の場合があります。
つまり、マイクロサービスの論理アーキテクチャは、物理的な展開アーキテクチャと必ずしも一致するわけではありません。 このガイドで "マイクロサービス" と言う場合は、1 つ以上の (物理) サービスにマッピングできるビジネスまたは論理マイクロサービスを意味します。 ほとんどの場合は単一のサービスですが、複数のサービスの場合もあります。
.NET