O’REILLY Learning「マイクロサービスアーキテクチャ 第2版」6〜7
content/uploads/2023/02/9784814400010.jpeg" alt="" width="400″ height="568″ class="alignnone size-full wp-image-6851″ />
https://learning.oreilly.com/library/view/maikurosabisuakitekutiya-di-2ban/9784814400010/
6章 ワークフロー
「ACID」
「Atomicity（原子性、アトミック性）、Consistency（一貫性、整合性）、Isolation（独立性、分離性）、Durability（永続性、耐久性）」
原子性に依存していたシステムを移行する場合、この原子性の欠如が、重大な問題を引き起こすことがある。
分散トランザクション：2フェーズコミット（2PC）
投票フェーズ
コミットフェーズ
マイクロサービスにわたる状態変更を調整するために、2フェーズコミットのような分散トランザクションを使うことは、勧められません。
GoogleのSpanner
https://cloud.google.com/spanner?hl=ja
「Sagas」
Hector Garcia-Molina、Kenneth Salem
https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf
→中核「長期トランザクション」（LLT：Long Lived Transaction）
「The Limits of the Saga Pattern」
Uwe Friedrichsen
https://www.ufried.com/blog/limits_of_saga_pattern/
サーガの実装には、2つのスタイル
「オーケストレーションベースのサーガ」
「コレオグラフィベースのサーガ」
→どちらにしても、誰かがコントロールする必要がある
7章 ビルド
継続的インテグレーション（CI：Continuous Integration）
継続的デリバリ（CD：Continuous Delivery）
CIを本当に理解しているかを確認
・1日1回、メインラインにチェックインしているか
・変更を検証するためのテストスイートがあるか
・ビルドが壊れたとき、その修正がチームの最優先事項であるか
コードのコミットは、早いほどよい
小さなパッチで作業する方がよい
完全に受け入れるには、ソフトウェアをチェックインから本番環境に持っていくまでの、すべてのプロセスをモデル化し、ソフトウェアの特定のバージョンが、リリースに向けてどのような状態にあるかを把握する必要がある。
成果物を、単一のデプロイ可能な塊だと考える。
1つの巨大リポジトリ、1つの巨大ビルド
パターン：マイクロサービスごとに1つのリポジトリ（別名マルチリポ）
パターン：モノリポ