私が検索したものの、直接的な答えが見つからないのは次のとおりです。
特定のサービスについて、そのサービスの 2 つのインスタンスが 2 台のマシンにデプロイされている場合、それらは同じ永続ストアを共有していますか、それとも何らかの同期メカニズム (マスター/スレーブ、クラスタリング) を備えた個別のストアを持っていますか?
たとえば、MySQL に裏打ちされた OrderService があります。多くの注文を受けているので、このサービスをスケールアップする必要があるため、2 つ目の OrderService をデプロイします。そのデータはどこから来たのですか？
ばかげているように聞こえるかもしれませんが、私には、すべての議論が、サービスとデータベースがパッケージ化されたユニットであり、一緒にデプロイされているように思えます。しかし、2 番目のサービスを展開するとどうなるかについて言及している議論はほとんどありません。
コメントするには長すぎるため、これを回答として投稿します。
マイクロサービスは自己完結型のコンポーネントであるため、独自のデータを管理します。データを取得したい場合は、サービス API と対話する必要があります。これは主にさまざまな種類のサービスに当てはまります (つまり、さまざまな種類のビジネス機能を提供するサービス間でデータベースを共有しません。データベースを介してヒープでサービスを結合すると、より多くのものを簡単に結合できるため、これは悪い習慣です。通常は API レベルで行われますが、データベースを介して行う方が便利です => コンポーネント化を失うリスクがあります)。
しかし、同じ種類のサービスがある場合、あなたが述べたように、データベースを共有するか、各サービスに独自のデータベースを含めるかという 2 つの明白な選択肢があります。
ここで、どのソリューションを選択したかを自問する必要があります。
OrderServiceの注文は本当に単独で機能しますか? それとも、他のアプリケーションからのレポートやアクセスのために、すべての注文を同じデータベースに保存する必要がありますか?私が言おうとしているのは、この種の状況では答えは「場合による」ということです。そして、私たち技術オタクが分散/スケーラビリティ/アーキテクチャの旅に乗り出す前に忘れがちなことは、ビジネスと話をすることです。多くの場合、ビジネスは、ある程度の矛盾、最適化されていないプロセス、または 1 つではなく複数の場所でのデータ検索に対処できます (つまり、重要だと考えていることが必ずしもビジネスにとって重要であるとは限りません)。だから彼らと話して、彼らが何を許容できるか見てみましょう。高度に分散可能なシステムの構築に多額の投資をするよりも、運用上の問題を解決する方が安上がりかもしれません。