マイクロサービスとデータストレージ

モノリシックREST APIをマイクロサービスアーキテクチャに移行することを検討していますが、データストレージについて少し混乱しています。私が見るように、マイクロサービスの利点のいくつかは次のとおりです。

• 水平方向にスケーラブル-負荷やサーバーのダウンに対処するために、マイクロサービスの複数の冗長コピーを実行できます。
• 疎結合-他のマイクロサービスを変更することなく、マイクロサービスの内部実装を変更できます。また、独立して展開および変更することもできます。

私の問題はデータストレージです。ご覧のとおり、いくつかのオプションがあります。

1. すべてのマイクロサービスで共有される単一のデータベースサービス-これは、疎結合の利点を完全に排除するようです。
2. 各マイクロサービスにローカルにインストールされたデータベースインスタンス-これを水平方向にスケーリングする方法が見当たらないため、オプションとは思わない。
3. 各マイクロサービスには独自のデータベースサービスがあります-疎結合と水平スケーリングの利点を保持するため、これは最も有望であると思われます（冗長データベースコピーの使用および/または複数でのシャーディング）

私には、3番目のオプションが唯一のオプションのように思えますが、私には信じられないほど重く、非常に過剰に設計されたソリューションです。私がそれを正しく理解している場合、4-5マイクロサービスを備えたシンプルなアプリケーションでは、16-20サーバーを実行する必要があります-マイクロサービスごとに2つの実際のマイクロサービスインスタンス（サーバー障害の場合、およびダウンタイムなしでデプロイするため）、およびマイクロサービスごとに2つのデータベースサービスインスタンス（サーバー障害などの場合）。

これは、率直に言って、少しばかげているようです。16〜20台のサーバーでシンプルなAPIを実行しますが、現実的なプロジェクトにはおそらく4〜5以上のサービスがあることに留意してください。これを説明する基本的な概念がありませんか？

回答中に役立ついくつかのこと：

• 私はこのプロジェクトの唯一の開発者であり、近い将来になります。
• Node.jsとMongoDBを使用していますが、言語に依存しない回答に興味があります。答えは、間違ったテクノロジを使用しているだけかもしれません。

3つのオプションのうち、最初の（単一の共有データベース）と3番目（「データベースサービス」）が最も一般的です。

1つ目は統合データベースと呼ばれます。これは通常、マイクロサービスアーキテクチャでは適切なソリューションとは見なされていません。サービスにカップリングを追加します。また、1つのサービスが他のサービスを単にバイパスし、データベースに直接クエリすることも非常に簡単になります。データベースレベルで適用されていないアプリケーションレベルで提供されるデータの整合性または検証が失われる可能性があります。

3番目のアイデアは、アプリケーションデータベースと呼ばれます。そのとおりです。APIレベルでサービス間の疎結合を強制でき、データベースレベルでサービスをより簡単にスケーリングできます。また、各サービスのテクノロジーやその他の実装の詳細を変更できるように、基礎となるデータベーステクノロジーを各サービスに適したものに簡単に置き換えることができます。非常に柔軟です。

ただし、中間的な解決策を提案します。

すべてのマイクロサービスのデータベースサービスを立ち上げる代わりに、すべてのサービスのスキーマを立ち上げます。複数のデータベーステクノロジを使用している場合は、少し異なる方法で分割する必要があるかもしれませんが、実行しているデータベースサーバーの数を最小限に抑えることをお勧めしますが、必要になったとき。データベースが独自のスキーマにアクセスすることのみを許可する限り、アプリケーションデータベースの利点がありますが、すべてのアプリケーションまたはサービスに存在するデータベースサーバーのオーバーヘッドはありません。

しかし、ソロ開発者として、私はこの時点でマイクロサービスの概念全体に挑戦します-マーティン・ファウラーはモノリス・ファーストとマイクロサービス・プレミアムについて書き、サイモン・ブラウンはモジュラー・モノリスについて話し、DHHはマジェスティック・モノリスについて話します。あなたのモノリスがどれだけうまく整理されているかはわかりませんが、リファクタリングして整理します。コンポーネントを特定し、それらを簡単に分離してサービスに簡単に抽出します。データベース構造についても同じことが言えます。サービスへのリファクタリングをサポートできる、優れたクリーンなコンポーネントベースのアーキテクチャに焦点を当てます。マイクロサービスは、1人の開発者が運用で構築してサポートするために多くのオーバーヘッドを追加します。ただし、実際にシステムの一部をスケーリングする必要がある場合は、監視およびレポートシステムを使用してボトルネックを特定し、サービスに抽出し、必要に応じてスケーリングします。

各マイクロサービスには独自のデータベースサービスがあります-疎結合と水平スケーリングの利点を保持するため、これは最も有望であると思われます（冗長データベースコピーの使用および/または複数でのシャーディング）

同意する。第三の選択肢はマイクロサービスのための自然な選択です。マイクロサービスが本当に独立している（分散モノリスの一部ではない）ことを意図している場合、通常、それぞれにデータベースがあります。

[...]マイクロサービスごとに2つの実際のマイクロサービスインスタンス（サーバー障害の場合、およびダウンタイムなしでデプロイする場合）、およびマイクロサービスごとに2つのデータベースサービスインスタンス（サーバー障害などの場合）。

ロードバランスを取りたい場合は、実行中のマイクロサービスの量について正しいです。既に説明したように、4つのマイクロサービスを計画している場合は、各マイクロサービスの少なくとも2つのインスタンス（合計8つ）を準備する必要があります。

しかし、マイクロサービスごとに2つのデータベースはありますか？これは本当に疑問です。マイクロサービスが関与するビジネス上の問題に関する詳細はわかりませんが、データベースの冗長性があるため、ほとんどの製品/プロジェクトにとって非常に多くなります。適切なバックアップを備えた単一のデータベースから開始し、インフラストラクチャの複雑さを（少なくとも最初は）最小限に抑えることをお勧めします。

これは、率直に言って、少しばかげているようです。16〜20台のサーバーでシンプルなAPIを実行しますが、現実的なプロジェクトにはおそらく4〜5以上のサービスがあることに留意してください。これを説明する基本的な概念がありませんか？

単純な APIの場合、この数値は一致しません。「マイクロサービスファースト」トラップのいずれかに該当しない場合は注意してください。

マイクロサービスは、おそらく極端な形のサービス指向アーキテクチャの一形態です。それらの一般的な目的は、結合を減らし、独立した開発と展開を可能にすることです。

非常に大まかに言えば、アーキテクチャ用語で言えば、マイクロサービスは論理レベルで適用される用語です。マイクロサービスは互いに論理的に分離されています。この観点から、マイクロサービスはそれぞれ独自のストレージを所有して提供する必要があり、他のマイクロサービスのストレージから切り離す必要があります。マイクロサービスの場合、このストレージの独立性は、モジュール性と疎結合の目標の鍵となります。

アーキテクチャの観点から見ると、水平スケーリングはより低いレベルで、実装に近く、たとえば物理レベルで適用されます。このレベルでは、マイクロサービスを実装しています。この単一のマイクロサービスを、内部的に、水平方向にスケーラブルなステートレスコンポーネントと、すべてのステートレスコンポーネントで共有されるステートフルコンポーネントに分解できます。  しかし、ステートレス部分だけをマイクロサービス自体と混同しないようにしましょう。

したがって、個々のマイクロサービスについて話しているとき、私たちは論理レベルでAPIと分離された責任と分離された開発/展開サイクルについて話します。また、水平スケーリングについては、物理レベルで（単一の）マイクロサービスの実装と、ステートレスおよびステートフルコンポーネントへの分解について話します。

複数のマイクロサービスを実装する場合、ステートフルコンポーネントにデータベーステクノロジーを再利用する選択肢があります。

• マイクロサービスごとに個別のデータベース
• 共有データベース：
  • マイクロサービスごとの個別/プライベートスキーマ
  • マイクロサービスごとの個別/プライベートテーブル

詳細はこちらをご覧ください。

すべてのマイクロサービスで共有される単一のデータベースサービス-これは、疎結合の利点を完全に排除するようです。

同意して、テーブルの行と列を共有することを意味する場合、それは実際にはマイクロサービスではありません。

思考プロセスにおいて、マイクロサービスのステートフルおよびステートレスコンポーネントの物理的概念からマイクロサービスの論理的概念を切り離すことができれば、共有の効率を維持しながら、マイクロサービスによって提供される疎結合を簡単に実現できる可能性があります。データベース。

一般に、マイクロサービスとステートフルな永続性について書かれたかなりの量があります。こちらも参照してください。

まあ、私はこのスレッドのすべての投稿を読んで、質問と混同していることを伝えることができます：それは、データベースとサーバーとデータアクセスサービス（DBサービス）を備えたサービスとマイクロサービス（MS）を混ぜています...

MSがステートレスな方法で1つの最も単純なタスクを解決する独立した（展開可能な）コンポーネントである場合、必要なデータベースは何ですか？複数の最も単純なサブタスク（MS？）を一緒に解決する必要がある、より複雑なタスクを解決する場合、それはまだMSですか？SOAでは、オーケストレーションサービスと呼ばれます。「プロセス」を実装し、MS呼び出しを調整します。したがって、その状態を保持する必要があり（すべてのオーケストレーション/オーガナイザー/作曲者などがステートフルです）、個人データストアが必要です。

ただし、データベースについてではなく、データベースアクセスMS /サービスについて説明しますが、これはまったく別の問題です。MSは、社内で（社内で動作するアプリケーションではなく）収集されたデータを必要とする場合があり、そのAPI /インターフェイスを介して別のMSにデータを要求することはできません。これは最も一般的で現実的なシナリオです。また、同じまたは異なるアプリケーションの別のMSがこのデータを必要とするか、変更することさえあります。はい、MSが登場する前のように、彼らはデータを求めて競争します。

なぜ私たちはよく知られ、開いている「ドア」をクラッシュさせているのですか？MSと通常の自己永続オブジェクトのこの点に関する違いは何ですか？とにかく（柔軟性と構成可能性の目的で）データアクセスサービス（DAS）を使用する必要がある場合、MSに個別のデータベースが必要なのはなぜですか？DASは、データベースへの物理的な接続に関する認識からビジネスタスクでMSを保護することを忘れないでください。データベースが固定されていない複数のアプリケーションに自由に参加するために、MSが保持すべきこの疎結合と柔軟性。