以下のシナリオで疎結合を実現するにはどうすればよいですか。
N個のマイクロサービス(Callerと呼びましょう)では、さまざまなコントラクトで実行されるロジックまたはビジネス(Workerと呼びましょう)が必要です。コントラクトは異なりますが、ロジックはほぼ同じであり、DBワーカーに集中管理されて格納されているデータに対する作業は、各呼び出し元のマイクロサービスに関して少し進化する可能性があります。
また、Workerには常に同じデータを使用できることを付け加えておきます。
だから、私は考慮すべき以下のオプションについて考えています:
また、どのタイプのコミュニケーションがKafka vs Restに適合し、どのようなシナリオになりますか?
これが私の理解からあなたが言ったことの履歴書です(検証してください):
これらの要件をサポートするために、特定のマイクロサービスが消費者が必要とするデータを管理することを提案します。さらに、この新しいプロデューサーは、コンシューマーに必要なビジネスロジックを維持します。
3つの質問に答える前に、マイクロサービスは非常に分離されているため、アンチマイクロサービスになる可能性があることを覚えておいてください。たとえば、ユーザーの名前を維持するためだけに特定のテクノロジースタックを使用して新しいアプリケーションを作成し、別のユーザーが個人情報を維持することは理想的ではありません。したがって、技術的な観点から問題を見るのではなく、ビジネスの側面を取り入れてください。
小さなロジック変更があり、データを維持するマイクロサービスからデータを取得する可能性のあるすべての発信者マイクロサービスにロジック(ビジネス)が追加されていますか?
ワーカーの集中型ロジックを備えた単一のマイクロサービスから複数のエンドポイント(個別のコントラクトがある)を作成してデータを維持しますか?
単一のエンドポイントがあり、複数のマイクロサービス契約をマージし、ワーカーの集中ロジックを使用してデータを維持していますか?
全体として、呼び出し側ごとに必要なビジネスロジックを正確に再確認してください。ワーカーのみがこのロジックを適用できる場合は、異なるエンドポイント(コントラクト)を使用します。ロジックが呼び出し元に固有である場合は、ロジックを呼び出し元に移動し、エンドポイントを可能な限り単純に保ちます。その結果、そのエンドポイントは、新しい呼び出し元がワーカーからの新しいAPIを必要とするまで再利用できます。
REST vs Kafka
あなたの最後の質問については、これらを考慮してください:
アプリケーションで何かを通知および/または通知する必要がある場合にのみ、パブリッシャーサブスクライバーパターンを使用します。あなたの場合、発信者がKafkaを使用している場合、発信者は基本的にワーカーからのデータの更新通知を待機します。それはまた、彼らが彼らの側でデータを永続化する必要があることを意味します。呼び出し元とワーカーの両方が同じシステムにある場合、これは不必要な複雑さです(データベースからデータを読み取るだけの場合)。