マイクロサービスアーキテクチャ
とりあえず統合の章まで読んだので感想 & メモ
動機
モノリシックなシステムからマイクロサービス化を検討することは誰しも経験したことがあると思う。
動機としては、
- システムが大きくなるにつれ、人員も増えたが作業のコンフリクトが増えた
- 一つの改修がシステム全体に及ぼす影響が大きい。システム全体のビルド、デプロイが必要。
- パフォーマンスや拡張性、可用性を求めて。
なんかがあるんじゃないかな。特に可用性なんかは、例えばECシステムで、販売システムとヘルプサポートが独立したシステムであれば、どちらかが落ちてもどちらかのシステムで業務が機能する。なんてことが可能だ。
で、本書はそういったメリットを紹介した後、徐々に設計の考え方から解説がはじまっていきます。
サービスの統合
サービスの境界線はどこにするか？
サービスをつなぐインターフェースは？
エンドポイントとサービスのバージョンアップと互換性はどうする？
破壊的変更のあるバージョンアップへの対応は？
外部ベンダが提供する使いづらいAPIを統合するには？
多分、すでにAPIサービスを運用している人達はすでに実践している古典的なこともあると思うけど、考え方やテクニックについての解説などなど、結構読み応えのある量。
複数のマイクロサービスからなる情報を提供するUI
マイクロサービスは最終的にUI上で表示されたりするわけなんだど、UIが複数のサービスからなる情報を提供する時、APIをどう結合していくか。
いくつかのパターンが紹介されているが、僕は「サービスがUIコンポーネントを返す」ってパターンは採用しないかな。
使いづらいものには蓋をしよう
自分たちの裁量では変更できなく扱いづらいAPIを提供するサービスのことだ。つまり他のベンダーから提供されるAPIインターフェース。
本書では「ファサード」で解決しようという提案であるが、「アダプター」という言葉のほうが適切のように感じた。
ちなみに僕の前職では顧客のいいなりで、一応パッケージシステムのAPIがあったんだけど、顧客の要望通りにAPIを変更していっていた(笑)
意外と後方互換をとるのは難しくなかったかな。なんて経験がある。
