マイクロサービス指向アプリケーションの設計Designing a microservice-oriented application

このセクションでは、仮想のサーバー側エンタープライズ アプリケーションの開発について説明します。This section focuses on developing a hypothetical server-side enterprise application.

アプリケーションの仕様Application specifications

仮想アプリケーションは、ビジネス ロジックを実行し、データベースにアクセスした後、HTML、JSON、または XML 応答を返すことで要求を処理します。The hypothetical application handles requests by executing business logic, accessing databases, and then returning HTML, JSON, or XML responses. このアプリケーションは、シングル ページ アプリケーション (SPA) を実行するデスクトップ ブラウザー、従来の Web アプリ、モバイル Web アプリ、およびネイティブ モバイル アプリを含むさまざまなクライアントをサポートする必要があるとします。We will say that the application must support a variety of clients, including desktop browsers running Single Page Applications (SPAs), traditional web apps, mobile web apps, and native mobile apps. さらに、アプリケーションは、サード パーティが使用する API を公開します。The application might also expose an API for third parties to consume. マイクロサービスまたは外部アプリケーションを非同期に統合して、部分的な障害が発生した場合に、このアプローチによって、マイクロサービスの回復を支援できるようにする必要もあります。It should also be able to integrate its microservices or external applications asynchronously, so that approach will help resiliency of the microservices in the case of partial failures.

アプリケーションは、次の種類のコンポーネントで構成されます。The application will consist of these types of components:

  • プレゼンテーション コンポーネント。Presentation components. これらは、UI の処理とリモート サービスの使用を担当します。These are responsible for handling the UI and consuming remote services.

  • ドメインまたはビジネス ロジック。Domain or business logic. これは、アプリケーションのドメイン ロジックです。This is the application's domain logic.

  • データベース アクセス ロジック。Database access logic. これは、データベース (SQL または NoSQL) へのアクセスを担当するデータ アクセス コンポーネントで構成されます。This consists of data access components responsible for accessing databases (SQL or NoSQL).

  • アプリケーション統合ロジック。Application integration logic. これには、主にメッセージ ブローカーに基づくメッセージング チャネルが含まれます。This includes a messaging channel, mainly based on message brokers.

特定のサブシステムが他のサブシステムよりも多くのスケーラビリティを必要とするため、アプリケーションには、垂直サブシステムが自律的にスケール アウトできる高いスケーラビリティが必要です。The application will require high scalability, while allowing its vertical subsystems to scale out autonomously, because certain subsystems will require more scalability than others.

アプリケーションは、複数のインフラストラクチャ環境 (複数のパブリック クラウドとオンプレミス) に配置できる必要があり、理想としてはクロスプラットフォームであり、Windows から Linux (またはその逆) に 簡単に移動できる必要があります。The application must be able to be deployed in multiple infrastructure environments (multiple public clouds and on-premises) and ideally should be cross-platform, able to move from Linux to Windows (or vice versa) easily.

開発チームのコンテキストDevelopment team context

アプリケーションの開発プロセスについては、以下を前提としています。We also assume the following about the development process for the application:

  • さまざまなビジネス領域のアプリケーションにフォーカスしている複数の開発チームがあること。You have multiple dev teams focusing on different business areas of the application.

  • 新しいチーム メンバーは短時間で生産的になる必要があり、アプリケーションを簡単に理解して変更できる必要があること。New team members must become productive quickly, and the application must be easy to understand and modify.

  • アプリケーションは長期間進化し、ビジネス ルールは常に変化すること。The application will have a long-term evolution and ever-changing business rules.

  • 適切な長期にわたる保守容易性が必要なこと。これは、将来新しい変更を機敏に実装する一方で、複数のサブシステムを他のサブシステムに与える影響を最小限に抑えながら更新できることを意味します。You need good long-term maintainability, which means having agility when implementing new changes in the future while being able to update multiple subsystems with minimum impact on the other subsystems.

  • アプリケーションの継続的インテグレーションと継続的デプロイを実践すること。You want to practice continuous integration and continuous deployment of the application.

  • アプリケーションを進化させながら、新しいテクノロジ (フレームワークやプログラミング言語など) を活用すること。You want to take advantage of emerging technologies (frameworks, programming languages, etc.) while evolving the application. 新しいテクノロジに移行するときに、アプリケーションの完全移行は行いません。理由は、完全移行にはコストがかかり、アプリケーションの予測可能性と安定性に影響する可能性があるためです。You do not want to make full migrations of the application when moving to new technologies, because that would result in high costs and impact the predictability and stability of the application.

アーキテクチャの選択Choosing an architecture

アプリケーションを配置するアーキテクチャは何にすべきでしょうか。What should the application deployment architecture be? アプリケーションの仕様と開発コンテキストでは、アプリケーションをマイクロサービスとコンテナーとコラボレーションする形の自律的なサブシステムに分解して設計することを強くお勧めします。ここでは、マイクロサービスはコンテナーになります。The specifications for the application, along with the development context, strongly suggest that you should architect the application by decomposing it into autonomous subsystems in the form of collaborating microservices and containers, where a microservice is a container.

このアプローチでは、各サービス (コンテナー) は、まとまりがある狭義に関連する一連の機能を実装します。In this approach, each service (container) implements a set of cohesive and narrowly related functions. たとえば、アプリケーションは、カタログ サービス、受注サービス、バスケット サービス、ユーザー プロファイル サービスなどで構成されます。For example, an application might consist of services such as the catalog service, ordering service, basket service, user profile service, etc.

マイクロサービスは、HTTP (REST) などのプロトコルを使用して通信しますが、可能であれば常に非同期 (AMQP の使用など) でも通信します。これは、特に統合イベントの更新を伝達するときに実行されます。Microservices communicate using protocols such as HTTP (REST), but also asynchronously (for example, using AMQP) whenever possible, especially when propagating updates with integration events.

マイクロサービスは、互いに独立したコンテナーとして開発と配置が行われます。Microservices are developed and deployed as containers independently of one another. これは、開発チームが特定のマイクロサービスを、他のサブシステムに影響を与えずに開発して配置できることを意味します。This means that a development team can be developing and deploying a certain microservice without impacting other subsystems.

各マイクロサービスには独自のデータベースがあり、それによって、他のマイクロサービスから完全に切り離すことができます。Each microservice has its own database, allowing it to be fully decoupled from other microservices. 必要であれば、異なるマイクロサービスのデータベース間の整合性は、コマンド クエリ責務分離 (CQRS) での処理と同じように、アプリケーション レベルの統合を使用して (論理イベント バス経由で) 実現されます。When necessary, consistency between databases from different microservices is achieved using application-level integration events (through a logical event bus), as handled in Command and Query Responsibility Segregation (CQRS). そのため、ビジネス上の制約は、複数のマイクロサービスと関連するデータベース間の最終的な整合性を容認する必要があります。Because of that, the business constraints must embrace eventual consistency between the multiple microservices and related databases.

eShopOnContainers: .NET Core とコンテナーを使用して配置されるマイクロサービス用のリファレンス アプリケーションeShopOnContainers: A reference application for .NET Core and microservices deployed using containers

知識を持っていない可能性がある仮想ビジネス ドメインを検討する代わりに、アーキテクチャとテクノロジにフォーカスできるようにするために、既知のビジネス ドメインが選択されています。具体的には、製品カタログの提示、顧客からの注文の受け取り、在庫の確認、およびその他のビジネス機能を実行する単純化された eコマース (eショップ) アプリケーションです。So that you can focus on the architecture and technologies instead of thinking about a hypothetical business domain that you might not know, we have selected a well-known business domain—namely, a simplified e-commerce (e-shop) application that presents a catalog of products, takes orders from customers, verifies inventory, and performs other business functions. このコンテナー ベースのアプリケーションのソース コードは、eShopOnContainers GitHub リポジトリから入手できます。This container-based application source code is available in the eShopOnContainers GitHub repo.

アプリケーションは、さまざまなストアの UI フロント エンド (Web アプリケーションとネイティブ モバイル アプリ) と、内部マイクロサービスへの統合されたエントリ ポイントとしてのいくつかの API ゲートウェイを使用する、サーバー側で必要なすべての操作用のバックエンド マイクロサービスとコンテナーを含む複数のサブシステムで構成されます。The application consists of multiple subsystems, including several store UI front ends (a Web application and a native mobile app), along with the back-end microservices and containers for all the required server-side operations with several API Gateways as consolidated entry points to the internal microservices. 図 6-1 は、リファレンス アプリケーションのアーキテクチャを示しています。Figure 6-1 shows the architecture of the reference application.

モバイルと SPA クライアントでは、単一の API ゲートウェイのエンドポイントと通信し、これでマイクロサービスと通信します。

図 6-1Figure 6-1. 開発環境用の eShopOnContainers 参照アプリケーション アーキテクチャThe eShopOnContainers reference application architecture for development environment

ホスト環境Hosting environment. 図 6-1 で、単一の Docker ホスト内に配置されたさまざまなコンテナーを確認します。In Figure 6-1, you see several containers deployed within a single Docker host. これは、docker-compose up コマンドを使用して単一の Docker ホストに配置する場合のものです。That would be the case when deploying to a single Docker host with the docker-compose up command. ただし、オーケストレーターまたはコンテナー クラスターを使用する場合は、各コンテナーを別のホスト (ノード) で実行でき、任意のノードで任意の数のコンテナーを実行できます。これについては、アーキテクチャのセクションで既に説明しました。However, if you are using an orchestrator or container cluster, each container could be running in a different host (node), and any node could be running any number of containers, as we explained earlier in the architecture section.

通信アーキテクチャCommunication architecture. eShopOnContainers アプリケーションは、機能アクションの種類 (クエリ対更新とトランザクション) に応じて、2 種類の通信を使用します。The eShopOnContainers application uses two communication types, depending on the kind of the functional action (queries versus updates and transactions):

  • API ゲートウェイ経由でのクライアントからマイクロサービスへの HTTP 通信。Http client-to-microservice communication through API Gateways. これは、クエリで、クライアント アプリから更新またはトランザクション コマンドを受け入れるときに使用されます。This is used for queries and when accepting update or transactional commands from the client apps. API ゲートウェイを使用したアプローチについては、後のセクションで詳しく説明します。The approach using API Gateways is explained in detail in later sections.

  • イベント ベースの非同期通信。Asynchronous event-based communication. これは、マイクロサービス間で更新を伝達するか、外部アプリケーションと統合するために、イベント バス経由で発生します。This occurs through an event bus to propagate updates across microservices or to integrate with external applications. イベント バスは、RabbitMQ などのメッセージング ブローカー インフラストラクチャ テクノロジを使用するか、Azure Service Bus、NServiceBus、MassTransit、Brighter などの上位レベル (抽象化レベル) のサービス バスを使用して実装できます。The event bus can be implemented with any messaging-broker infrastructure technology like RabbitMQ, or using higher-level (abstraction-level) service buses like Azure Service Bus, NServiceBus, MassTransit, or Brighter.

アプリケーションは、コンテナーの形の一連のマイクロサービスとして配置されます。The application is deployed as a set of microservices in the form of containers. クライアント アプリは、API ゲートウェイによって公開されたパブリック URL 経由でコンテナーとして実行されているこれらのマイクロサービスと通信できます。Client apps can communicate with those microservices running as containers through the public URLs published by the API Gateways.

マイクロサービス単位のデータ管理Data sovereignty per microservice

サンプル アプリケーションでは、SQL Server データベースがすべて単一のコンテナーとして配置されますが、各マイクロサービスで独自のデータベースまたはデータ ソースを所有します。In the sample application, each microservice owns its own database or data source, although all SQL Server databases are deployed as a single container. この設計上の決定は、開発者が GitHub からコードを取得して複製し、Visual Studio または Visual Studio Code で簡単に開くことができるようにすることのみを目的として行われました。This design decision was made only to make it easy for a developer to get the code from GitHub, clone it, and open it in Visual Studio or Visual Studio Code. または、カスタム Docker イメージを .NET Core CLI と Docker CLI を使用してコンパイルした後、Docker 開発環境に配置して実行しやすくしています。Or alternatively, it makes it easy to compile the custom Docker images using .NET Core CLI and the Docker CLI, and then deploy and run them in a Docker development environment. どちらの方法でも、データ ソース用のコンテナーを使用することで、開発者は、インフラストラクチャ (クラウドまたはオンプレミス) に強く依存している外部データベースやその他のデータ ソースのプロビジョニングなしで、ほんの数分でビルドと配置を実行できます。Either way, using containers for data sources lets developers build and deploy in a matter of minutes without having to provision an external database or any other data source with hard dependencies on infrastructure (cloud or on-premises).

実際の運用環境では、高可用性とスケーラビリティを実現するために、データベースは、コンテナーではなく、クラウドまたはオンプレミスのデータベース サーバーに基づく必要があります。In a real production environment, for high availability and for scalability, the databases should be based on database servers in the cloud or on-premises, but not in containers.

そのため、マイクロサービス (およびこのアプリケーション内のデータベース) の配置の単位は Docker コンテナーであり、リファレンス アプリケーションはマイクロサービスの 原則を採用するマルチコンテナー アプリケーションです。Therefore, the units of deployment for microservices (and even for databases in this application) are Docker containers, and the reference application is a multi-container application that embraces microservices principles.

その他の技術情報Additional resources

  • eShopOnContainers GitHub リポジトリ。参照アプリケーションのソース コード eShopOnContainers GitHub repo. Source code for the reference application
    https://aka.ms/eShopOnContainers/

マイクロサービス ベースのソリューションの利点Benefits of a microservice-based solution

このようなマイクロサービス ベースのソリューションには、多くの利点があります。A microservice based solution like this has many benefits:

各マイクロサービスが比較的小さい - 管理しやすく進化させやすいEach microservice is relatively small—easy to manage and evolve. 具体的には、次のように使用します。Specifically:

  • 開発者が理解しやすく、適切な生産性ですぐに開始できます。It is easy for a developer to understand and get started quickly with good productivity.

  • コンテナーは短時間で開始されます。これにより、開発者の生産性が向上します。Containers start fast, which makes developers more productive.

  • Visual Studio のような IDE は、小さなプロジェクトを高速で読み込みます。これにより、開発者の生産性が向上します。An IDE like Visual Studio can load smaller projects fast, making developers productive.

  • 各マイクロサービスの設計、開発、および配置は、他のマイクロサービスとは無関係に実行できます。これにより、新しいバージョンのマイクロサービスの配置を簡単かつ頻繁に実行できるため、機敏性が提供されます。Each microservice can be designed, developed, and deployed independently of other microservices, which provides agility because it is easier to deploy new versions of microservices frequently.

アプリケーションの個々 の領域をスケールアウトできますIt is possible to scale out individual areas of the application. たとえば、カタログ サービスとバスケット サービスはスケールアウトが必要になることがありますが、受注サービスでは必要ありません。For instance, the catalog service or the basket service might need to be scaled out, but not the ordering process. マイクロサービス インフラストラクチャは、スケールアウトする際に使用されるリソースに関して、モノリシック アーキテクチャよりも、はるかに効率的です。A microservices infrastructure will be much more efficient with regard to the resources used when scaling out than a monolithic architecture would be.

開発作業を複数のチームに分割できますYou can divide the development work between multiple teams. 各サービスは、1 つの開発チームが所有できます。Each service can be owned by a single development team. 各チームは、管理、開発、配置、およびスケーリングを、残りのチームとは無関係に実行できます。Each team can manage, develop, deploy, and scale their service independently of the rest of the teams.

問題を分離できますIssues are more isolated. あるサービスに問題がある場合、当初影響を受けるのはそのサービスのみであり (マイクロサービス間に直接的な依存関係がある正しくない設計が使用されている場合は除きます)、他のサービスは要求の処理を続行できます。If there is an issue in one service, only that service is initially impacted (except when the wrong design is used, with direct dependencies between microservices), and other services can continue to handle requests. 対照的に、モノリシックな配置アーキテクチャで 1 つのコンポーネントが正常に機能していない場合、それが特にメモリ リークなどのリソースに関係している場合は、システム全体がダウンする可能性があります。In contrast, one malfunctioning component in a monolithic deployment architecture can bring down the entire system, especially when it involves resources, such as a memory leak. さらに、マイクロサービス内の問題が解決したら、アプリケーションの残りの部分に影響を与えることなく、影響を受けたマイクロサービスだけを配置できます。Additionally, when an issue in a microservice is resolved, you can deploy just the affected microservice without impacting the rest of the application.

最新のテクノロジを利用できますYou can use the latest technologies. サービスの開発を個別に開始して、横並びで実行できるため (コンテナーと .NET Core のおかげです)、アプリケーション全体で古いスタックやフレームワークにとらわれることなく最新のテクノロジとフレームワークの使用を臨機応変に開始できます。Because you can start developing services independently and run them side by side (thanks to containers and .NET Core), you can start using the latest technologies and frameworks expediently instead of being stuck on an older stack or framework for the whole application.

マイクロサービス ベースのソリューションのマイナス面Downsides of a microservice-based solution

このようなマイクロサービス ベースのソリューションには、複数のマイナス面もあります。A microservice based solution like this also has some drawbacks:

分散アプリケーションDistributed application. アプリケーションを分散させると、開発者によるサービスの設計とビルドが複雑になります。Distributing the application adds complexity for developers when they are designing and building the services. たとえば、開発者は、HTTP や AMPQ などのプロトコルを使用してサービス間の通信を実装する必要があります。これにより、テストと例外処理が複雑になります。For example, developers must implement inter-service communication using protocols like HTTP or AMPQ, which adds complexity for testing and exception handling. また、待機時間がシステムに追加されます。It also adds latency to the system.

配置の複雑性Deployment complexity. 数十種類のマイクロサービスがあり、高いスケーラビリティを必要とするアプリケーション (サービスごとに複数のインスタンスを作成でき、それらのサービスを複数のホスト間でバランスを取る必要があります) では、IT の運用と管理に対する配置の複雑さが高まります。An application that has dozens of microservices types and needs high scalability (it needs to be able to create many instances per service and balance those services across many hosts) means a high degree of deployment complexity for IT operations and management. マイクロサービス指向のインフラストラクチャ (オーケストレーターとスケジューラなど) を使用していない場合、複雑さの上昇によって、ビジネス アプリケーション自体を大きく上回る開発努力が必要になる可能性があります。If you are not using a microservice-oriented infrastructure (like an orchestrator and scheduler), that additional complexity can require far more development efforts than the business application itself.

アトミック トランザクションAtomic transactions. 複数のマイクロサービス間のアトミック トランザクションは、通常は可能ではありません。Atomic transactions between multiple microservices usually are not possible. ビジネス要件は、複数のマイクロサービス間の最終的な整合性を容認する必要があります。The business requirements have to embrace eventual consistency between multiple microservices.

グローバルなリソースのニーズの増加 (すべてのサーバーまたはホストの合計メモリ、ドライブ、およびネットワーク リソース)。Increased global resource needs (total memory, drives, and network resources for all the servers or hosts). 多くの場合、モノリシック アプリケーションをマイクロサービスのアプローチに置き換える場合、新しいマイクロサービス ベースのアプリケーションで必要な初期のグローバル リソースの量は、元のモノリシック アプリケーションのインフラストラクチャの必要な量よりも大きくなります。In many cases, when you replace a monolithic application with a microservices approach, the amount of initial global resources needed by the new microservice-based application will be larger than the infrastructure needs of the original monolithic application. これは、高いレベルの粒度と分散サービスによって多くのグローバル リソースが必要になるためです。This is because the higher degree of granularity and distributed services requires more global resources. ただし、リソースは一般に低コストであり、モノリシック アプリケーションを進化させる場合の長期的なコストに比べてアプリケーションの特定の領域のみをスケールアウトできるという利点を考慮すると、リソースの使用量の増加は、長期にわたって使用される大規模なアプリケーションにとっては、通常は適切なトレードオフになります。However, given the low cost of resources in general and the benefit of being able to scale out just certain areas of the application compared to long-term costs when evolving monolithic applications, the increased use of resources is usually a good tradeoff for large, long-term applications.

クライアントからマイクロサービスへの直接的な通信に伴う問題Issues with direct client-to-microservice communication. アプリケーションが数十個のマイクロサービスを含む大規模なものであるときに、クライアントからマイクロサービスへの直接的な通信が必要な場合は、課題と制限があります。When the application is large, with dozens of microservices, there are challenges and limitations if the application requires direct client-to-microservice communications. 1 つの問題 は、クライアントのニーズと各マイクロサービスによって公開される API のニーズが一致しない可能性です。One problem is a potential mismatch between the needs of the client and the APIs exposed by each of the microservices. 場合によっては、クライアント アプリケーションは、UI を構成するために多数の独立した要求を行う必要がありますが、これはインターネット経由では効率的ではない可能性があり、モバイル ネットワークでは実用的ではありません。In certain cases, the client application might need to make many separate requests to compose the UI, which can be inefficient over the Internet and would be impractical over a mobile network. そのため、クライアント アプリケーションからバックエンド システムへの要求は最小限に抑える必要があります。Therefore, requests from the client application to the back-end system should be minimized.

クライアントからマイクロサービスへの直接的な通信に伴う別の問題は、一部のマイクロサービスで使用するプロトコルが Web フレンドリではない場合があることです。Another problem with direct client-to-microservice communications is that some microservices might be using protocols that are not Web-friendly. あるサービスではバイナリ プロトコルが使用され、別のサービスでは AMQP メッセージングが使用されることがあります。One service might use a binary protocol, while another service might use AMQP messaging. これらのプロトコルはファイアウォール フレンドリではなく、最善なのは内部的に使用することです。Those protocols are not firewall-friendly and are best used internally. 通常、アプリケーションは、ファイアウォールの外部と通信するために HTTP や Websocket などのプロトコルを使用する必要があります。Usually, an application should use protocols such as HTTP and WebSockets for communication outside of the firewall.

さらに、クライアントからマイクロサービスへの直接的な通信に伴う別のマイナス面は、これらのマイクロサービスのコントラクトのリファクタリングが困難になることです。Yet another drawback with this direct client-to-service approach is that it makes it difficult to refactor the contracts for those microservices. 時間の経過と共に、開発者は、システムをサービスに分割する方法を変更する可能性があります。Over time developers might want to change how the system is partitioned into services. たとえば、2 つのサービスをマージしたり、1 つのサービスを複数のサービスに分割したりします。For example, they might merge two services or split a service into two or more services. ただし、クライアントがサービスと直接的に通信している場合、この種のリファクタリングを実行すると、クライアント アプリとの互換性が破られる可能性があります。However, if clients communicate directly with the services, performing this kind of refactoring can break compatibility with client apps.

アーキテクチャのセクションで説明したように、マイクロサービスに基づく複雑なアプリケーションの設計とビルドを行うときは、単純なクライアントからマイクロサービスへの直接的な通信ではなく、複数の粒度の細かい API ゲートウェイの使用を検討してください。As mentioned in the architecture section, when designing and building a complex application based on microservices, you might consider the use of multiple fine-grained API Gateways instead of the simpler direct client-to-microservice communication approach.

マイクロサービスの分割Partitioning the microservices. 最後に、マイクロサービス アーキテクチャで採用するアプローチに関係なく、エンド ツー エンド アプリケーションを複数のマイクロサービスにどのように分割するかという別の課題があります。Finally, no matter which approach you take for your microservice architecture, another challenge is deciding how to partition an end-to-end application into multiple microservices. このガイドのアーキテクチャで説明したように、使用できるさまざまな手法とアプローチがあります。As noted in the architecture section of the guide, there are several techniques and approaches you can take. 基本的には、他の領域から切り離され、依存関係の数が少ないアプリケーションの領域を識別する必要があります。Basically, you need to identify areas of the application that are decoupled from the other areas and that have a low number of hard dependencies. 多くの場合、これは、ユース ケースによってサービスを分割することと同じです。In many cases, this is aligned to partitioning services by use case. たとえば、e ショップ アプリケーションには、受注プロセスに関連するすべてのビジネス ロジックを担当する受注サービスがあります。For example, in our e-shop application, we have an ordering service that is responsible for all the business logic related to the order process. 他の機能を実装するカタログ サービスとバスケット サービスもあります。We also have the catalog service and the basket service that implement other capabilities. 各サービスが少数の責任のみを持っていることが理想です。Ideally, each service should have only a small set of responsibilities. これは、クラスの変更理由は 1 つだけにする必要があるという、クラスに適用される単一責任原則 (SRP) に似ています。This is similar to the single responsibility principle (SRP) applied to classes, which states that a class should only have one reason to change. ただし、ここではマイクロサービスに関するものであるため、そのスコープは 1 つのクラスよりも大きくなります。But in this case, it is about microservices, so the scope will be larger than a single class. 何よりも、マイクロサービスは、独自のデータ ソースに対する責任も含めて、端から端まで完全に自律的である必要があります。Most of all, a microservice has to be completely autonomous, end to end, including responsibility for its own data sources.

外部アーキテクチャ、内部アーキテクチャ、および設計パターンExternal versus internal architecture and design patterns

外部アーキテクチャは複数のサービスによって構成されるマイクロサービス アーキテクチャであり、このガイドのアーキテクチャのセクションで説明した原則に従っています。The external architecture is the microservice architecture composed by multiple services, following the principles described in the architecture section of this guide. ただし、各マイクロサービスの性質によっては、選択された高度なマイクロサービス アーキテクチャに関係なく、マイクロサービスごとに異なるパターンに基づいて複数の内部アーキテクチャを持つことが一般的であり、そのようにすることが推奨される場合もあります。However, depending on the nature of each microservice, and independently of high-level microservice architecture you choose, it is common and sometimes advisable to have different internal architectures, each based on different patterns, for different microservices. マイクロサービスでは、複数のテクノロジとプログラミング言語を使用することもできます。The microservices can even use different technologies and programming languages. この多様性を図 6-2 に示します。Figure 6-2 illustrates this diversity.

外部アーキテクチャ (マイクロサービス パターン、API ゲートウェイ、回復力のある通信、pub/sub など) と、内部アーキテクチャ (データ駆動型/CRUD、DDD パターン、依存関係の挿入、複数のライブラリなど) の違い。

図 6-2Figure 6-2. 外部アーキテクチャ、内部アーキテクチャ、および設計External versus internal architecture and design

たとえば、eShopOnContainers の例では、カタログ、バスケット、およびユーザー プロファイルのマイクロサービス は単純です (基本的には CRUD サブシステムです)。For instance, in our eShopOnContainers sample, the catalog, basket, and user profile microservices are simple (basically, CRUD subsystems). そのため、その内部アーキテクチャと設計はわかりやすいものです。Therefore, their internal architecture and design is straightforward. ただし、もっと複雑であり、ドメインが非常に複雑である常に変化するビジネス ルールを表すマイクロサービス (受注マイクロサービスなど) が存在する場合があります。However, you might have other microservices, such as the ordering microservice, which is more complex and represents ever-changing business rules with a high degree of domain complexity. このような場合は、eShopOnContainers の受注マイクロサービスで実行しているように、ドメイン駆動設計 (DDD) アプローチによって定義される高度なパターンを特定のマイクロサービスの中で 実装することができますIn cases like these, you might want to implement more advanced patterns within a particular microservice, like the ones defined with domain-driven design (DDD) approaches, as we are doing in the eShopOnContainers ordering microservice. (これらの DDD パターンについては、eShopOnContainers の受注マイクロサービスの実装を説明するセクションで検討します)。(We will review these DDD patterns in the section later that explains the implementation of the eShopOnContainers ordering microservice.)

マイクロサービスごとに異なるテクノロジを使用する別の理由は、各マイクロサービスの性質です。Another reason for a different technology per microservice might be the nature of each microservice. たとえば、C# のようなオブジェクト指向プログラミング言語ではなく、F# のような関数型プログラミング言語や、AI と機械学習ドメインをターゲットにしている場合は R のような言語を使用するほうがふさわしい場合があります。For example, it might be better to use a functional programming language like F#, or even a language like R if you are targeting AI and machine learning domains, instead of a more object-oriented programming language like C#.

重要なのは、各マイクロサービスは、さまざまな設計パターンに基づいて異なる内部アーキテクチャを持つことができるということです。The bottom line is that each microservice can have a different internal architecture based on different design patterns. すべてのマイクロサービスを高度な DDD パターンを使用して実装する必要はありません。これを行うと、過剰エンジニア リングになります。Not all microservices should be implemented using advanced DDD patterns, because that would be over-engineering them. 同様に、常に変化するビジネス ロジックを使用する複雑なマイクロサービスは、CRUD コンポーネントとして実装すべきではありません。これを行うと、コードの質が低下する可能性があります。Similarly, complex microservices with ever-changing business logic should not be implemented as CRUD components, or you can end up with low-quality code.

新しい世界: 複数のアーキテクチャ パターンと多言語マイクロサービスThe new world: multiple architectural patterns and polyglot microservices

ソフトウェア アーキテクトと開発者が使用するアーキテクチャ パターンは多数あります。There are many architectural patterns used by software architects and developers. そのいくつかを次に示します (アーキテクチャ スタイルとアーキテクチャ パターンの混合)。The following are a few (mixing architecture styles and architecture patterns):

マイクロサービスは、ASP.NET Core Web API、NancyFx、ASP.NET Core SignalR (.NET Core 2 で利用可能)、F#、Node.js、Python、Java、C++、GoLang などのさまざまなテクノロジと言語を使用してビルドすることもできます。You can also build microservices with many technologies and languages, such as ASP.NET Core Web APIs, NancyFx, ASP.NET Core SignalR (available with .NET Core 2), F#, Node.js, Python, Java, C++, GoLang, and more.

重要な点は、すべての状況に適合する特定のアーキテクチャ パターン、アーキテクチャ スタイル、テクノロジは存在しないことです。The important point is that no particular architecture pattern or style, nor any particular technology, is right for all situations. 図 6-3 は、さまざまなマイクロサービスで使用できる可能性があるいくつかのアプローチとテクノロジを示しています (順不同です)。Figure 6-3 shows some approaches and technologies (although not in any particular order) that could be used in different microservices.

複数のアーキテクチャ パターンと多言語マイクロサービスとは、言語とテクノロジを混合して、各マイクロサービスのニーズに一致させることができ、引き続き互いに通信できるということです。

図 6-3Figure 6-3. 複数のアーキテクチャ パターンと多言語マイクロサービスの世界Multi-architectural patterns and the polyglot microservices world

図 6-3 に示すように、多数のマイクロサービス (ドメイン駆動設計の用語では境界コンテキスト、自律型のマイクロサービスでは単に "サブシステム" と呼ばれます) で構成されるアプリケーションでは、各マイクロサービスを異なる方法で実装できます。As shown in Figure 6-3, in applications composed of many microservices (Bounded Contexts in domain-driven design terminology, or simply "subsystems" as autonomous microservices), you might implement each microservice in a different way. それぞれのアーキテクチャ パターンは異なる場合があり、アプリケーションの性質、ビジネス要件、および優先度に応じて異なる言語とデータベースを使用できます。Each might have a different architecture pattern and use different languages and databases depending on the application's nature, business requirements, and priorities. 場合によっては、複数のマイクロサービスが同じようになることがあります。In some cases, the microservices might be similar. 各サブシステムのコンテキスト境界と要件は通常異なっているため、通常はそのような状態にはなりません。But that is not usually the case, because each subsystem's context boundary and requirements are usually different.

たとえば、単純な CRUD メンテナンス アプリケーションは、DDD パターンを設計して実装しても意味はありません。For instance, for a simple CRUD maintenance application, it might not make sense to design and implement DDD patterns. ただし、中核となるドメインまたは主要業務では、絶えず変化するビジネス ルールとビジネスの複雑さに対応するために、より高度なパターンを適用する必要があります。But for your core domain or core business, you might need to apply more advanced patterns to tackle business complexity with ever-changing business rules.

特に、複数のサブシステムによって構成される大規模なアプリケーションを処理する場合は、1 つのアーキテクチャ パターンに基づく 1 つの最上位レベルのアーキテクチャを適用すべきではありません。Especially when you deal with large applications composed by multiple sub-systems, you should not apply a single top-level architecture based on a single architecture pattern. たとえば、アプリケーション全体の最上位レベルのアーキテクチャとして CQRS を適用すべきではありませんが、CQRS は特定のサービス セットでは有用である可能性があります。For instance, CQRS should not be applied as a top-level architecture for a whole application, but might be useful for a specific set of services.

すべてのケースに対応できる特効薬のようなアーキテクチャ パターンは存在しません。There is no silver bullet or a right architecture pattern for every given case. "1 つのアーキテクチャ パターンですべてを統治する" ことはできません。You cannot have "one architecture pattern to rule them all." 以降のセクションの説明に従って、各マイクロサービスの優先度に応じて、マイクロサービスごとに適切なアプローチを選択してください。Depending on the priorities of each microservice, you must choose a different approach for each, as explained in the following sections.