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