マイクロサービスアーキテクチャの構築同じマイクロサービスのインスタンス間でのデータ共有の問題に直面しました。マイクロサービス：インスタンス単位またはマイクロサービス単位のデータソース？
私はマイクロサービスを持っています。そのサービスは大量のデータソースを使用しています。このサービスは非常に重く使用され、Load Balancerの背後に複数のインスタンスを隠す予定です。ここでは、これらのインスタンスが1つのデータベース（データベースがボトルネックになるか）または複数（インスタンスごとのデータソース）を使用するかどうかという疑問が生じます。 mSOAアーキテクチャとの私の経験では
、私が使用する
MULTIPLE（インスタンスごとにデータソース）
を見たことがありません。頻繁にロードする予定がある場合でも、最も一般的なDBはマルチスレッドアクセスをサポートしています。通常、DBシステムのボトルネック（または最も遅い部分）はディスクです。クラスタを数回スケールする必要がありました（クラウドにいる場合は比較的安いですが、スケーリングされたDBシステムを管理および実行するためにはスレッド数が増えるためスケーラビリティも問題になります）。 RDBMSの中には、ソート、ハッシュ、一時変数などのために、そのインスタンス上のすべてのDBが使用する一時DB（tempdb）を使用するものがあります。このtempdbファイルをマルチスレッド化して分割すると、tempdb全体的なサーバーのパフォーマンスが向上します。
私はOrchardで作業しているので、あるインスタンス上でのアクションが完全に（そしてタイムリーに）同期されていない場合、いくつかのコーナーケースがあると言います。これにより、正しい認証の後でさえ、リソースのアクセスが拒否される（イベントの登録直後）。
私はこれがあなたのアプリケーションサーバー用の適切な設計なので、DBクラスタを利用することにも適しているはずであるロードバランサの背後に
を複数のインスタンスを非表示にする予定。完全な答えを目指して - あなたは多くのサービスを持っており、すべてのDBからいくつかのデータのマイニングと分析ができるようにしたい場合に備えて、DWHと考えることができます。
あなたの実際のユースケースによって多くの違いがありますが、私はwrite-behindやwrite-backがあなたの解決策の一つかもしれないと思います。 ThisリンクはEhCacheのテクニックについて話していますが、私はその機能をサポートする他のキャッシュがあるはずだと思います。
マイクロサービスインスタンスごとに1つのデータベースインスタンスを持つことは、非常に珍しいアーキテクチャです。データベースの負荷が懸念される場合は、高いスループットのためにクラスタリングすることができますが、挿入によって負荷が大きくなることはありません。
データベースがボトルネックになることが懸念される場合は、NoSQLデータベースを調べることをお勧めします。 NoSQLデータベースは、高スループットのために拡張し、大量のデータをうまく処理するように設計されています。もちろん、複雑なデータモデルをうまく扱えないという欠点があります。