マイクロサービスと分離されたデータストレージモデル
マイクロサービスをしばらく見てきました。コンセプトは新しいものではありませんが、軽量な方法で伝達されます。だから、私はこれにとても興奮しています。
ただし、その答えが何であるかわからないという質問があります。各マイクロサービスは、独自の独立したデータストレージモデルを完全に備えているはずですか？以下を検討してください：
注：ここでの分離は読み取り/書き込みに基づいて行われるため、これはおそらく良い例ではありませんが、優れたアプローチはビジネス上の懸念を分離することです。
- products-write-service：製品の作成と編集を処理する責任があります。 MongoDBを理解し、そこにデータを書き込みます。
- products-lookup-service：IDによる製品の取得、カテゴリに基づく製品の基本的なリストの提供などを処理します。MongoDBを認識しており、そこからデータを読み取ります。
- products-search-service：製品の検索リクエストの処理を担当します。 Elasticsearchを認識し、そこからデータを読み取ります。
ここでは、3つのサービスの間に2つの個別のデータストレージ技術があります。しかしながら：
products-write-serviceとproducts-lookup-serviceは、同じデータストレージモデルで機能します。 2つのサービス間に試行された関係があります。- 結局のところ、
products-search-serviceが機能するためには、MongoDBからElasticsearchにETLを実行するプロセスが必要です。ある意味で、3つのマイクロサービスには独自のデータストレージモデルがありますが、これら2つのモデルを認識する中間プロセスがあります。
このモデルについてどう思いますか？ここで分離が完全に間違っていますか？
各サービスには独自のストレージがあるはずだと思います。それ以外の場合は、（マイクロ）サービスのポイントがありません。他のサービスと共有するストレージに制限されている場合、サービスをすぐに進化させることはできません。
読み取りロジックと書き込みロジックを別々のサービスに分割するのはなぜですか？ちょっと匂いがします。
サービスが複数のストレージを持つことができないということは何もありません。多分あなたは複数のストレージを持つ単一のサービスを探していますか？製品を更新すると、MongoDBとESの両方が同時に更新される可能性があります。
限られたドメイン知識に基づいて、2つのサービスをプロビジョニングします。MongoDBを使用した製品カタログとバックエンドとしてESを使用した製品検索です。サービス間でデータを転送する方法は別の質問です。
- あなたが提案したETL（両方のストレージを理解する必要があります-クイックとダーティ）
- ドメインイベント-Product Searchサービスは、Product Catalogサービスから発行されたイベントにサブスクライブできます（これが私の選択です）
- ストレージに直接移動する代わりにサービスのAPIを使用するバッチプロセス（おそらく1より優れていますが、より豊富なAPIの開発が必要になります）
さて、最良のアナロジーは、OOPでのカプセル化とデータ非表示です。
オブジェクトの状態を操作できる唯一の方法は、そのパブリックインターフェイスを使用することです。同様に、（マイクロ）サービスのデータを操作できる唯一の方法は、そのパブリックAPIを介する必要があります。そうは言っても、（マイクロ）サービスは、他のサービスがサブスクライブできるイベントであることがよくあります。
そのため、読み取りおよび書き込みサービスは、同じデータソースにアクセスするため、ほとんど同じ（マイクロ）サービスです。
では、古典的なSOAとの違いは何ですか？さて、ここではそれほど多くありません。しかし、製品カタログをさまざまな側面に分解し始めると、サービスは小さくなります。たとえば、古典的なSOAカスタマーサービスは、カスタマーに関連するすべてを格納しますが、マイクロサービスの世界では、アドレスは1つのサービスに行き、優先は1つ以上のサービスに行きます。
ただし、すべてのマイクロサービスにデータストアがあるわけではありません。一部のマイクロサービスはcomposition複数のサービス（enrich）からのデータを集約し、より使いやすいファサードを表すサービスです。また、一部のマイクロサービスはalgorithmをカプセル化し、そのようなデータはありません。おそらく一部の構成のみです。
お役に立てれば。