2

現時点で私が取り組んでいることの簡単な要約：

関連するメタデータ/フィルターを使用して、1 つのトピックと N 個のトピックが必要な場合でこれを実行できるかどうかを決定しています。

私はほとんど3個持っています。現場のユニットが接続するソケット サーバー (ワーカー ロール)、Azure Service Bus メッセージング、そして最後に Web アプリ。ユーザーは、Web アプリを介してデバイスに送信されるコマンドをキューに入れることができますが、デバイスがオンラインになるまでメッセージをキューに保持できる必要があり、デバイスはすべてのメッセージを取得します。迷っているところです...

私は当初、キューに入れられたメッセージの Web アプリで 1 から 9999 のトピックを動的に作成する方法に沿って作業していました (作成できるトピックの上限は 10,000 であるため、シリアルの最後の 4 文字を使用します)。その後、メタデータ内にデバイスの完全なシリアルが含まれます。このようにして、デバイスがソケット サーバーに接続するときに、特定のルールで N 個のサブスクリプションを作成し、デバイスが切断されたときにそれらをシャットダウンできます。

しかし、トピックを 1 つだけにして、すべてのロジックをメタデータ内に配置できるかどうか疑問に思っています。

私はサービスバスを使用したSQLFiltersに非常に慣れていないので、どんな助けでも大歓迎です:)

4

1 に答える 1

3

良い質問！まず第一に、IoT シナリオ向けに最適化された「キュー」のようなサービスである IoT Hub を使用することをお勧めします。これには、管理とコマンドが含まれます。または Event Hubs ですが、コマンド パターンはあまり最適化されていません。

1) イベントハブ

2) IoT ハブ

1 つ目は、よりイベント指向のシナリオ用です。つまり、バックエンドからデバイスの管理を実装することは、イベント ハブではより複雑になり、IoT ハブではそれほど複雑ではなくなります。

Service Bus は優れたサービスですが、リストされているサービスはより IoT 指向であるため、これらのサービスを確認することを強くお勧めします。

アーキテクチャの観点から、Microsoft は最近 IoT リファレンス アーキテクチャのホワイトペーパーを公開しました。こちらからダウンロードできます。Microsoft の観点から、Azure + IoT プロジェクトに使用できる推奨事項、サービス、ベスト プラクティスなどが含まれています。

もう 1 つの役立つリソースはhttp://azureiotsuite.comです。これは、実装されたリファレンス IoT アーキテクチャです。したがって、[作成] をクリックすると、Azure サブスクリプションに 2 つの参照アーキテクチャ (リモート監視または予知保全) のいずれかが含まれ、すべてのフローを確認できるようになります。

したがって、IoT 分野では、これらのワークロード向けに最適化されたサービスは、最初に最適化されていないサービスよりも優れたパフォーマンスを発揮するはずなので、SB トピック/キューの代わりに IoT/イベント ハブの使用を検討することをお勧めします。

次に、デバイスを Worker ロールに接続する方法を指定していませんでした。そのため、 SuperSocketと呼ばれる優れたライブラリがあることがわかりました。

したがって、私が見るように、ソリューション アーキテクチャは次のようになります。

デバイス 2 クラウド:

デバイス => ゲートウェイ (SuperSocket など) || IoT Hub => デバイス レジストリ (上記のリンクを参照)

クラウド 2 デバイス:

ユーザー インターフェイス => デバイスが登録されている IoT Hub => デバイス

デバイス レジストリは、ID などを転送するよりも IoT フローを実行するためのより便利な方法です。エンティティの動的作成にはいくつかの欠点があります。たとえば、作成コマンドがタイムアウト エラーを返す場合を想像してください。最適化されたサービスを使用する方が良いと思います。

デバイスがオフラインの場合、キューはポーリングされません。メッセージが停止する前に、ある程度の保持期間があります。これが組み込みのメカニズムです。

于 2016-05-17T11:59:32.487 に答える