マイクロサービスアーキテクチャのメリットを3分で説明する
Sal
inhouse_se マイクロサービスは分散アーキテクチャを形成し、各サービスは独自のプロセスで実行されます。これは元々は物理コンピューターを意味していましたが、すぐに仮想マシンとコンテナーに進化しました。

マイクロサービスアーキテクチャのメリットを3分で説明する

  1. マイクロサービスアーキテクチャの概要
  2. 各サービスの粒度について
  3. データの分離
  4. Devopsについて
  5. フロントエンド
  6. 備考
## マイクロサービスアーキテクチャの概要
以下はマイクロサービスの基本的なトポロジーである マイクロサービスは分散アーキテクチャを形成し、各サービスは独自のプロセスで実行されます。 これは元々は物理コンピューターを意味していましたが、すぐに仮想マシンとコンテナーに進化しました。 **マイクロサービスのコアな価値観は疎な結合です。** そして疎な結合を求めるため、再利用性を破棄しています。 また、各サービスは、ドメインまたはワークフローをモデル化します。 したがって、各サービスには、クラス、その他のサブコンポーネント、データベーススキーマなど、アプリケーション内で動作するために必要なすべてのものが含まれています。 多くの点で、マイクロサービスはドメイン駆動設計における論理概念の物理的な具体化となるのです。
## 各サービスの粒度について
アーキテクトは、マイクロサービスのサービスの正しい粒度を見つけるのに苦労し、サービスを小さくしすぎるという間違いを犯すことがよくあります。 そのため、有用な作業を行うには、サービス間に通信リンクを構築する必要があります。 マイクロサービスで適切な粒度を決定するには次のことを肝に銘じてください。 **コンポーネントの分離を行うことで結合が増えるのであればそれは正しい粒度ではない**
## データの分離
制限付きコンテキストの概念によって推進されるマイクロサービスのもう1つの要件は、データの分離です。 他の多くのアーキテクチャスタイルは、永続性のために単一のデータベースを使用します。 マイクロサービスアーキテクチャは違います。 **統合ポイントとして使用される共有スキーマやデータベースなど、あらゆる種類の結合を回避しようとします。** それぞれのサービスがデータベースを持つことに意味があるのです。
## Devopsについて
従来のサービス指向アーキテクチャーの哲学の1つは、ドメインと運用の両方で、可能な限り多くの機能を再利用することでした。 それによりたった一つの中央集権的なコンポーネントが発生し、監視などを行います。 マイクロサービスアーキテクチャは違います。 アーキテクトはこれら2つの懸念(ドメインと運用)を分割しようとするのです。 つまり、**それぞれのサービスごとに運用の機能を持たせます** このパターンをsidecarパターンと読んでいます。 仮に運用チームという体制が存在する場合、sidecarとなっている監視用のパネルを集約することも可能です。 各サービスの呼び出し状況を把握するための方法はもう一つあります。 **各サービスを直接呼び出すのではなく、サービス検知ツールを経由します** のツールは、リクエストの数と頻度を監視し、サービスの新しいインスタンスを起動して、規模や弾力性の問題を処理します。 このようにしてマイクロサービスアーキテクチャはサービスの弾力性を維持するのです。
## フロントエンド
ここまではマイクロサービスアーキテクチャのバックエンドの話をしてきました。 ユーザーインターフェースがモノシリックである場合、各サービスはAPIを通して呼ばれます。 しかしこれはマイクロサービスアーキテクチャの理想とは少し異なります。 マイクロサービスアーキテクチャでは**フロントエンドでも高度な分離を要求するのです。**
## 備考
title:マイクロサービスアーキテクチャのメリットを3分で説明する description:マイクロサービスは分散アーキテクチャを形成し、各サービスは独自のプロセスで実行されます。これは元々は物理コンピューターを意味していましたが、すぐに仮想マシンとコンテナーに進化しました。