Java読書会BOF「マイクロサービスパターン」を読む会 第3回議事録
[ 戻る ]
==============================================================================
Java読書会BOF 「マイクロサービスパターン」を読む会 第3回
==============================================================================
.. csv-table:: 開催概要
"日時","2021年10月30日 10:00 - 17:00"
"場所","てくのかわさき 第４研修室"
"出席者(敬称略)","高橋(智)、高橋(徹)、根本(記)、岩永、松永、加藤、遠藤、平山、今井"
P111 えー、なんでEventuateフレームワークなの から
##############################################################################
Eventuate framework
- Eventuate Tram APIの説明
- Pub/Sub 構造の説明
- CommandProducerは ストリングのコマンドメッセージを送れる
* p113 上 new DomainEventDispatcher () は newしているだけで、外とつながっていない、いったいどう使うのか
* 【誤植】 p113 右下コード アロー表記に改行が入っている
3.4 可用性向上のための非同期メッセージング
==============================================================================
3.4.1 可用性を下げる同期通信
------------------------------------------------------------------------------
* 【誤訳】p114一番下のCreateObject -> CreateOrderの誤訳 英文はCreateOrder になっているが、ここでは同期連動するアプリは信頼性が下がることを説明している。
3.4.1 同期的なインタラクションの取り除き方
------------------------------------------------------------------------------
- 非同期的なインタラクションスタイル
- データのリプリケート
* 【誤訳】データのは、 -> データのレプリケートは、
ローカルにレプリケートされた外部データがあると、処理が止まらず進む
* 問: チャネルはどう実装するのか MQTT? WebSocket?
3.5 まとめ
==============================================================================
- メッセージング手法は 同期(RPC)か非同期か(Messaging)か決める
- Circuit brakerパターンで障害を回避する
- ディスカバリ手法 : Server side discoveryか 3rd party registration または Client-side discoeryかSelf Registration
- Serviceをまたがるトランザクションも Transaction outbox で、できはする。
mySQLもXA使える、JMSかJCAでつなげても良い。
4. サーガによるトランザクションの管理
##############################################################################
saga: メッセージ駆動トランザクションのシーケンス。ACIDとは異なりI(Isolation)がない
代わりにカウンターメジャーを使う。
また、分離性を下げて結果整合性維持のみにして二段階コミットは使わない。
代わりに choreography か orchestration を使う。
翻訳: スターバックスは2フェーズコミットを使わない
https://ameblo.jp/ouobpo/entry-10070039150.html
4.1 マルチサービスアーキテクチャにおけるトランザクション処理
==============================================================================
springなら @TransactionalのアノテーションのみでOK
4.1.1 マイクロサービスアーキテクチャで分散トランザクションが必要になる理由
------------------------------------------------------------------------------
非同期だから
4.1.2 分散トランザクションの問題点
------------------------------------------------------------------------------
最近のDBはXAサポートしていない RammitMQ, Kafkaもサポートしていない
* 【誤植】P122 二段階コミットは --> 2相コミット
4.1.3 Sagaパターンを使ってデータ整合性を維持する方法
------------------------------------------------------------------------------
- Rollbackさせるには Compensating transactionの実行が必要
種類
- compensatable transaction 保証可能
- pivot transaction 必ず成功する
- retriable transaction 再施行可能
* 問: compensationが失敗したら回復どうする?
4.2 サーガのコーディネート
==============================================================================
以下の2種類
- choreograpy 連携動作
- orchestration 司令塔が一括管理する
4.2.1 コレオグラフィーベースのサーガ
------------------------------------------------------------------------------
中心がない
相関IDという横断的なID管理が必要
メリット
- 疎結合、互いのサービスを認識する必要がない
- 単純、変化があったらPublish
デメリット
- 循環依存による事故
- 密結合の危険性、自分に関係するものにはすべてsubscribeしなくてはならない
- ロジックに中心がない
4.2.2 オーケストレーションベースのサーガ
------------------------------------------------------------------------------
* 問: verifyXonsumer で入って OrderApprovedが出てくる
*【誤植】 図4.7の質が悪い OrderReject -> Order Rejected
Orderappreved -> OrderApproved
Cirating Ticket -> Creating ticket
Rejecting ticket -> Rejecting Ticket
- メリット
依存関係が把握しやすい
コレオグラフィーよ疎結合にできる
関心事の分離が進む
4.3.2 分離性の欠如に対抗するためのカウンターメジャー
------------------------------------------------------------------------------
種類
- Semantic lock
- Commutative update 交換可能な更新
- Pessimistic view
- Reread value データの読み直し
- Version file
- By valie
これらの識別は重要
- comensatable transaction
- pivot transaction
- retriable transaction
図4.8 1,2,3 がセットで保証可能トランザクション
カウンターメジャー : Semantic lock
カウンターメジャー : Commutative updates
ロールバック
カウンターメジャー : Pessimistic view
カウンターメジャー : Reread value
楽観的offline lock patternのこと
カウンターメジャー : Version file
カウンターメジャー : by vakye
高額取引のみ2pc transactionにする、とか
4.4 オーダーサービスとCreate Order Sageの設計
==============================================================================
4.4.1 OrderServiceクラス
------------------------------------------------------------------------------
4.4.2 Oreate Order Sageの実装
------------------------------------------------------------------------------
リスト4.3 ①と②が逆
proxyクラスを置く理由は、サービスの型チックができるようになるから
* 問: builderパターンとの違いはなにか? constructurを受け取り側に使わせない
https://eventuate.io/abouteventuatetram.html
4.4.3 OrderCommandHandlerクラス
------------------------------------------------------------------------------
4.4.4 OrderServiceConfigurationクラス
------------------------------------------------------------------------------
Springを使用して @Bean @Configurationを使って Beanを作る
4.5 まとめ
==============================================================================
コレオグラフィーは単純なworkflowのみに使う、それ以上の場合はオーケストレーションの方が良い
ビジネスロジックの設計が複雑化する場合は、ロック制御して、デッドロックのリスクを犯してでも使ったほうがロジックが単純化できて良いことがある。
5 マイクロサービスアーキテクチャにおけるビジネスロジックの設計
##############################################################################
Transaction script, Domain model, Aggregate, Domain event パターン
5.1 ビジネスロジック構成パターン
==============================================================================
5.1.1 <Transaction script>を使ったビジネスロジックの設計
------------------------------------------------------------------------------
単純なビジネスロジック向き
5.1.2 <Domain model>パターンを使ったビジネスロジックの実装
------------------------------------------------------------------------------
最初は単純なビジネスロジックでも、徐々に複雑化していくので、できればこちらのDomain modelで実装すべき
動作と状態の2点でモデリングする
ただし OODは限界があるのでできれば 次のDDDが良い
5.1.3 ドメイン駆動設計<DDD>について
------------------------------------------------------------------------------
パターン
entity
value object
factory
repository
service
(aggregate) これのみ別枠
5.2 DDDのAggregateパターンを使ったドメインモデルの設計
==============================================================================
5.2.1 境界が不明確なことによる問題
------------------------------------------------------------------------------
２つの異なったOrderが無関係に動くと最高額を突破することの例
(以上)
[ 戻る ]