マイクロサービス境界の特定
アーキテクトと開発者は、マイクロサービスの適切なサイズの定義に苦労しています。 ガイダンスでは、多くの場合、大きすぎるか小さすぎる極端な状況を避けることが強調されますが、実際にはそのアドバイスはあいまいになる可能性があります。 しかし、慎重に設計されたドメイン モデルから始めると、各マイクロサービスの適切なサイズとスコープをより簡単に定義できます。
この記事では、ドローン配送サービスを実行中の例として使用します。 シナリオと対応する参照実装の詳細 については、こちらをご覧ください。
ドメイン モデルからマイクロサービスへ
前の 記事では、ドローン配送アプリケーションの境界付けられたコンテキストのセットを定義しました。 次に、これらの境界付けられたコンテキストの 1 つ、出荷の境界付きコンテキストを詳しく調べて、その境界付けられたコンテキストのエンティティ、集計、およびドメイン サービスのセットを特定しました。
これで、ドメイン モデルからアプリケーション設計に進む準備ができました。 ドメイン モデルからマイクロサービスを派生させるために使用できるアプローチを次に示します。
境界付きコンテキストから始めます。 一般に、マイクロサービスの機能は、複数の境界付けられたコンテキストにまたがるべきではありません。 定義上、境界付きコンテキストは、特定のドメイン モデルの境界をマークします。 マイクロサービスによって異なるドメイン モデルが混在している場合は、ドメイン分析に戻って調整する必要がある場合があります。
次に、ドメイン モデルの集計を確認します。 多くの場合、集計はマイクロサービスの候補として適しています。 適切に設計された集計は、適切に設計されたマイクロサービスの特性の多くを示します。
- 集計は、データ アクセスやメッセージングなどの技術的な問題ではなく、ビジネス要件から派生します。
- 集計には、高い機能の凝集性が必要です。
- 集約は永続化の境界です。
- 集計は疎結合する必要があります。
ドメイン サービスは、マイクロサービスの候補としても適しています。 ドメイン サービスは、複数の集計にわたるステートレス操作です。 一般的な例は、複数のマイクロサービスを含むワークフローです。 ドローン配送アプリケーションの例を示します。
機能しない要件を検討してください。 チーム サイズ、データ型、テクノロジ、スケーラビリティ要件、可用性要件、セキュリティ要件などの要因を確認します。 これらの要因により、マイクロサービスが複数の小さなサービスに分割される可能性があります。 それ以外の場合は、複数のマイクロサービスを 1 つのマイクロサービスにマージする可能性があります。
アプリケーションでマイクロサービスを特定したら、次の条件に照らして設計を検証します。
各サービスには 1 つの責任があります。
サービス間で頻繁な呼び出しはありません。 機能を 2 つのサービスに分割すると、それらの機能が過度に頻繁にチャットされる場合、これらの関数が同じサービスに属している現象である可能性があります。
各サービスは、独立して作業する小規模なチームが構築できる十分な小ささです。
2 つ以上のサービスを一緒にデプロイする必要がある相互依存関係はありません。 各サービスは、他のサービスを再デプロイする必要なく、個別にデプロイできる必要があります。
サービスは密接に結合されておらず、個別に進化する可能性があります。
サービス境界は、データの整合性や整合性に関する問題を回避するように設計されています。 場合によっては、データの整合性を維持することは、関連する機能を 1 つのマイクロサービスにグループ化することを意味します。 ただし、厳密な整合性は必ずしも必要ではありません。 分散システムは最終的な整合性を処理するための戦略を提供します。多くの場合、サービスを分解する利点は、管理の複雑さを上回ります。
何よりも、実用的であることが重要であり、ドメイン駆動型の設計は反復的なプロセスであることを覚えておいてください。 不明な場合は、より粗いマイクロサービスから始めます。 マイクロサービスを 2 つの小さなサービスに分割する方が、複数の既存のマイクロサービス間で機能をリファクタリングするよりも簡単です。
例: ドローン配送アプリケーションのマイクロサービスの定義
開発チームは以前、配信、パッケージ、ドローン、アカウントの 4 つの集計と、Scheduler と Supervisor という 2 つのドメイン サービスを特定しました。
配信とパッケージは、マイクロサービスの明白な候補です。 Scheduler と Supervisor は、他のマイクロサービスによって実行されるアクティビティを調整するため、これらのドメイン サービスをマイクロサービスとして実装するのが理にかなっています。
ドローンとアカウントは、他の境界付けられたコンテキストに属しているため、興味深いものです。 1 つのオプションは、Scheduler がドローンとアカウントの境界付きコンテキストを直接呼び出すことです。 もう 1 つのオプションは、出荷境界コンテキスト内にドローンマイクロサービスとアカウント マイクロサービスを作成することです。 これらのマイクロサービスは、出荷コンテキストにより適した API またはデータ スキーマを公開することによって、境界付けられたコンテキスト間を仲介します。
ドローンとアカウントの境界付きコンテキストの詳細は、このガイダンスの範囲外であるため、リファレンス実装でそれらのモック サービスを作成しました。 ただし、この状況で考慮すべきいくつかの要因を次に示します。
他の境界付けられたコンテキストに直接呼び出すことのネットワーク オーバーヘッドは何ですか?
他の境界付きコンテキストのデータ スキーマは、このコンテキストに適していますか。それとも、この境界付きコンテキストに合わせてスキーマを調整することをお勧めしますか?
もう 1 つの境界付きコンテキストはレガシ システムですか? その場合は、レガシ システムと最新のアプリケーションの間で変換する 破損対策レイヤー として機能するサービスを作成できます。
チーム構造は何ですか? 他の境界付けられたコンテキストを担当するチームと簡単にコミュニケーションを取ることができますか? そうでない場合は、2 つのコンテキスト間を仲介するサービスを作成すると、チーム間通信のコストを軽減するのに役立ちます。
ここまで、チームは機能しない要件を考慮していません。 アプリケーションのスループットニーズを評価した後、開発チームは、クライアント要求を処理するために個別のインジェスト マイクロサービスを作成します。 このマイクロサービスは、受信要求を処理用のバッファーに配置することで 、負荷平準化 を実装します。 その後、Scheduler はバッファーから要求を読み取り、ワークフローを実装します。
また、機能以外の要件により、チームはもう 1 つのサービスを作成できます。 既存のサービスでは、リアルタイムでのパッケージのスケジュール設定と配信に重点を置いて取り組みます。 ただし、データ分析のためには、配信履歴も長期保存する必要があります。 当初、チームはこのタスクを配信サービスの一部にすることを検討しました。 ただし、履歴分析のデータ ストレージ要件は、機内操作の要件とは異なります。 詳細については、「 データに関する考慮事項」を参照してください。 その結果、チームは個別の配信履歴サービスを作成しました。 このサービスは、配信サービスから DeliveryTracking イベントをリッスンし、長期ストレージに書き込みます。
次の図は、この時点での設計を示しています。
このアーキテクチャの Visio ファイルをダウンロードします。
次のステップ
この時点で、設計における各マイクロサービスの目的と機能を明確に理解している必要があります。 これで、システムを設計できます。
マイクロサービス アーキテクチャ を設計する