Share via


Szabályozási műveletek az Azure Service Buson

A natív felhőmegoldások a számítási feladatokkal skálázható korlátlan erőforrások fogalmát adják. Bár ez a fogalma a felhőben igazabb, mint a helyszíni rendszerek esetében, a felhőben továbbra is vannak korlátozások. Ezek a korlátozások az ügyfélalkalmazás-kérelmek szabályozását okozhatják mind a standard, mind a prémium szinten, amint azt ebben a cikkben ismertetjük.

Szabályozás standard szinten

A Service Bus standard szintje több-bérlős beállításként működik használatalapú díjszabási modellel. Itt egy fürtben több névtér is osztozik a lefoglalt erőforrásokon. A standard szint a fejlesztői környezetek, a minőségbiztosítási környezetek és az alacsony átviteli sebességű éles rendszerek számára ajánlott választás.

Korábban a Service Bus szigorúan az erőforrás-kihasználtságtól függött, durva szabályozási korlátozásokkal rendelkezett. Lehetőség van azonban a szabályozási logika finomítására, és kiszámítható szabályozási viselkedést biztosíthat az erőforrásokat megosztó összes névtér számára.

Annak érdekében, hogy biztosítsa az erőforrások igazságos használatát és elosztását az azonos erőforrásokat használó Összes Service Bus-szabványnévtérben, a Service Bus standard jelenleg a kreditalapú szabályozási logikát használja.

Feljegyzés

Fontos megjegyezni, hogy a szabályozás nem új az Azure Service Busban vagy a natív felhőszolgáltatásban.

A kreditalapú szabályozás egyszerűen finomítja azt, ahogyan a különböző névterek osztják meg az erőforrásokat egy több-bérlős standard szintű környezetben, és így lehetővé teszi az erőforrásokat megosztó összes névtér számára a méltányos használatot.

Mi az a kreditalapú szabályozás?

A kreditalapú szabályozás korlátozza az adott névtéren egy adott időszakban elvégezhető műveletek számát. Íme a kreditalapú szabályozás munkafolyamata.

  • Minden időszak elején a Service Bus krediteket biztosít az egyes névtereknek.
  • A küldő vagy fogadó ügyfélalkalmazások által végrehajtott műveletek beleszámítanak ezekbe a kreditekbe (és kivonódnak a rendelkezésre álló kreditekből).
  • Ha a kreditek kimerülnek, a rendszer a következő időszak kezdetéig szabályozza a további műveleteket.
  • A kreditek a következő időszak elején töltődnek fel.

Mik a kreditkorlátok?

A kreditkorlátok jelenleg másodpercenként 1000 kreditre vannak beállítva (névtérenként). Nem minden művelet jön létre egyenlőként. Íme az egyes műveletek kreditköltségei.

Művelet Jóváírási költség
Adatműveletek (Send, SendAsync, Receive, ReceiveAsync) Peek Üzenetenként 1 kredit
Felügyeleti műveletek (Create, Read, Updateüzenetsorokon Delete , témakörökben, előfizetésekben, szűrőkben) 10 kredit

Feljegyzés

Egy témakörbe való küldéskor az egyes üzenetek kiértékelése szűrők alapján történik, mielőtt elérhetővé válik az előfizetésben. Minden szűrőértékelés a kreditkerettel is számol (azaz szűrőértékelésenként 1 kredit).

Hogyan tudom, hogy szabályoznak?

Amikor az ügyfélalkalmazás-kérelmek szabályozása folyamatban van, az ügyfélalkalmazás a következő kiszolgálói választ kapja.

The request was terminated because the entity is being throttled. Error code: 50009. Please wait 2 seconds and try again.

Hogyan kerülhetem el a szabályozást?

Megosztott erőforrások esetén fontos, hogy az erőforrásokat megosztó különböző Service Bus-névtereken méltányos használatot kényszerítsünk ki. A szabályozás biztosítja, hogy egyetlen számítási feladat kiugró száma ne okozzon más számítási feladatokat ugyanazon az erőforráson. Ahogy azt a cikk későbbi részében említettük, nincs kockázat a szabályozásra, mivel az ügyfélszoftver-fejlesztési készletek (SDK-k) és más Azure PaaS-ajánlatok beépített alapértelmezett újrapróbálkozási szabályzattal rendelkeznek. A szabályozott kérelmeket exponenciális visszalépéssel újrapróbáljuk, és végül a kreditek feltöltése után is végighaladunk.

Érthető, hogy egyes alkalmazások érzékenyek lehetnek a szabályozásra. Ebben az esetben azt javasoljuk, hogy az aktuális Service Bus standard névteret prémium szintűre migrálja. A migrálás során dedikált erőforrásokat rendelhet a Service Bus-névtérhez, és megfelelően skálázhatja fel az erőforrásokat, ha a számítási feladat kiugróan magas, és csökkenti a szabályozás valószínűségét. Emellett, ha a számítási feladat normál szintre csökken, leskálázhatja a névtérhez lefoglalt erőforrásokat.

Szabályozás prémium szinten

A Service Bus prémium szintű csomag dedikált erőforrásokat foglal le az üzenetkezelési egységek tekintetében az ügyfél által beállított névterekhez. Ezek a dedikált erőforrások kiszámítható átviteli sebességet és késést biztosítanak, és magas átviteli sebességhez vagy érzékeny éles minőségű rendszerekhez ajánlottak. Emellett a prémium szint lehetővé teszi az ügyfelek számára az átviteli kapacitás vertikális felskálázását is, ha a számítási feladat kiugróan magas. További információ: Azure Service Bus-névtér üzenetkezelési egységeinek automatikus frissítése.

Hogyan működik a szabályozás a Service Bus Premiumban?

A prémium szintű kizárólagos erőforrás-kiosztással a szabályozást kizárólag a névtérhez lefoglalt erőforrások korlátozásai vezérlik. Ha a kérések száma meghaladja az aktuális erőforrások által kiszolgálható értéket, akkor a kérések szabályozva lesznek.

Hogyan tudom, hogy szabályoznak?

A service bus prémium szintű szabályozásának különböző módjai vannak.

  • A szabályozott kérések megjelennek az Azure Monitor-kérelmek metrikáiban, hogy megállapíthassák , hány kérelem lett szabályozva.
  • A magas CPU-használat azt jelzi, hogy az aktuális erőforrás-kiosztás magas, és a kérések szabályozva lehetnek, ha az aktuális számítási feladat nem csökken.
  • A magas memóriahasználat azt jelzi, hogy az aktuális erőforrás-kiosztás magas, és a kérések szabályozva lehetnek, ha az aktuális számítási feladat nem csökken.

Hogyan kerülhetem el a szabályozást?

Mivel a Service Bus prémium szintű névtér már rendelkezik dedikált erőforrásokkal, csökkentheti a szabályozás lehetőségét, ha a számítási feladat csúcsának eseményében (vagy előrejelzésében) a névtérhez rendelt üzenetkezelési egységek számának skálázásával csökkenti a szabályozás lehetőségét. További információ: Azure Service Bus-névtér üzenetkezelési egységeinek automatikus frissítése.

GYIK

Hogyan befolyásolja a szabályozás az alkalmazásomat?

Ha egy kérés szabályozva van, az azt jelenti, hogy a szolgáltatás foglalt, mert több kéréssel szembesül, mint amennyit az erőforrások megengednek. Ha ugyanezt a műveletet néhány pillanat múlva újra megpróbálják, miután a szolgáltatás átdolgozta az aktuális számítási feladatát, a kérést meg lehet tartani.

Mivel a szabályozás minden natív felhőszolgáltatás elvárt viselkedése, az újrapróbálkozási logika magában a Service Bus SDK-ban van beépítve. Az alapértelmezett beállítás az automatikus újrapróbálkozás exponenciális visszakapcsolással, hogy ne legyen minden alkalommal ugyanaz a kérés szabályozva. Az alapértelmezett újrapróbálkozási logika minden műveletre érvényes.

Feljegyzés

Az egyéb külső szolgáltatásokat hívó üzenetfeldolgozó kódot ezek a szolgáltatások is szabályozhatják. A forgatókönyvek kezelésével kapcsolatos további információkért tekintse meg a szabályozási mintával kapcsolatos dokumentációt.

A szabályozás adatvesztést eredményez?

Az Azure Service Bus az adatmegőrzésre van optimalizálva. Biztosítjuk, hogy a Service Busnak küldött összes adat tárolóra legyen kötelezve, mielőtt a szolgáltatás elismerené a kérés sikerességét.

Miután a Service Bus sikeresen elismerte a kérést, az azt jelenti, hogy a Service Bus sikeresen feldolgozta a kérést. Ha a Service Bus hibát ad vissza, az azt jelenti, hogy a Service Bus nem tudta feldolgozni a kérést, és az ügyfélalkalmazásnak újra meg kell próbálkoznia a kéréssel.

Ha azonban egy kérés szabályozva van, a szolgáltatás azt jelenti, hogy erőforráskorlátozások miatt jelenleg nem tudja elfogadni és feldolgozni a kérést. Ez nem jelent semmilyen adatvesztést, mert a Service Bus egyszerűen nem tekintette meg a kérést. Ebben az esetben a Service Bus SDK alapértelmezett újrapróbálkozási szabályzatára támaszkodva biztosítható, hogy a kérés végül feldolgozva legyen.

A Service Bus-üzenetkezelés használatával kapcsolatos további információkért és példákért tekintse meg az alábbi speciális témaköröket: