概要

Java読書会でせっかく勉強したのにつぎつぎと忘れていくので、印象に残ったところを記録していく

3章マイクロサービスアーキテクチャで使われるプロセス間通信

略してRPI。同期的なリモート呼び出しを指す
https://microservices.io/patterns/communication-style/rpi.html
具体例としてはRESTやgRPCが挙げられている
SOAP、CORBAやJava RMIなどもこの類に入る
- Java RMIのような言語固有のメカニズムを使うのは、様々な技術が入り乱れるマイクロサービスアーキクテチャには向かないとしている
この本としては、同期呼び出しは可用性を下げるので、あまりおすすめしてない

https://microservices.io/patterns/reliability/circuit-breaker.html
同期呼び出し向けのパターンで、あるサービスへの呼び出しが一定回数、連続で失敗したり応答を返さなかったりした場合、以降の呼び出しは、（おそらくクライアント側のプロキシのところで）即座にエラーを返すようにする
一定期間が過ぎたら再びリモート呼び出しを行うようにする
Java向けにはNetflixのHystrixが紹介されている

サービスが自身のDBに対する処理を行いつつ、他のサービスに対してメッセージを発行する場合の話
例えばOrderのレコードを作りつつ、OrderCreatedイベントを発行する場合（イベントでなくても他のサービスへのリクエスト発行でも良い）
このようなケースではDBの整合性はトランザクションによって保たれるが、DBの処理とメッセージの発行を分けて実施するとイベントの順序が逆転してしまうことがある
例えばOrderがCancelされてから、Orderが生成されるというイベント順になったりする
解決方法としては、メッセージをキューイングするためのテーブル（Outboxテーブル）を用意して、元々のテーブル更新と、メッセージキューイングのテーブル更新を一つのトランザクションで行う
- Transactional outboxパターン： https://microservices.io/patterns/data/transactional-outbox.html
Outboxテーブルに貯められたメッセージは以下のいずれかの方法で取り出され、その後ブローカーに渡される
- Polling publisherパターン：https://microservices.io/patterns/data/polling-publisher.html
  - 名前の通りOutboxテーブルのポーリング
- Transaction log tailing： https://microservices.io/patterns/data/transaction-log-tailing.html
  - Outboxテーブルのトランザクションログを監視する。

サービス間の通信は非同期メッセージング推奨とは言っても、公開APIはRESTだったりする
- 反応の遅い非同期通信では、RESTに求められるパフォーマンスがでない懸念がある
解決法1: 例えばOrderのGETの場合は、顧客情報やレストラン情報などのミラーをOrderService内に抱えれば、サービス間の非同期通信自体しなくてすすむ
- これは7章のCQRSでより発展した議論になる
解決法2：REST APIでは、不完全状態のOrderをつくって、IDだけ返す。あとはクライアントがOrderの状態をポーリングする

色々な概念・パターンが登場したけど、重要なのは「トランザクショナルメッセージング」
昔、Mutexロックを持っている状態で、キューにメッセージを入れる実装をしたことがあったが、発想は同じ
トランザクションもキューも処理をシリアライズする仕組みなので、組み合わせて使うと全体としてもシリアルになる
本書ではこれ以降の議論は、トランザクショナルメッセージングによって、メッセージやイベントの順序性が保たれていることに立脚しているので、ここの部分は極めて重要
著者が言うようにトランザクショナルメッセージングを実現する高水準なライブラリがEventuateしなないのであれば、マイクロサービスパターンを活用したマイクロサービスアーキテクチャを構築するには、事実上Eventuateを使う以外にないということになるのかもしれない。
- 代替品はないのか？