マイクロサービス-分散インメモリキャッシュを介してデータを共有しますか？
私はマイクロサービスとRedisのような共有メモリ内データベースの両方にかなり慣れていません。
マイクロサービス指向のアーキテクチャーでデータの複製、共有、所有権の課題に対処するために2つを組み合わせるのは良い考えでしょうか。
別のサービスデータにアクセスする必要があるマイクロサービスが、読み取り専用のスレーブノードとしてクラスターに参加するだけでよいソリューションではないでしょうか。
この方法でも、所有権（および書き込みアクセス）は完全に個々のサービス内にありますが、データへのアクセスはすべてのスレーブで非常に高速であり、マスターがダウンしても、ある程度のサービスを提供し続けることができます奴隷から。
明らかに、データの量が制限要因になる可能性がありますが、それ以外に、このアプローチが広く使用されていないように見える理由は何ですか？
複数のサービスに単一のデータベースを使用するのと同じように、あなたが説明するアプローチは、サービス間の強い結合を引き起こします。たとえば、1つのサービスのデータモデルを変更するには、それに応じて他のサービスのモデルを変更する必要があります。これは、開発とデプロイメントの両方が結合され、実際のマイクロサービスが複数のプロセスを持つモノリスになることを意味します。サービスの独立した開発と展開は、マイクロサービスアーキテクチャを使用する重要な理由の1つであるため、それらがなければ、モノリスを構築することもできます。
ほとんどすべての優れた実践と同様に、もちろん、今言ったことには例外があります。限られた範囲で使用すると、共有キャッシュはパフォーマンスの大幅な向上をもたらす可能性があり、サービスの疎結合を無視することは理にかなっています。合理的な状況とは、たとえば、範囲が狭く、いずれにせよ密接に協力する必要のある、1つのチームによって開発された2つのサービスなどです。キャッシュをデータで満たすサービスと、そのデータを読み取る別のサービスを考えてみてください。この場合、非常に強い結合があり、アーキテクチャとメンテナンスの観点からはあまりよくありませんが、共有キャッシュはパフォーマンス上の利点があるため、相応の妥協案になる可能性があります。しかし、一般的なケースでは、そのような共有キャッシュは悪い考えです（上記を参照）。