概要
- Java読書会でせっかく勉強したのにつぎつぎと忘れていくので、印象に残ったところを記録していく
7章 マイクロサービスアーキテクチャでのクエリーの実装
- テーマはマイクロサービスアーキテクチャでいかにしてクエリーを実現するか
API Compositionパターン
- 各マイクロサービスの手前にComposerを立てて、ComposerがAPIをクライアントに公開しつつ、各マイクロサービスに必要なクエリーを発行する
- API GatewayにComposerを埋め込むなり、独立サービスにするなり、役割分担は色々選択肢がある
- 例）ComposerはクライアントにfindOrder()を提供するために、Order、Kitchen、Deliveryなどのマイクローサービスを呼び出して、得られた情報を結合した結果を返す
- 利点：直感的で分かりやすい
- 欠点：ComposerでJoinの処理をするので、大量データを扱うのは難しい
CQRS(Command Query Responsibility Segregation)パターン
-
概要
- クエリー専用のサービスと専用のデータベースを用意する
- クエリー専用サービスは、各マイクロサービスからのイベントを受けて自身のテーブルを更新する
- クエリー機能は、自身のテーブルに対するクエリーで実現する
-
利点
- 更新系（Command系）のサービスと、クエリー系のサービスで関心事を分離できる
- 作り次第でクエリーが高速、かつ多様にできる
- 事前にイベントを受けて情報を貯めておくので、クエリーに都合のいい形を事前に作っておけるので
-
欠点
- 複雑。単にクエリー用サービスが増えるだけでなく、既存の各サービスはイベントを発行しないといけないし
- イベントのタイムラグがあるので、例えばユーザーが自身の行った更新を、即座に見れるか？といったことを考える必要がある
- クエリーAPIには、直前に行った更新が反映されるのを待ち合わせる仕組みも必要
感想
- CQRSは、ちゃんと作れば、それは何でもできるでしょうが、ちゃんと作れるのか？イベントをロストしたら、そのあと全部ずれてしまうけど大丈夫か？
- モノリシックアプリではエンティティの更新イベントのようなものはほとんど無しだけど、マイクロサービスの世界ではイベント作るのってみんなやるものなの？