Pokročilé omezování požadavků pomocí služby Azure API Management
PLATÍ PRO: Všechny úrovně služby API Management
Schopnost omezovat příchozí požadavky je klíčovou rolí služby Azure API Management. Buď kontrolou četnosti požadavků nebo celkového počtu přenášených požadavků nebo dat, služba API Management umožňuje poskytovatelům rozhraní API chránit svá rozhraní API před zneužitím a vytvářet hodnotu pro různé úrovně produktů rozhraní API.
Limity rychlosti a kvóty
Omezení četnosti a kvóty se používají k různým účelům.
Omezení přenosové rychlosti
Limity četnosti se obvykle používají k ochraně před krátkými a intenzivními nárůsty objemů. Pokud například víte, že vaše back-endová služba má kritický bod v databázi s vysokým objemem volání, můžete nastavit zásadu rate-limit-by-key tak, aby nepovolovala velký objem volání pomocí tohoto nastavení.
Upozornění
Vzhledem k distribuované povaze architektury omezování není omezování rychlosti nikdy úplně přesné. Rozdíl mezi nakonfigurovaným a skutečným počtem povolených požadavků se liší v závislosti na objemu a četnosti požadavků, latenci back-endu a dalších faktorech.
Kvóty
Kvóty se obvykle používají k řízení četnosti volání za delší časové období. Můžou například nastavit celkový počet volání, která může konkrétní odběratel provést v daném měsíci. Pokud chcete monetizovat rozhraní API, můžete pro předplatná založená na vrstvách nastavit kvóty také jinak. Například předplatné úrovně Basic může mít maximálně 10 000 volání měsíčně, ale úroveň Premium může každý měsíc mít až 100 000 000 volání.
Ve službě Azure API Management se limity rychlosti obvykle šíří rychleji napříč uzly, aby se chránily před špičkami. Naproti tomu informace o kvótách využití se používají za delší dobu, a proto se jejich implementace liší.
Poznámka:
Když se základní výpočetní prostředky restartují na platformě služby, služba API Management může po dosažení kvóty dál zpracovávat žádosti po krátkou dobu.
Omezování založené na produktech
Možnosti omezování rychlosti, které jsou omezené na konkrétní předplatné, jsou užitečné pro poskytovatele rozhraní API, aby použil limity pro vývojáře, kteří se zaregistrovali k používání svého rozhraní API. Nepodporuje ale například omezování jednotlivých koncových uživatelů rozhraní API. Je možné, že jeden uživatel aplikace vývojáře využije celou kvótu a pak zabrání ostatním zákazníkům, aby mohli aplikaci používat. Také několik zákazníků, kteří můžou generovat velký objem požadavků, může omezit přístup na občasné uživatele.
Omezení založené na vlastních klíčích
Poznámka:
Zásady rate-limit-by-key a quota-by-key zásady nejsou k dispozici, pokud jsou na úrovni Consumption služby Azure API Management. Zásady quota-by-key také nejsou v současné době k dispozici na úrovních v2.
Zásady rate-limit-by-key a kvót-by-key poskytují flexibilnější řešení pro řízení provozu. Tyto zásady umožňují definovat výrazy k identifikaci klíčů, které se používají ke sledování využití provozu. Způsob, jak to funguje, je nejsnadněji znázorněný v příkladu.
Omezování IP adres
Následující zásady omezují jednu IP adresu klienta na 10 volání každou minutu, celkem 1 000 000 volání a 10 000 kilobajtů šířky pásma za měsíc.
<rate-limit-by-key calls="10"
renewal-period="60"
counter-key="@(context.Request.IpAddress)" />
<quota-by-key calls="1000000"
bandwidth="10000"
renewal-period="2629800"
counter-key="@(context.Request.IpAddress)" />
Pokud všichni klienti na internetu použili jedinečnou IP adresu, může to být efektivní způsob omezení využití uživatelem. Je však pravděpodobné, že více uživatelů sdílí jednu veřejnou IP adresu, protože k internetu přistupuje přes zařízení NAT. Navzdory tomu může být nejlepší volbou rozhraní API, která umožňují neověřený přístup IpAddress .
Omezování identity uživatele
Pokud je koncový uživatel ověřený, může být vygenerován klíč omezování na základě informací, které uživatele jednoznačně identifikují.
<rate-limit-by-key calls="10"
renewal-period="60"
counter-key="@(context.Request.Headers.GetValueOrDefault("Authorization","").AsJwt()?.Subject)" />
Tento příklad ukazuje, jak extrahovat autorizační hlavičku, převést ji na JWT objekt a použít předmět tokenu k identifikaci uživatele a použít ho jako klíč omezení rychlosti. Pokud je identita uživatele uložená jako JWT jedna z ostatních deklarací identity, mohla by se tato hodnota použít na svém místě.
Kombinované zásady
I když zásady omezování založené na uživatelích poskytují větší kontrolu než zásady omezování na základě předplatného, stále existují hodnoty kombinování obou možností. Omezení podle kódu Product Subscription Key (omezení četnosti volání podle předplatného a nastavení kvóty využití podle předplatného) je skvělý způsob, jak povolit monetizaci rozhraní API na základě úrovní využití. Jemně odstupňovaná kontrola schopnosti omezovat uživatele je doplňková a brání chování jednoho uživatele v degradaci prostředí jiného uživatele.
Omezování řízené klientem
Když je klíč omezování definován pomocí výrazu zásad, pak se jedná o zprostředkovatele rozhraní API, který vybírá, jak je omezení vymezeno. Vývojář ale může chtít řídit, jak limituje své vlastní zákazníky. To může povolit poskytovatel rozhraní API tím, že zavádí vlastní hlavičku, která klientské aplikaci vývojáře umožní komunikovat klíč s rozhraním API.
<rate-limit-by-key calls="100"
renewal-period="60"
counter-key="@(request.Headers.GetValueOrDefault("Rate-Key",""))"/>
Díky tomu může klientská aplikace vývojáře zvolit, jak chce vytvořit klíč omezení rychlosti. Vývojáři klientů můžou vytvořit vlastní úrovně sazeb přidělením sad klíčů uživatelům a obměnou používání klíče.
Shrnutí
Azure API Management nabízí omezování četnosti a kvót pro ochranu a zvýšení hodnoty služby rozhraní API. Nové zásady omezování s vlastními pravidly oborů umožňují podrobnější kontrolu nad těmito zásadami, aby vaši zákazníci mohli vytvářet ještě lepší aplikace. Příklady v tomto článku ukazují použití těchto nových zásad omezením rychlosti výroby klíčů s IP adresami klienta, identitou uživatele a hodnotami vygenerovanými klientem. Existuje však mnoho dalších částí zprávy, které lze použít, jako je uživatelský agent, fragmenty cest URL, velikost zprávy.
Další kroky
Sdělte nám prosím svůj názor jako problém na GitHubu pro toto téma. Bylo by skvělé slyšet další potenciální klíčové hodnoty, které byly ve vašich scénářích logickou volbou.