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つのリポジトリ(別名マルチリポ)
パターン:モノリポ

memoO'REILLY Learning

Posted by shi-n