マイクロサービスがふわっとしか分かってないので、改めて勉強。
ドメイン駆動設計やら、APIやら、ソフトウェア設計(ヘキサゴナル、クリーン、レイヤード、オブジェクト指向etc)なども
関わってくるので、追々勉強する、というか、関連したページをサマっていこうかと思います。
今回のフォーカス
MicrosoftのAzure Docsで色々な機能やアーキテクチャなどがまとまっているので、
今回は、マイクロサービス関連で下記ページをサマリーします。なるべく短い言葉を使って。
◆マイクロサービス アーキテクチャ スタイル
https://docs.microsoft.com/ja-jp/azure/architecture/guide/architecture-styles/microservices
マイクロサービス(MS)とは・・・
- MSは、
小さく、独立、疎結合である。 - 各サービスは個別のコードを持つ。小規模なチームが開発。
- サービスは、サービスのデータや外部の状態を保持する役割。
-
APIで相互の通信- マイクローサービス内の通信でAPI利用。
-
クライアントからの通信の場合もAPI Gatewayを置く。- メリット：
- サービスからクライアントの切り離し
- AMQPなどのWebフレンドリでないメッセージングプロトコルをサポート
- 調整、キャッシュ、変換、検証などすぐに使用できるポリシー ⇨どういうこと？
- メリット：
-
polyglotプログラミグ(多言語プログラミング)：簡単に言えば、個々のサービスが別の言語(Python,C#,Java etc)を使ってOK
メリット
- 機敏性：MSは個別にデプロイされるため、バグ修正や機能リリースなどの
更新をアプリ全体の停止なく実施できる。 - 小規模チームで実施可能。大規模になるとコミュニケーションに時間がかかり、管理オーバーヘッドが増大し、生産性が低下する。
- 小さなコードベース：モノリスの場合、依存関係が複雑のため多くの場所でコード変更が必要。
MSでは、コードやデータストアは共有されないので、新しい機能を簡単に追加。 - 障害の分離：個々のマイクロサービスが停止しても、
アプリ全体が停止することない仕組みにすることができる。 - スケーラビリティ：個々のサービスが
独立して拡大縮小が可能。 - データの分離：サービスが独立しているので、スキーマの変更が実行しやすい。
課題
- 複雑：MSはモノリスよりも多くの動的パーツで構成されるため、各サービスは単純だが、全体では複雑。
- 開発およびテストにおいて、モノリシックとはアプローチが異なる。
- ガバナンスの欠如：多くの異なる言語やフレームワークを使用するため、維持が難しくなる。
- サービスの依存関係のチェーンが長すぎる(サービスAがBを呼び出し、BがCを呼び出す)問題がおこる
- データ整合性をとることが難しい。
- 成熟したDevOpsカルチャーが必要。
- スキルと経験が必要。
ベストプラクティス
- 全てを
分散化する。 データストレージは、データを所有するサービス専用とする。API通信- 認証やSSL終了などの横断的な懸念事項は
ゲートウェイにオフロードする。 ドメインのナレッジは、ゲートウェイの外部で保持する。- サービスには
疎結合と高い凝集度(ぎょうしゅうど)が必要。｀ - 障害の分離。
感想
- MSは、アプリを開発することだけでなく、リリース後の機能追加、更新を意識している。
- 分散化(独立)、疎結合、凝集度、API通信というのは、大事なキーワードである。