Azure中的SignalR：如何使用特定服務模式進行擴展？

我們正在開發一個使用SignalR推出一些業務重要指標的頻繁更新的系統。我們將有中等數量的連接客戶端，從50到1000的任何地方，每個客戶端都需要一個唯一的有效負載。Azure中的SignalR：如何使用特定服務模式進行擴展？

根據Damian Edwards給出的演講，我們的負載配置文件與特定服務器橫向擴展模式最匹配，我們基本上將客戶端分配到拓撲中的特定SignalR服務器，而不是使用背板。

關於這種工作方式的粗略僞代碼是，客戶端在我們的負載平衡API URL上進行GET操作，無論哪個服務器都會響應其URL，然後客戶端將SignalR客戶端庫配置爲使用該URL進行連接。

這看起來很像內部部署，但現在我們也計劃部署Azure。如果沒有這個要求，Azure網站非常適合。但是，這種模式要求我們可以可靠地識別Web站點中的單個實例，而我們無法做到這一點。

這是否違反了Azure網站提供的抽象？我們是否必須使用虛擬機或Web角色爲我們的每個SignalR實例獲取可靠，一致的IP或可尋址URL？或者還有另一種方式，人們已經將SignalR與Specific Server部署到Azure。

來源

2014-12-03 Peter M

使用虛擬機，它將成爲文件。基於同樣的講話，你正確地使用虛擬機，它會給你更多的控制權。嘗試使用由Azure分配的VM網址，例如companyname_node01.cloudapp.net – 2014-12-03 21:35:17

感謝Farrukh。正如您所說，看起來我們可以使用虛擬機或雲服務，並獲得一個定義的可尋址URL以與特定服務器設計一起使用 – 2014-12-05 13:55:43

默認的Azure網站行爲實際上可能適合您。

Azure網站在來自客戶端的第一個請求之後將親和標記保存爲cookie。該關聯標記可確保將來自該客戶端的所有未來請求都路由到該網站的同一實例。

如果你真的想出於某種原因自己處理負載均衡，那也是可以的。有一個API可以讓你獲得所有站點實例的相關令牌。

參見此處瞭解詳情：http://blog.amitapple.com/post/2014/03/access-specific-instance/#.VH-KOHl0xUY

來源

2014-12-03 22:04:50

Zain，感謝關於親和性標記的信息。聽起來似乎合理，但我們對完全依靠親和力標記表示謹慎。看起來像Azure實例內負載平衡的實現細節可能會在我們的下面改變。 – 2014-12-05 13:58:03

@PeterM我的主要觀點是，你想要的是Azure網站的默認行爲，並且這是未來不太可能改變的事情（太多人依賴於該行爲來改變）。我可以看到，如果您自己直接處理親和標記，可能會發現它更具風險，但如果您忽略它作爲幕後實現細節並瞭解默認行爲爲您提供了所需內容，則會獲得更穩定情況。 – 2014-12-05 17:38:50

感謝您的澄清。在設計我們的內部部署系統時，通常我們避免依賴於粘性會話，但正如您所說的，或許我們會重新考慮Azure。 – 2014-12-05 18:40:59

Azure中的SignalR：如何使用特定服務模式進行擴展？

回答

相關問題