概要
マイクロサービスアーキテクチャを読んだ記録
第4章
アーキテクチャ
- オーケストレーション
- 中央集権・わかりやすい
- コレオグラフィ
- イベントをパブリッシュ
- 各サービスがサブスクライブ
- 疎結合で柔軟、変更を受け入れやすい
- プロセスの監視と追跡に追加の作業が必要
サービスインターフェース
- RPC
- REST
- HATEOAS
- JSON
- 殆どの人が選択する
- XML
- 著者は好き
- XPathを使う
- JSON
- HTTPはサポートツールやエコシステムが充実
- 欠点
- クライアントスタブが使えない
- 遅延
- REST in Practice (O'Reilly)
- HATEOAS
非同期イベントベース連携
- 技術
- RabbitMQ
- Atom
- やめておけ
- SQSもこのあたり？
- 複雑さ
- 「壊滅的フェイルオーバー」
- リトライ
- ワーカの停止
- 「メッセージ病院」
- 不正な状態の最終的な処理
- 適切な監視、相関IDの利用
- 追跡可能性の担保
- Enterprise Integration Patterns
マイクロサービスでのDRY
- 共有コードをサービス境界外で使うと結合が発生する
- 1つのマイクロサービス内ではDRYを守る
- マイクロサービス間ではDRYの違反には寛大に対処する
- 例外
- ロギングなどの共通はOK
参照
- メールサービスに発送通知メールの依頼をかけるとき
- 注文詳細を渡すのでなく、注文の状態を確認できるリソースのURIを渡すことを考える
- リソースの状態が変わりうるため
- 注文詳細を渡すのでなく、注文の状態を確認できるリソースのURIを渡すことを考える
- リソースへの問い合わせが増えるので、キャッシュを活用する
バージョニング
- ポステルの法則
- セマンティックバージョニング
- 異なるエンドポイントの共存が合理的である場合
- 呼び出し元が複数ある場合、それらすべての改修が完了するまで
- デプロイ時の短期間のもの
- 3つ以上の共存は明らかに間違い
- 共存が長期化する場合は、同じサービスに両方のエンドポイントを持つようにする
- バージョン番号をどのようにリクエストに含めるかは悩ましいとしている
- バージョンをクライアントにハードコードさせないのが著者の好み
- URIにバージョンを含めると、ルーティングは簡素となるメリットもある
UI
- API合成
- UIが直接各サービスに問い合わせる
- UI側でマッピングする
- API呼び出しが増える
- UI部品合成
- サービス側がUIの部品を提供する
- デバイスごとのUIを提供しにくい
- BFF
- UIからのリクエストを受けるレイヤーを設け、そこが各サービスに問い合わせる
- モノリシックなゲートウェイになりがち
- サービスにあるべきビジネスロジックが、集約レイヤに入り込みがち
まとめると
- コレオグラフィを選ぶ
- ここに向かって変えていく
- 非同期処理は複雑であり、同期処理時とは異なる配慮が必要
- 異常系の考慮、監視についても先に考えておく必要がある
- HTTP、JSONでやり取りすることをまず考える
- UIは合成レイヤ