モノリスからマイクロサービスへ（1.1 マイクロサービスとは）
目的
マイクロサービスに関する基礎知識の収集
背景
仕事でマイクロサービスにチャレンジする予定がある。
マイクロサービスについて理解しておかなければ、マイクロサービスの良さが活かせないと思ったので。
この章・節に期待すること
「マイクロサービスとは何か」についての記載
この章・節を読む上で必要な知識
- サービス志向アーキテクチャとは
- ビジネスドメインとは
マイクロサービスとは
ビジネスドメインに基づいて分割されたサービス
マイクロサービスでは、ビジネス機能単位でサービスを分割する。
分割したサービス同士はネットワークを介して相互に通信する。
※自分メモ
ビジネスドメイン＝ビジネス機能に基づいたモデリングと理解をしたが、ちゃんとした説明は本文に記載されていなかった。
この本を読む上での前提知識として必要なのかもしれない。
独立してデプロイ可能なサービス
マイクロサービスの重要ポイント。
サービス同士は疎結合であり、一つのサービスに対する変更が他のサービスに影響しないようにする。
これを実現する為には安定したインターフェースが重要。
※自分メモ
安定したインターフェースというのがふんわりとしか理解できていない。
後述の「可能な限り小さなインターフェースを持つ」ことが重要という認識であるが、
安定したインターフェースを設計するには？という部分についてもっと詳細を知りたい。
サービス志向アーキテクチャの一種
※自分メモ
サービス志向アーキテクチャとは？という部分は説明されていなかった。
ここを読む上での前提知識なのかもしれない。
サービスの分割基準が明確
※自分メモ
この時点では「ビジネスドメインに基づいてモデル化する」とだけ言及されていた。
もっと詳細な情報を得る為に、1.4 必要十分なドメイン駆動設計や4 データベースを分割するを読んでみる。
特定の技術に依存しない
マイクロサービスは特定の技術に依存するものではない。
これにより、必要に応じて技術スタックを組み替えることも可能。
カプセル化されたビジネス機能
各サービスはビジネス機能をカプセル化している。
外部からはサービス側が用意したエンドポイントにアクセスすることで利用できる。
マイクロサービスの注意点
データベースを共有するべきではない
独立してデプロイ可能なサービスを実現する為に、データベースは複数のサービス間で共有するべきではない。
各サービスで独立したデータベースを持ち、隠蔽するデータと公開するデータを明確にすること。
マイクロサービスにはコストがある
マイクロサービスの導入には相応のコストがあり、そのコストが「マイクロサービスを導入することによって得られるもの」に見合うものかどうかを判断しなければならない。
※自分メモ この部分を読んでいるときは「なるほど！！」と思っていたが、よくよく考えれば大抵のことには相応のコストがかかるので当然のことだった。
分散システムに関する課題に遭遇する
※自分メモ
分散システムに関する課題について詳細な記載が無い。
5 成長の痛みに書いてありそうなので、ここを読んでみる。
サービスを小さく分割しすぎないこと
一つの機能に対する変更が複数のサービスに及んでしまうと、1つのサービスやモノリスに対する変更よりも手間がかかってしまう。
複数のサービスに対する変更ができるだけ発生しないように、サービスの分割は適切に行う必要がある。
サービス同士はネットワークを介して通信している
ネットワークを介してのやりとりは失敗する可能性があることを考慮しなければいけない。
また、データの一貫性を保つのも難しいのでどう対応するかも検討する必要がある。
大事なこと
段階的な移行
モノリスからマイクロサービスへ移行する際は段階的に移行することが重要。
可能な限り小さなインターフェースを持つ
「独立してデプロイ可能なサービス」を実現するのに重要である。
※自分メモ 先述の通り、この部分に関して詳細な記載が無いのでもっと詳しく知りたい
慣れた技術スタックを利用する
分散システムに関する課題・問題に遭遇した際、慣れ親しんた技術の方が良い。
※自分メモ 先述の通り、分散システムに関する課題が具体的に何なのかわかっていない状態
サービスを分割するラインの決め方
※自分メモ データベースのモデリングが大事になるんだと理解している
感想
例を挙げるなら「ビジネス機能単位で作成した3層アーキテクチャ」が1つのサービスとなるようなイメージ。
1つのサービスに対して複数の技術が含まれるという点が、Vue.jsのSFC（単一ファイルコンポーネント）とよく似ていると思った。
バックエンドとフロントエンドを分離しているアプリケーションは、マイクロサービスではどう管理するのか気になった
