マイクロサービスとデータストレージ
モノリシックREST APIをマイクロサービスアーキテクチャに移動することを検討しています。データストレージについて少し混乱しています。それを見るとわかるように、マイクロサービスの利点のいくつかは次のとおりです。
- 水平方向にスケーラブル-負荷やサーバーのダウンに対処するために、マイクロサービスの複数の冗長コピーを実行できます。
- 疎結合-他を変更せずにマイクロサービスの内部実装を変更できます。また、それらを個別にデプロイして変更できます...
私の問題はデータストレージにあります。私が見るように、いくつかのオプションがあります：
- すべてのマイクロサービスで共有される単一のデータベースサービス-これは、疎結合の利点を完全に排除するようです。
- 各マイクロサービスにローカルにインストールされたデータベースインスタンス-これを水平方向にスケーリングする方法が見当たらないため、これはオプションではないと思います。
- 各マイクロサービスには独自のデータベースサービスがあります-疎結合と水平スケーリング（冗長データベースコピーや複数のシャーディングを使用）の利点を維持するため、これは最も有望です。
私にとって、3番目のオプションは唯一のオプションのようですが、それは私にとって信じられないほど重いものであり、非常に高度に設計されたソリューションです。私がそれを正しく理解している場合、4〜5のマイクロサービスを使用する単純なアプリケーションの場合、16〜20のサーバーを実行する必要があります-マイクロサービスごとに2つの実際のマイクロサービスインスタンス（サーバー障害の場合、およびダウンタイムなしで展開するため）、およびマイクロサービスごとに2つのデータベースサービスインスタンス（サーバー障害などの場合）。
これは、率直に言って、少しばかげているようです。 16〜20台のサーバーでシンプルなAPIを実行します。現実的なプロジェクトには4〜5を超えるサービスがあると思いますか。これを説明する欠けている基本的な概念はありますか？
回答中に役立ついくつかのこと：
- 私はこのプロジェクトの唯一の開発者であり、当面は将来の予定です。
- Node.jsとMongoDBを使用していますが、言語に依存しない答えに興味があります。答えは、間違ったテクノロジーを使用しているだけかもしれません。
3つのオプションのうち、最初のオプション（単一の共有データベース）と3番目のオプション（「データベースサービス」）が最も一般的です。
1つ目は 統合データベース と呼ばれます。これは一般に、マイクロサービスアーキテクチャでは優れたソリューションとは見なされていません。サービスにカップリングを追加します。また、1つのサービスが他のサービスをバイパスしてデータベースに直接クエリを実行することも非常に簡単になります。データベースレベルで適用されていないアプリケーションレベルによって提供されるあらゆる種類のデータの整合性または検証を失う可能性があります。
3番目のアイデアは アプリケーションデータベース と呼ばれます。そして、あなたの言うとおりです。これにより、サービス間のAPIレベルで疎結合を適用でき、データベースレベルでサービスをより簡単にスケーリングできます。また、各サービスのテクノロジーやその他の実装の詳細を変更できるのと同じように、基盤となるデータベーステクノロジーを各サービスで適切なものに置き換えるのが容易になります。非常に柔軟です。
ただし、中間的な解決策を提案します。
すべてのマイクロサービスのデータベースサービスを立ち上げる代わりに、すべてのサービスのスキーマを立ち上げます。複数のデータベーステクノロジを使用している場合は、少し異なる方法で分割する必要があるかもしれませんが、実行しているデータベースサーバーの数を最小限に抑えることをお勧めしますが、サービスを独自のデータベースサーバーに簡単に分割できる場合は、必要になったとき。データベースに独自のスキーマへのアクセスのみを許可する限り、アプリケーションデータベースの利点がありますが、すべてのアプリケーションまたはサービスに存在するデータベースサーバーのオーバーヘッドはありません。
しかし、ソロ開発者として、私はこの時点でマイクロサービスの概念全体に挑戦します-マーティンファウラーは モノリスファースト と マイクロサービスプレミアム について書いています、サイモンブラウンは話します モジュラーモノリス について、およびDHHは マジェスティックモノリス について話します。あなたのモノリスがどれだけうまく整理されているかはわかりませんが、リファクタリングして整理します。コンポーネントを特定し、それらを明確に分離して、サービスに断片を簡単に抽出します。データベース構造についても同様です。サービスへのリファクタリングをサポートできる、コンポーネントベースの優れたクリーンなアーキテクチャに焦点を当てます。マイクロサービスは、1人の開発者がオペレーションを構築してサポートするために多くのオーバーヘッドを追加します。ただし、システムの一部を実際に拡張する必要がある場合は、監視およびレポートシステムを使用してボトルネックを特定し、サービスに抽出して、必要に応じて拡張します。
各マイクロサービスには独自のデータベースサービスがあります。これは、疎結合と水平スケーリング（冗長なデータベースコピーや複数のシャーディングを使用）の利点を維持するため、最も有望です。
同意します。 thirdオプションは、マイクロサービスの自然な選択です。マイクロサービスが本当に独立している（そして 分散モノリス の一部ではない）ことを意図している場合、それぞれがデータベースを持っているのは正常です。
[...]マイクロサービスごとの2つの実際のマイクロサービスインスタンス（サーバー障害の場合、およびダウンタイムなしのデプロイ用）、およびマイクロサービスごとの2つのデータベースサービスインスタンス（サーバー障害の場合など）。
負荷分散が必要な場合は、実行しているマイクロサービスの量について適切です。すでに説明したように、4つのマイクロサービスを計画している場合は、各マイクロサービスのインスタンスを少なくとも2つ（合計8つ）準備する必要があります。
しかし、マイクロサービスごとに2つのデータベースがあるのでしょうか。これは本当に疑わしいです。私はあなたのマイクロサービスが参加するビジネス問題についての詳細を知りませんが、データベースの冗長性があり、ほとんどの製品/プロジェクトにとって非常に多くあります。適切なバックアップを備えた1つのデータベースから始めて、インフラストラクチャの複雑さを（少なくとも最初は）最小限に抑えることをお勧めします。
これは、率直に言って、少しばかげているようです。 16〜20台のサーバーでシンプルなAPIを実行します。現実的なプロジェクトには4〜5を超えるサービスがあると思いますか。これを説明する欠けている基本的な概念はありますか？
simpleAPIの場合、この数値は一致しません。 「マイクロサービスファースト」 traps のいずれにも該当しない場合は注意してください。
Microservices は、おそらく極端なサービス指向アーキテクチャの形式です。それらの一般的な目的は、結合を減らし、独立した開発と展開を可能にすることです。
アーキテクチャの用語で非常に大まかに言えば、マイクロサービスは、たとえば論理レベルで適用される用語です。マイクロサービスは互いに論理的に分離されています。この観点から見ると、マイクロサービスはそれぞれ独自のストレージを所有および提供する必要があり、他のマイクロサービスのストレージから分離する必要があります。マイクロサービスの場合、このストレージの独立性は、モジュール化と疎結合の目標にとって重要です。
アーキテクチャの観点からは、水平スケーリングは、物理レベルなど、実装に近い下位レベルで適用されます。このレベルでは、マイクロサービスを実装しており、この単一のマイクロサービスを内部的に、水平方向にスケーラブルなステートレスコンポーネントと、すべてのステートレスコンポーネントで共有されるステートフルコンポーネントに分解できます。 しかし、ステートレスな部分だけをマイクロサービス自体と混同しないでください。
したがって、個々のマイクロサービスについて話すときは、論理レベルでAPIについて話し、責任と分離した開発/デプロイメントサイクルを分離します。そして、水平スケーリングについて話すときは、物理レベルで（単一の）マイクロサービスの実装と、ステートレスおよびステートフルコンポーネントへのその分解について話しています。
複数のマイクロサービスを実装する場合、データベーステクノロジーをステートフルコンポーネントに再利用するための選択肢があります。
- マイクロサービスごとに個別のデータベース
- 共有データベース：
- マイクロサービスごとの個別/プライベートスキーマ
- マイクロサービスごとの個別/プライベートテーブル
詳細はこちら こちら 。
すべてのマイクロサービスで共有される単一のデータベースサービス-これは、疎結合の利点を完全に排除するようです。
同意しますが、テーブルの行と列を共有するつもりなら、それは実際にはマイクロサービスではありません。
思考プロセスにおいて、マイクロサービスの論理的な概念を、マイクロサービスのステートフルおよびステートレスコンポーネントのより物理的な概念から切り離すことができれば、共有の効率を維持しながら、マイクロサービスによって提供される疎結合を実現する方が簡単であると感じるかもしれません。データベース。
一般的に、マイクロサービスとステートフルな永続性についてはかなりの量が書かれています。 ここ も参照してください。