Subscribed unsubscribe Subscribe Subscribe

nashcft's blog

時々何か書く。

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

イベント

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

architect-club.doorkeeper.jp

スライド: 前半

www.slideshare.net

後半

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とか

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

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

versioning

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

会の後