第3回 マイクロサービス アーキテクチャ 読書会 メモ

書くだけ書いて投稿し忘れていた当日書いたメモ。もう第4回も終わってるんだけど...

architect-club.doorkeeper.jp

スライド: 前半

Msa読書会#3前半 from Takehito Amanuma

www.slideshare.net

後半

第三回マイクロサービスアーキテクチャ読書会（後半） from Mizuki Wada

www.slideshare.net

統合

• 数ある選択肢
• 統合から何を得たいのか?
  • 破壊的変更を回避する
  • APIを技術日依存に
    • サービス間の通信に使うAPIを特定技術に依存させない
  • コンシューマにとって単純なサービスに
    • 利用コストが高いと価値がない
    • クライアントライブラリ: 結合度が高まる
  • 内部の実装詳細を隠蔽
    • 変更コスト、破壊リスク、技術的負債
    • ECサイトに対する会員登録API,メール送信APIを公開するべきではない -> ドメインモデル貧血症

顧客とのinterface

• 単純なCRUD: 登録、削除とか

共有データベース

サービス間でDBを共有しても良いか否か

• 大規模な共有APIの場合
  • スキーマ変更によりコンシューマを破壊してしまう
  • データモデル、プロダクトの変更がむずい (ドライバの問題とかあるね)
  • ロジックが分散する: 凝集性の喪失
• いかなる代償を払ってもDB統合を避けるべき

共有しない場合の手段

• 特に言及なし?

REST vs RPC (Remote Procedure Call): Trade-off?

RPC

• finagle, gRPC
• ひどくはない
• プロダクトを選ぶ

REST

• HATEOAS
  • リチャードソンの成熟モデル level 3
    • level 0: the swamp of POX - URI と HTTPが 1to1
    • level 1: Resources - リソースが紐付いている
    • level 2: HTTP Verbs - methodを活用している
    • level 3: Hypermedia controls - RESTful、状態と振る舞いを表している
      • 次の振る舞いを返却してくれたりする

JSON or XML?

• JSONにはlink controlがない -> HAL e.g. Spring HATEOAS
• SIREN
• JSON API
• JSON-LD (linked data)
• de fact standard はなさそう

コレオグラフィ

Coreography

the art or job of deciding how dancers will move in a performance; also : the movements that are done by dancers in a performance

マイクロサービスアーキテクチャにおけるオーケストレーションとコレオグラフィ

• クライアントが直接サービスを呼び出すのではなく、イベントを間に挟んで、イベントが必要な各サービスを呼び出す
  • pub/sub
• Zabbix, Zipkin

orchestration vs coreography どちらを採用するべき?

• coreographyはバッチみたいな大量の処理をするときに向いてそう
• クライアントサービスはorchestrationでも良い?
• 弊社サービスの構成はAPI gatewayというらしい
  • BFFかも?

req/res vs event-based

• 同期モデルか非同期モデルか
• SOAPとかRMIみたいな重いのよりJSONみたいな軽量のものを使いたいよね
• level 3の採用は難しそうですねえ
• まあ両方使うよね
  • ms間はevent-based
  • frontからはreq/res

色々なサービスを呼び出して結果的に1枚のHTMLに収めたい時

↓はアジェンダに当てはめるとここ?

UI

API合成

• UIとサービス作成者の違い
  • 歩調を合わせるのは難しい
• レスポンスの調整ができない

UI部品合成

• SSRとか
• wigetとか

API GatewayとかBFFとか

#MSA読書会 / “BFF @ SoundCloud | ThoughtWorks” https://t.co/iR3bEgoeOd

— 寝起き (@nashcft) July 16, 2016

#MSA読書会 / “StranglerApplication” https://t.co/uuNvFkiVJz

— 寝起き (@nashcft) July 16, 2016

レガシーシステムやパッケージ製品ともやりとりする時の方法

↓はアジェンダに当てはめるとここ?

versioning

• 最大限の見送り
  • フィールドの場所を曖昧にしておく (XPath)
    • 耐性のあるリーダー by Martin Fowler
  • ポステルの法則
• 破壊的変更の早期把握
  • Consumer Driven Contract
    • 回避
    • 受け入れてコンシューマと相談
• semverの利用
• 異なるエンドポイントの共存
  • v1, v2がエンドポイントとして存在するけどロジックは1つ
  • テストの負担がやばいので3つ以上はやめとけ
• 複数バージョンを同時に使う
  • 短時間ならまあいいかも
  • 「慎重に」

会の後

今日の読書会で読み直してて思ったのだけど、共有データベースの節は「複数サービスが単一DBを共有すること」と「アプリケーションとDBを異なるサービスと見立てた時にコミュニケーションの手段が製品やデータモデルに依存すること」の2種類が混同されて述べられてない? #MSA読書会

— 寝起き (@nashcft) July 16, 2016

@nashcft 結合度の話は後者で、共有とは関係ない気がする #MSA読書会

— 寝起き (@nashcft) July 16, 2016