最近、いくつかの Web アプリで SignalR を変更して、SQL バックプレーンを使用して Web ファームの状況で動作するようにしました。
微調整できるさまざまな方法の数は、それがどのように機能するか (スケーラビリティを最大化し、障害点を最小化するという目標に向かって) を調査するにつれて、頭の中で増えています。
現在、SignalR は各アプリで使用され、データベースに記録されている変更のポーリング駆動型ブロードキャストをサポートしています。
すべてのアプリのすべての SignalR インスタンスに対して 1 つのバックプレーンを使用することに関する重要な前提/観察:
1 つの共通バックプレーンを持つすべてのハブとハブ インスタンス (すべてのタイプ) は、1 つのメッセージバス上で動作します。
すべてのハブ インスタンスは、基本的にクライアント プールを「マージ」します。ハブ インスタンスは、所有しているクライアントの数を実際には認識できません。
一部の AppB_Hub からのメッセージ トラフィックは、AppA からのトレース出力で確認できます。もし AppA が同じ名前のハブを持っていたら、競合するだろうし、クライアントを共有していることに気付いていない限り、そうではないだろう。
質問/懸念/不明:
- 異なるハブ (異なるハブ タイプ、おそらく異なるアセンブリ) は適切に再生されますか? つまり、一方のメッセージと通話が他方に干渉することはありますか? どんな状況で？
- それはすべてネーミングに基づいていますか？つまり、AppAHub と AppBHub がうまくプレイしたい場合、メソッドとカルバックの名前が異なることを確認する必要がありますか? それとも、ハブ名が異なる限り、それらはすでに異なっていますか?
- 「十分に安全」であると仮定すると、各アプリが他のアプリのメッセージをふるいにかけるために「スケールアウト」しますか。ある程度の規模で別のバックプレーンを用意する価値はありますか。小規模でやる価値ある？例: 2 種類のハブ、それぞれの 2 つのインスタンス。
- あるいは、AppAHub と AppBHub が実際には同じハブへの 2 つのインターフェイスにすぎない可能性があるため、AppA は AppB に関する情報を保持できる可能性があり、その逆も同様です。それらすべてにすべてが供給されることがわかっている場合、それらが別々のハブであることに何か意味があるのだろうか。または、AppBメッセージをより明示的に「気にする」ようになったため、AppAの避けられない追加コストが発生しますか?