マイクロサービスアーキテクチャ
SOA
独立デプロイ可能性
マイクロサービスの全て。DB共有するな校歌。
サービスに渡る変更を抑える
ビジネス機能の高凝集度を優先
システム変更のほとんどはビジネス起因。3層分割はシステム的な凝集度は高いがビジネス機能が分散している。
ストリームアラインドチーム
モノリス=システムの全てまとめてデプロイしないといけないもの
分散モノリス
モノリスを使わない理由ではなくマイクロサービスを使う理由を追求すべき
デプロイ管理に本当に困って初めてkubernates等を検討。
マイクロサービスの利点
技術の異業種性/堅牢性/スケーリング/デプロイ容易性/組織連携
マイクロサービスの課題
開発体験(ローカルに何個もアプリを立ち上げないといけない)/コスト/レポート/監視/セキュリティ/テスト/遅延/データ一貫性(サーガ,結果整合性)
ドメインモデルが安定するまでサービス境界は定義しないべき
デリバリ競合を減らす(100人規模の企業なら採用も検討)
凝集とは
一緒に変更され、一緒に存在するコード
関連する振る舞いを一緒にし、関連しない振る舞いを別の場所へ
変更が他へ影響を及ぼさない→疎結合
ゴール
他のサービスへ影響することなくサービスをデプロイさせる
結合の種別(モジュール結合度のマイクロサービス版みたいなやつ。下に行くほど密結合) ドメイン結合
パススルー
コンポーネント同士がデータの受け渡しなどでコミュケーションが発生する状態
※時間的結合
共通/内容
DB等が同じ。複数のサービスが一つのデータにアクセスし更新など行ってる状態。
マイクロサービス化の明確な目標
最初からマイクロサービスにするより既存のモノリスをドメイン境界で分割する方が簡単
ほとんどの場合モノリスは敵ではない
通信パターン
どれも知ってるものばかりで真新しいものないな
コレオグラフィーとオーケストレーション