Hely valós idejű megosztása alacsony költségű kiszolgáló nélküli Azure-szolgáltatások használatával

Ez a forgatókönyv azt ismerteti, hogyan építhet ki olyan megoldást, amely valós idejű szolgáltatások használatával dolgozza fel a mögöttes adatok módosításait egy webes nézetben anélkül, hogy lapfrissítésre van szükség. Ilyen eset például a termékek és áruk valós idejű nyomon követése, valamint a közösségimédia-megoldások.

Architektúra

Töltse le az architektúra Visio-fájlját.

Összetevők

• Azure Service Bus egy rendkívül megbízható felhőalapú üzenetkezelési szolgáltatás alkalmazások és szolgáltatások között, még akkor is, ha egy vagy több offline állapotban van.
• Azure SignalR Service megkönnyíti a valós idejű kommunikáció hozzáadását a webalkalmazáshoz.
• Azure Functions egy eseményvezérelt, kiszolgáló nélküli számítási platform, amely összetett vezénylési problémákat is képes megoldani.

Alternatív megoldások

Ennek a forgatókönyvnek a megoldására léteznek alternatívák, beleértve a Pushert is. Ez a kategóriavezető a robusztus API-kban olyan alkalmazásfejlesztők számára, akik skálázható valós idejű kommunikációs funkciókat fejlesztenek.

Ott van a PubNub is. A PubNubbal egyszerűen adhat hozzá valós idejű képességeket az alkalmazásához anélkül, hogy az infrastruktúrával kellene foglalkoznia. Olyan alkalmazásokat hozhat létre, amelyekkel a felhasználók valós időben kommunikálhatnak mobilon, böngészőben, asztali számítógépen és kiszolgálón is.

Ez egy másik alternatíva. Kiszolgáló nélküli közzétételi/feliratkozási (pub/sub) üzenetküldést biztosít, amely megbízhatóan skálázható az igényeinek megfelelően. Az üzenetküldés a peremhálózaton, a WebSockets használatával történik. Az Ably platform magas rendelkezésre állású, rugalmasan méretezhető és globálisan elosztott valós idejű infrastruktúrát biztosít egy API meghívására.

Bár a Pusher, a PubNub és az Ably a legelfogadottabb platformok a valós idejű üzenetküldéshez, ebben a forgatókönyvben mindent az Azure-ban fog elvégezni. Javasoljuk, hogy a SignalR legyen a go-to platform, mert lehetővé teszi a kétirányú kommunikációt a kiszolgáló és az ügyfél között. Ez egy nyílt forráskódú eszköz, 7,9 ezer GitHub-csillaggal és 2,2 ezer GitHub-elágazással.

További információ: SignalR nyílt forráskódú adattár a GitHubon.

Forgatókönyv részletei

Ebben a forgatókönyvben azt fogja áttekinteni, hogyan állíthat be valós idejű üzenetküldő szolgáltatást egy ételkézbesítési szolgáltatás tranzakciójának élő helyének megosztásához. Ez a példa azoknak is hasznos lehet, akik valós idejű helymegosztási platformot próbálnak létrehozni webes vagy mobilalkalmazásaikhoz.

A kiszolgáló nélküli módban konfigurált SignalR-szolgáltatással integrálható egy szolgáltatásbusz által aktivált Azure Functions alkalmazással, mindezt a .NET Core használatával.

Lehetséges használati esetek

Ezek a használati esetek hasonló tervezési mintákkal rendelkeznek:

• Valós idejű hely megosztása ügyféleszközökkel
• Értesítések leküldése a felhasználóknak
• Ütemtervek frissítése
• Csevegőszobák létrehozása

Megfontolandó szempontok

Ezek a szempontok implementálják az Azure Well-Architected-keretrendszer alappilléreit, amelyek a számítási feladatok minőségének javítására használható vezérelvek. További információ: Microsoft Azure Well-Architected Framework.

Az alábbiakban néhány dolgot érdemes szem előtt tartani a forgatókönyv kidolgozása során, többek között azt is, hogyan konfigurálhatja a paramétereket a ServiceBusTrigger Azure Service Bus kapcsolati sztring:

• Központok: A hubok összehasonlíthatók egy videóstreamelési szolgáltatással. Feliratkozhat egy központra, ahonnan üzeneteket küldhet és fogadhat.
• Célok: A célpontok olyanok, mint a rádiócsatornák. Ezek közé tartozik minden olyan személy, aki figyeli a célcsatornát, és értesítést kap, ha új üzenet van rajta.

Ha emlékszik a SignalR platform előző két funkciójára, könnyű lesz gyorsan felállni és futni.

Rendelkezésre állás, skálázhatóság és biztonság

Ezzel a megoldással magas rendelkezésre állást érhet el a következő két szakaszban leírtak szerint.

Régiónkénti párosítás

Minden egyes Azure-régió párban áll egy másikkal egy azonos földrajzi területen belül. Régiókat általában azonos regionális párokból érdemes választani (például: USA 2. keleti régiója és USA középső régiója). Ennek előnyei például a következők:

• Ha széles körű kimaradás történik, minden párból legalább egy régió helyreállítása prioritást élvez.
• A tervezett Azure-rendszerfrissítések egyszerre csak a régiópár egyik tagján jelennek meg, ami csökkenti az állásidőt.
• A legtöbb esetben a regionális párok azonos földrajzi helyen belül találhatók, hogy megfeleljenek az adatok tárolási helyére vonatkozó előírásoknak.
• Győződjön meg azonban arról, hogy mindkét régió támogatja az alkalmazáshoz szükséges összes Azure-szolgáltatást. Lásd: Szolgáltatások régiónként. További információk a regionális párokról: Üzletmenet-folytonosság és vészhelyreállítás (BCDR): Az Azure párosított régiói.

Azure Front Door

Töltse le az architektúra Visio-fájlját.

Az Azure Front Door Service skálázható, biztonságos belépési pont a globális alkalmazások gyors biztosításához. Ha prioritású útválasztást használ, az automatikusan feladatátvételre kerül, ha az elsődleges régió elérhetetlenné válik. A többrégiós architektúrák magasabb rendelkezésre állást biztosíthatnak, mint az egyetlen régióban történő üzembe helyezés. Ha egy régió üzemkimaradása hatással van az elsődleges régióra, a Front Door szolgáltatással feladatátvételt hajthat végre a másodlagos régióba.

Ez az architektúra a megoldás egy adott alrendszerének meghibásodása esetén is segíthet. A webalkalmazási tűzfal és a DDoS Protection segítségével kivédheti a hálózatot és az alkalmazásréteget célzó támadásokat a peremhálózaton. A Microsoft által felügyelt szabálykészletek használatával megerősítheti a szolgáltatást, és saját szabályokat készíthet az alkalmazás egyéni védelméhez.

A Front Door a rendszer egyik lehetséges meghibásodási pontja. Ha a szolgáltatás meghibásodik, az ügyfelek nem tudnak hozzáférni az alkalmazáshoz az állásidő alatt. Tekintse át a Front Door szolgáltatásiszint-szerződését (SLA), és állapítsa meg, hogy a Front Door használata önmagában megfelel-e az üzleti követelményeknek a magas rendelkezésre állás érdekében. Ha nem, akkor a biztonság érdekében érdemes lehet hozzáadni egy másik forgalomkezelési szolgáltatást a feladat-visszavételhez. Ha a Front Door szolgáltatás meghibásodik, módosítsa a saját kanonikus nevének (CNAME-) rekordját a DNS-ben úgy, hogy a többi forgalomkezelő szolgáltatásra mutasson. Ezt a lépést manuálisan kell végrehajtania, és az alkalmazás nem lesz elérhető a DNS-módosítások propagálásáig.

Költségoptimalizálás

A költségoptimalizálás a felesleges költségek csökkentésének és a működési hatékonyság javításának módjait ismerteti. További információ: A költségoptimalizálási pillér áttekintése.

Tegyük fel, hogy vállalata napi 1000 megrendeléssel rendelkezik, és egyidejűleg meg kell osztania a helyadatokat mindegyikkel. A forgatókönyv üzembe helyezéséhez szükséges becsült Azure-használat a közzététel időpontjában érvényes díjszabás alapján havonta közel 192 USD lesz.

A forgatókönyv üzembe helyezése

Az Azure Functions fejlesztése

A Azure Functions és Azure SignalR Service beépített kiszolgáló nélküli valós idejű alkalmazások általában két Azure Functions igényelnek:

• Egy negotiate függvény, amelyet az ügyfél meghív egy érvényes SignalR Service hozzáférési jogkivonat és szolgáltatásvégpont URL-címének beszerzéséhez.
• Egy vagy több olyan függvényre, amelyek üzeneteket küldenek, vagy csoporttagságokat kezelnek.

SignalRFunctionApp

A SignalRFunctionApp egy függvényalkalmazás, amely létrehoz egy Azure Functions-példányt egy Service Bus-eseményindítóval a SignalR használatával.

Negotiate.cs

Ezt a függvényt egy HTTP-kérés aktiválja. Az ügyfélalkalmazások arra használják, hogy jogkivonatot szerezzenek be a SignalR szolgáltatásból, amellyel az ügyfelek feliratkozhatnak egy központra. Ennek a függvénynek a neve negotiate. További információ: Azure Functions fejlesztés és konfigurálás Azure SignalR Service

Message.cs

Ezt a függvényt egy Service Bus-eseményindító aktiválja. A függvény össze van kötve a SignalR-szolgáltatással. Kiemeli az üzenetet az üzenetsorból, és továbbítja egy SignalR-központba.

Utasítások

Előkészületek:

• Győződjön meg arról, hogy ki van építve egy Service Bus-üzenetsor az Azure-ban.
• Győződjön meg arról, hogy rendelkezik kiszolgáló nélküli módban kiépített SignalR-szolgáltatással az Azure-ban.

1. Adja meg a kapcsolati sztringeket (Service Bus és SignalR) a local.settings.json fájlban.
2. Adja meg az ügyfélalkalmazás (SignalR-ügyfél) URL-címét a CORS-ban (eltérő eredetű erőforrás-megosztás). A legújabb szintaxisért lásd: Azure Functions fejlesztés és konfigurálás Azure SignalR Service.
3. Adja meg a service bus-üzenetsor nevét a Service Bus-eseményindítóban a Message.cs fájlban.

Most konfiguráljuk az ügyfélalkalmazást a teszteléshez. Először ragadja meg a példaforrásokat a megoldásarchitektúrák GitHub-oldalán.

SignalR-ügyfél

Ez egy egyszerű .NET Core-webalkalmazás, amellyel feliratkozhat a SignalRFunctionApp által létrehozott központra. Valós időben jeleníti meg a Service Bus-üzenetsoron fogadott üzeneteket. Bár a SignalRFunctionApp használatával mobilügyféllel dolgozhat, maradjunk a webes ügyfélnél ebben az adattárban.

Utasítások

1. Győződjön meg arról, hogy a SignalRFunctionApp fut.

2. Másolja ki az egyeztetési függvény által létrehozott URL-címet. A következőhöz hasonlóan néz ki: http://localhost:7071/api/.

3. Illessze be az URL-címet a chat.js fájlba a fájlba signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build();.

4. Futtassa az alkalmazást.

   Az állapot akkor csatlakozik, ha a webes ügyfél sikeresen feliratkozik a SignalR hubra.

SendToQueue.js

Ez a node.js szkript egy üzenetet küld a Service Busnak, hogy tesztelhesse az imént befejezett üzembe helyezést.

Utasítások

1. Telepítse a node Azure Service Bus modult (@azure/service-bus).

2. Adja meg a szkriptben a kapcsolati sztringet és az üzenetsor nevét.

3. Futtassa a szkriptet.

További lépések

Ezt a forgatókönyvet az éles környezetben is használhatja. Győződjön meg azonban arról, hogy az Azure-szolgáltatások méretezésre vannak beállítva. Az Azure Service Bust például standard vagy prémium csomagra kell állítani.

A kódot közvetlenül a Visual Studióból helyezheti üzembe az Azure Functionsben. Ha meg szeretné tudni, hogyan teheti közzé a kódot Azure Functions a Visual Studióból, kövesse az Útmutató a szoftver készítéséhez című útmutatót.

Ismerje meg, hogyan dolgozhat Azure Service Bus kötésekkel Azure Functions. Azure Functions támogatja a Service Bus-üzenetsorok és -témakörök trigger- és kimeneti kötéseit.

Megtudhatja, hogyan hitelesítheti és küldhet valós idejű üzeneteket a Azure SignalR Service csatlakoztatott ügyfeleknek SignalR Service kötések használatával Azure Functions. Az Azure Functions támogatja a SignalR-szolgáltatás bemeneti és kimeneti kötéseit.

Kapcsolódó források (lehet, hogy a cikkek angol nyelvűek)

• Nagy mennyiségű kötegelt tranzakció feldolgozása
• Transit Hub dinamikus pub-sub üzenetkezelő rendszer
• Kiszolgáló nélküli eseményfeldolgozás
• Blokklánc-munkafolyamati alkalmazás
• Eseményalapú felhőbeli automatizálás