多個SignalR集線器類型在一個背板上 - 優點/缺點/可擴展性？

Question

最近，我們嘗試使用SQL背板將一些Web應用上的SignalR更改為在Web場中工作。

當我探索它是如何工作的時候，我們可以調整它的不同方式的數量正在增加（朝向大多數可擴展性的目標，最少的失敗點）。

目前，每個應用程序使用SignalR來支持數據庫中記錄的輪詢驅動的更改廣播。

關於在所有應用上為所有SignalR實例使用一個背板的基本假設/觀察：

1. 所有具有一個公共背板的集線器和集線器實例（所有類型）僅位於一個消息總線上。

2. 所有中心實例基本上都“合並”其客戶端池。 中心實例實際上無法知道他們擁有多少客戶端。

3. 來自某些AppB_Hub的消息流量可以在AppA的跟蹤輸出中看到。 我假設如果AppA有一個名稱相同的中心，他們會發生沖突 - 或者只要他們意識到他們將共享客戶端。

問題/顧慮/未知數：

1. 不同的集線器（不同的集線器類型，可能是不同的組件）可以很好地運行嗎？ 即一個上的消息和呼叫是否會干擾另一個？ 在什么情況下？
2. 這一切都基於命名嗎？ 即如果AppAHub和AppBHub想要很好地玩，他們需要確保他們的方法和回調名稱不同嗎？ 或者只要集線器名稱不同，它們是否已經不同？
3. 假設它“足夠安全”，它是否可以“擴展”以使每個應用程序篩選彼此的應用程序消息。 在某種程度上有一個單獨的背板是否值得。 是否值得小規模？ 例如：2種類型的集線器，每種集線器2個實例。
4. 或者，AppAHub和AppBHub可能只是兩個接口進入同一個集線器，因此AppA可能會隨時了解AppB，反之亦然。 我想知道如果我們知道他們都會被送到一切，他們是否有任何一點是獨立的樞紐。 或者這會為AppA激活一些不可避免的額外成本，因為它更明確地“關注”AppB消息嗎？

Answer 1

集線器是獨立的，所以不同的集線器運行良好，如果你把它們放在不同的組件中並想要互相訪問，請參見此處

名稱和回調基於客戶端連接到哪個集線器，如果客戶端連接到一個或多個不同的集線器（如果每個客戶端僅連接到一個集線器），則它們應該是唯一的用於調試目的

對於性能計數器，請參閱此處 ，Microsoft在其天藍色Web服務中使用signlR背板，因此它確實可以擴展，但基准數據上沒有發布白皮書

如果你想使用接口方法IAppAHub和IAppBHub，你的java腳本客戶端可以調用IAppAHub和IAppBHub方法，如果你想限制你可以通過角色來調用它，你應該調查一下SignalR securty