なぜ必要なのか

境界の明確な業務ごとに異なる日程や責任で公開したい。一括のリリースでは無関係な変更まで調整が必要になります。

どう解決するのか

  1. 架空の読書アプリ。一チーム、カタログ・ライブラリ・課金は各v1。A17はタグなし。
  2. 互換性を保つタグ機能をライブラリv2だけにデプロイ。カタログ・課金はv1のまま。
  3. ライブラリがネットワークでカタログを参照し、自分の保存先にtravelを記録。書き込み前の参照タイムアウトならタグなしのまま。失敗を伝え、復旧後に再試行。
独立リリースには遠隔障害への対処が必要

説明用の架空の例

一つの機能だけをリリース

読書アプリ · 一チーム · A17はタグなし

変更：ライブラリにタグを追加。課金の動作は同じ。

契約の互換性を維持：新しいリリースはライブラリのみ。

  1. デプロイ単位 · 1

    カタログ

    v1 → v1

    動作は同じ

    所有する保存先カタログ

  2. デプロイ単位 · 2

    ライブラリ

    v1 → v2

    タグ機能を追加

    所有する保存先ライブラリ

  3. デプロイ単位 · 3

    課金

    v1 → v1

    動作は同じ

    所有する保存先課金

ネットワーク参照 · タグの書き込み前

ライブラリ → カタログ API

遠隔応答は保証されません。課金はこの参照経路に参加しません。

  1. 1 · 成功

    参照成功 → travelを記録 → A17のタグはtravel。

  2. 2 · カタログ参照タイムアウト

    書き込み前に参照失敗 → タグなし。失敗を伝え、復旧後に再試行。

各サービスがデータを所有し、他サービスのテーブルを直接読みません。独立リリースでも監視と障害処理が必要で、依存先の障害は波及し得ます。

所有権の枠はアクセス規則を示し、データベースのマシン数を示しません。

どんな考え方なのか

マイクロサービスは明示的な契約とデータ所有権を持ち、独立してデプロイする業務機能別サービスです。プロセス分割だけでは独立性は生まれません。Lewis・Fowler

ネットワーク障害とサービス間データの調整が必要です。他の機能はモジュラーモノリスに残せます。