0

Web API を構築し、nServiceBus を使用してすべての非同期および長時間実行プロセスの内部でメッセージングを行っています。

質問は、新しいバージョンの API をスピンオフするときに、新しいキューのセットを使用する必要があるかどうかです。

同様に、API バージョン 1 の場合、

  • blobstore.v1.inbound
  • blobstore.v1.outbound
  • blobstore.v1.timeout
  • blobstore.v1.audit

API バージョン 2 の場合、

  • blobstore.v2.inbound
  • blobstore.v2.outbound
  • blobstore.v2.timeout
  • blobstore.v2.audit

それとも、複数のメッセージ形式とハンドラーで同じキューのセットを使用するように努めるべきでしょうか (要件の変更とメッセージ形式の進化を想定して)。

アーキテクチャの観点から、長期的には長所と短所を理解しようとしています。個別のキュー セットを使用すると、互換性や社交性を気にすることなく、さまざまな API バージョンを分離して構築、デプロイ、および管理できる柔軟性が得られます。

個人的には後者に傾いていますが、互換性とアップグレードに関する課題は明確に理解されていません。

過去に同様のシナリオに対処したことがある場合は、経験、考え、提案、および推奨事項を共有してください。

あなたの時間は大歓迎です!

4

2 に答える 2

0

異なるバージョンのメッセージをサポートするために異なるキューのセットを使用するか、単一のキューを使用するかの決定は、メッセージ間の違いの程度によって異なります。バージョン管理のサンプルV2メッセージは、インターフェイスの継承で表すことができるV1メッセージの純粋な拡張です。V1メッセージの加入者は、V1メッセージの適切なスーパーセットであるV2メッセージを受信できます。この場合、同じキューを維持し、必要に応じてサブスクライバーのみを更新するのが理にかなっています。メッセージが大幅に異なる場合は、2番目のキューのセットを展開する方が簡単な場合があります。これには、あなたが説明した利点、つまり分離があります。依存するコンポーネントを台無しにすることを心配する必要はありません。ただし、キューに依存する可能性のあるすべてのことを考慮する必要があるため、これはシステムに大きな影響を与えます。V2の展開を完了するには、複数のエンドポイントとサービスを一度に展開する必要がある場合があります。

于 2012-08-28T23:16:50.010 に答える
0

リリースの頻度が高いほど、バージョンごとのキュー戦略は適切ではなくなり、下位互換性が (構造と動作の両方で) 重要になります。

于 2012-09-02T09:16:32.507 に答える