TL;DR
1 つのアプリケーションを、それぞれ独自のプロセスで動く小さなサービスの集まりとして作るアーキテクチャのスタイル。各サービスはビジネスの機能ごとに作られ、HTTP の API などの軽い仕組みで通信し、独立してデプロイされる。
なぜ必要か
James Lewis と Martin Fowler の記事によると、モノリスは 1 つのデプロイ単位なので、一部を変えるだけでもアプリケーション全体をビルドし直してデプロイする必要がある。モジュールの境界も時間とともに崩れやすく、スケールも負荷のかかる部分だけでなく全体で行うことになる。マイクロサービスでは、サービスを独立して置き換え、デプロイし、スケールできる。
仕組み
同じ記事は、マイクロサービスに厳密な定義はないとしたうえで、共通する特徴を挙げている。
- サービスを、リモートで呼び出すインタフェースを持つコンポーネントとして扱う
- ビジネスの機能を軸にサービスとチームを分け、チームが UI からデータストアまでを受け持つ
- ロジックはサービス側に置き、通信の仕組みは単純に保つ（smart endpoints and dumb pipes）
- サービスごとに自分のデータベースを持ち、データ管理を分散させる
- 継続的デリバリーなど、インフラを自動化する
- サービスが落ちることを前提に設計する
例
Domain Modeling Made Functional では、境界づけられたコンテキストのデプロイ方法の 1 つとして、ワークフローごとに専用のコンテナを個別にデプロイする形を挙げている。
注意点
Lewis と Fowler によると、リモート呼び出しはプロセス内の呼び出しより遅いので、API の粒度を粗くする必要がある。障害への対処、監視、テストも難しくなり、トランザクションだった処理には結果整合性と補償処理が必要になる。サービスごとにデータベースを持つと複数のデータストアにまたがる整合性が問題になり、これを扱うのがサーガである。また、サービスの境界をまたぐリファクタリングは難しく、複雑さがコンポーネントの内側から、見えにくいコンポーネント間のつながりに移るだけのこともある。