Szolgáltatás mód az Azure SignalR Szolgáltatásban
A szolgáltatás mód fontos fogalom az Azure SignalR Szolgáltatásban. A SignalR szolgáltatás jelenleg három szolgáltatásmódot támogat: alapértelmezett, kiszolgáló nélküli és klasszikus. A SignalR szolgáltatás erőforrása minden módban másképp fog viselkedni. Ebben a cikkben megtudhatja, hogyan választhatja ki a megfelelő szolgáltatási módot a forgatókönyve alapján.
A szolgáltatás mód beállítása
Amikor új SignalR-erőforrást hoz létre az Azure Portalon, meg kell adnia egy szolgáltatásmódot.
A szolgáltatás módot később a Beállítások menüben is módosíthatja.
A az signalr create szolgáltatás mód beállítása vagy az signalr update módosítása az Azure SignalR parancssori felületével.
Alapértelmezett mód
Ahogy a név is mutatja, az alapértelmezett mód a SignalR szolgáltatás alapértelmezett szolgáltatásmódja. Alapértelmezett módban az alkalmazás tipikus ASP.NET Core SignalR vagy ASP.NET SignalR (elavult) alkalmazásként működik. Rendelkezik egy olyan webkiszolgáló-alkalmazással, amely egy hubot, úgynevezett hubkiszolgálót üzemeltet, és az ügyfelek teljes kétirányú kommunikációval rendelkeznek a központi kiszolgálóval. A ASP.NET Core SignalR és az Azure SignalR szolgáltatás közötti különbség ahelyett, hogy közvetlenül csatlakoztatja az ügyfél- és központkiszolgálót, az ügyfél és a kiszolgáló is csatlakozik a SignalR szolgáltatáshoz, és proxyként használja a szolgáltatást. Az alábbi ábrán a tipikus alkalmazásstruktúra látható Alapértelmezett módban.
Az alapértelmezett mód általában akkor a megfelelő választás, ha rendelkezik a SignalR szolgáltatással használni kívánt SignalR-alkalmazással.
Csatlakozás ion útválasztás alapértelmezett módban
Alapértelmezett módban WebSocket-kapcsolatok vannak a központi kiszolgáló és a SignalR szolgáltatás között, úgynevezett kiszolgálókapcsolatok. Ezek a kapcsolatok üzenetek kiszolgáló és ügyfél közötti átvitelére szolgálnak. Ha új ügyfél csatlakozik, a SignalR szolgáltatás egy központi kiszolgálóra irányítja az ügyfelet (feltételezve, hogy több kiszolgálóval rendelkezik) a meglévő kiszolgálókapcsolatokon keresztül. Az ügyfélkapcsolat az élettartama során ugyanahhoz a központi kiszolgálóhoz fog csatlakozni. Ezt a tulajdonságot kapcsolati ragadósságnak nevezzük. Amikor az ügyfél üzeneteket küld, mindig ugyanarra a központi kiszolgálóra kerülnek. A ragadós viselkedéssel biztonságosan fenntarthat bizonyos állapotokat az egyes kapcsolatokhoz a központi kiszolgálón. Ha például streamelni szeretne valamit a kiszolgáló és az ügyfél között, nem kell figyelembe vennie azt az esetet, amikor az adatcsomagok különböző kiszolgálókra kerülnek.
Fontos
Alapértelmezett módban az ügyfél nem tud csatlakozni anélkül, hogy először egy központi kiszolgáló csatlakozik a szolgáltatáshoz. Ha az összes központi kiszolgáló hálózati megszakadása vagy a kiszolgáló újraindítása miatt megszakad, az ügyfélkapcsolatok hibaüzenetet kapnak, amely azt jelzi, hogy nincs kiszolgáló csatlakoztatva. Az Ön felelőssége, hogy mindig legyen legalább egy központi kiszolgáló csatlakoztatva a SignalR szolgáltatáshoz. Az alkalmazást például több központi kiszolgálóval is megtervezheti, majd győződjön meg arról, hogy nem lesznek egyszerre offline állapotban.
Az alapértelmezett útválasztási modell azt is jelenti, hogy amikor egy központi kiszolgáló offline állapotba kerül, a kiszolgálóra irányított kapcsolatok megszakadnak. A kapcsolat megszakadása várható, ha a központi kiszolgáló offline állapotban van karbantartás céljából, és kezelnie kell az újracsatlakozást az alkalmazásra gyakorolt hatások minimalizálása érdekében.
Megjegyzés:
Alapértelmezett módban a REST API, a felügyeleti SDK és a függvénykötés használatával közvetlenül küldhet üzeneteket egy ügyfélnek, ha nem szeretne központi kiszolgálót használni. Alapértelmezett módban az ügyfélkapcsolatokat továbbra is a központi kiszolgálók kezelik, és a felsőbb rétegbeli végpontok nem működnek ebben a módban.
Serverless mode
Az alapértelmezett módtól eltérően a kiszolgáló nélküli módhoz nincs szükség központi kiszolgáló futtatására, ezért ezt a módot "kiszolgáló nélkülinek" nevezik. A SignalR szolgáltatás felelős az ügyfélkapcsolatok fenntartásáért. Nincs garancia a kapcsolat ragadósságára, és a HTTP-kérések kevésbé hatékonyak lehetnek, mint a WebSockets-kapcsolatok.
A kiszolgáló nélküli mód az Azure Functions használatával valós idejű üzenetkezelési képességet biztosít. Az ügyfelek az Azure Functions SignalR szolgáltatáskötéseivel, úgynevezett függvénykötésekkel dolgoznak az üzenetek kimeneti kötésként való küldéséhez.
Mivel nincs kiszolgálókapcsolat, ha kiszolgálói SDK-val próbál kiszolgálókapcsolatot létesíteni, hibaüzenet jelenik meg. A SignalR szolgáltatás elutasítja a kiszolgálókapcsolati kísérleteket kiszolgáló nélküli módban.
A kiszolgáló nélküli mód nem rendelkezik kapcsolati ragadóssággal, de a kiszolgálóoldali alkalmazás leküldéses üzeneteket küldhet az ügyfeleknek. Kétféleképpen küldhet üzeneteket az ügyfeleknek kiszolgáló nélküli módban:
- REST API-k használata egyszeri küldési eseményhez, vagy
- WebSocket-kapcsolat használatával hatékonyabban küldhet több üzenetet. Ez a WebSocket-kapcsolat eltér a kiszolgálókapcsolattól.
Megjegyzés:
A SignalR szolgáltatásfelügyeleti SDK-ban a REST API és a WebSocket is támogatott. Ha a .NET-en kívül más nyelvet használ, manuálisan is meghívhatja a REST API-kat a specifikációt követve.
A kiszolgálóalkalmazás is fogadhat üzeneteket és kapcsolati eseményeket az ügyfelektől. A SignalR szolgáltatás webes kampók használatával küld üzeneteket és kapcsolati eseményeket előre konfigurált végpontokra (úgynevezett felsőbb rétegbeli végpontokra). A felsőbb rétegbeli végpontok csak kiszolgáló nélküli módban konfigurálhatók. További információ: Felsőbb rétegbeli végpontok.
Az alábbi ábra a kiszolgáló nélküli üzemmód működését mutatja be.
Klasszikus mód
Megjegyzés:
A klasszikus mód elsősorban az alapértelmezett és kiszolgáló nélküli üzemmód bevezetése előtt létrehozott alkalmazások visszamenőleges kompatibilitására szolgál. Ne használjon klasszikus módot, kivéve végső megoldásként. Használja az Alapértelmezett vagy a Kiszolgáló nélküli beállítást az új alkalmazásokhoz a forgatókönyve alapján. Fontolja meg a meglévő alkalmazások újratervezését, hogy ne legyen szükség klasszikus módra.
A klasszikus az Alapértelmezett és a Kiszolgáló nélküli üzemmód vegyes módja. Klasszikus módban a kapcsolat típusát az határozza meg, hogy van-e csatlakoztatott központi kiszolgáló az ügyfélkapcsolat létesítésekor. Ha van központi kiszolgáló, az ügyfélkapcsolat egy központi kiszolgálóra lesz irányítva. Ha a központi kiszolgáló nem érhető el, az ügyfélkapcsolat korlátozott kiszolgáló nélküli módban jön létre, ahol az ügyfél–kiszolgáló üzenetek nem kézbesíthetők a központi kiszolgálóra. A klasszikus módú kiszolgáló nélküli kapcsolatok nem támogatnak bizonyos funkciókat, például a felsőbb rétegbeli végpontokat.
Ha az összes központi kiszolgáló bármilyen okból offline állapotban van, a kapcsolatok kiszolgáló nélküli módban lesznek létrehozva. Az Ön felelőssége, hogy legalább egy központi kiszolgáló mindig elérhető legyen.
Válassza ki a megfelelő szolgáltatási módot
Most már tisztában kell lennie a szolgáltatási módok közötti különbségeket, és tudnia kell, hogyan választhat közöttük. Ahogy korábban említettem, a klasszikus mód nem ajánlott új vagy meglévő alkalmazásokhoz. Íme néhány további tipp, amelyek segíthetnek a megfelelő választásban a szolgáltatási módhoz, és segíthetnek a klasszikus mód kivonásában a meglévő alkalmazások esetében.
Válassza az Alapértelmezett módot, ha már ismeri a SignalR-kódtár működését, és át szeretne lépni egy saját üzemeltetésű SignalR-ről az Azure SignalR szolgáltatás használatára. Az alapértelmezett mód pontosan ugyanúgy működik, mint a saját üzemeltetésű SignalR, és ugyanazt a programozási modellt használhatja a SignalR-kódtárban. A SignalR szolgáltatás proxyként működik az ügyfelek és a központi kiszolgálók között.
Válassza a Kiszolgáló nélküli módot, ha új alkalmazást hoz létre, és nem szeretné fenntartani a központi kiszolgáló- és kiszolgálókapcsolatokat. A kiszolgáló nélküli mód együttműködik az Azure Functions szolgáltatással, így semmilyen kiszolgálót sem kell fenntartania. A REST API-val, a felügyeleti SDK-val vagy a függvénykötés + felsőbb rétegbeli végponttal továbbra is teljes kétirányú kommunikációt végezhet, de a programozási modell eltér a SignalR-kódtártól.
Válassza az Alapértelmezett módot, ha mindkét központi kiszolgálóval rendelkezik az ügyfélkapcsolatok kiszolgálásához, és egy háttéralkalmazással közvetlenül leküldheti az üzeneteket az ügyfeleknek. Az alapértelmezett és a kiszolgáló nélküli mód közötti fő különbség az, hogy vannak-e központi kiszolgálók, és hogyan vannak irányítva az ügyfélkapcsolatok. A REST API/management SDK/függvénykötés mindkét módban használható.
Ha valóban vegyes forgatókönyvvel rendelkezik, érdemes megfontolnia a használati esetek több SignalR-szolgáltatáspéldányra való elkülönítését, a használatnak megfelelően beállított szolgáltatásmóddal. Egy klasszikus módot igénylő vegyes forgatókönyvre példa, ha két különböző központ van ugyanazon a SignalR-erőforráson. Az egyik központot hagyományos SignalR-központként, a másikat pedig az Azure Functionsben használják. Ezt a példát két erőforrásra kell felosztani, egy példány alapértelmezett módban, egy pedig kiszolgáló nélküli módban.
Következő lépések
Az alapértelmezett és kiszolgáló nélküli módokkal kapcsolatos további tudnivalókért tekintse meg az alábbi cikkeket.