Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Používá bránu k agregaci několika jednotlivých požadavků do jednoho. Tento model je užitečný, když klient musí provést více volání různých back-endových systémů, aby mohl provést operaci.
Kontext a problém
Aby bylo možné provést jednu úlohu, klient může muset provést více volání různých back-endových služeb. Aplikace, která je kvůli provedení úkolu závislá na mnoha službách, musí na každý požadavek vynaložit prostředky. Při přidání nových funkcí nebo služeb do aplikace jsou potřeba další požadavky, které dále zvyšují požadavky na prostředky a síťová volání. Tato chattnost mezi klientem a back-endem může nepříznivě ovlivnit výkon a škálování aplikace. Architektury mikroslužeb učinily tento problém běžnějším, protože aplikace tvořené mnoha menšími službami mají větší počet volání mezi službami.
V následujícím diagramu klient odesílá požadavky do každé služby (číslování 1, 2 a 3). Každá služba zpracuje požadavek a vrátí odpověď na aplikaci (číslo 4, 5 a 6). Odesílání jednotlivých požadavků tímto způsobem přes mobilní síť s vysokou latencí je neefektivní a může způsobit ztrátu připojení nebo neúplné odpovědi. Každý požadavek může běžet paralelně. Aplikace ale stále musí odesílat, čekat a zpracovávat data pro každý požadavek na samostatná připojení, což zvyšuje pravděpodobnost selhání.
Solution
Použijte bránu ke snížení nadměrné komunikace mezi klientem a službami. Brána přijímá požadavky klientů, odesílá požadavky do různých back-endových systémů a agreguje výsledky předtím, než je odešle zpět klientovi.
Tento model může snížit počet požadavků, které aplikace provádí v back-endových službách, a zlepšit výkon aplikací v sítích s vysokou latencí.
V následujícím diagramu aplikace odesílá požadavek do brány (1). Požadavek obsahuje balíček dalších požadavků. Brána tyto požadavky rozdělí a zpracuje každý požadavek tím, že jej odešle příslušné službě (2). Každá služba vrátí odpověď bráně (3). Brána odpovědi z každé služby zkombinuje a odešle odpověď aplikaci (4). Aplikace vytvoří jeden požadavek a z brány obdrží jenom jednu odpověď.
Problémy a důležité informace
Při rozhodování o implementaci tohoto modelu zvažte následující body:
Brána by neměla zavádět propojení služeb napříč back-endovými službami.
Brána by se měla nacházet poblíž back-endových služeb, aby se snížila latence co nejvíce.
Služba brány může zavést jediný bod selhání (SPoF). Ujistěte se, že je brána správně navržená tak, aby splňovala požadavky vaší aplikace na dostupnost.
Brána může představovat úzké místo. Ujistěte se, že má brána odpovídající výkon pro zvládnutí aktuálního zatížení a je možné ji škálovat tak, aby odpovídala očekávanému růstu.
Proveďte zátěžové testy na bráně, abyste zajistili, že nezpůsobíte kaskádová selhání služeb.
Navrhněte odolné řešení pomocí technik, jako jsou bulkheads, circuit breaker, opakování pokusů a časové limity.
Pokud jedno nebo více volání služby trvá příliš dlouho, může být přijatelné operaci ukončit po vypršení časového limitu a vrátit pouze část dat. Zvažte, jak vaše aplikace tento scénář zvládne.
Používejte asynchronní vstup a výstup (I/O), aby prodleva v back-endu nezpůsobila problémy s výkonem aplikace.
Implementujte distribuované trasování pomocí ID korelace ke sledování jednotlivých volání.
Monitorujte metriky požadavků a velikosti odpovědí.
Zvažte vrácení dat z mezipaměti jako záložní strategii pro případ selhání.
Namísto zabudování agregace do brány zvažte umístit agregační službu za bránu. Agregace požadavků bude pravděpodobně mít jiné nároky na prostředky než jaké mají ostatní služby v bráně a může ovlivnit funkce směrování a odlehčování brány.
Kdy použít tento vzor
Tento model použijte v těchto případech:
Klient musí komunikovat s více back-endovými službami, aby mohl provést operaci.
Klient může používat sítě, které mají významnou latenci, například mobilní sítě.
Tento vzor nemusí být vhodný v těchto případech:
Chcete snížit počet volání mezi klientem a jednou službou napříč více operacemi. V tomto scénáři může být přidání dávkové operace do služby vhodnější.
Klient nebo aplikace se nachází poblíž back-endových služeb a latence není významným faktorem.
Návrh úloh
Vyhodnoťte, jak použít model agregace brány v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected. Následující tabulka obsahuje pokyny, jak tento model podporuje cíle jednotlivých pilířů.
| Pilíř | Jak tento model podporuje cíle pilíře |
|---|---|
| Spolehlivostní rozhodnutí o návrhu pomáhají vaší pracovní zátěži stát se odolná proti poruchám a zajistit, aby se po selhání obnovila do plně funkčního stavu. | S touto topologií můžete přesunout zpracování přechodných chyb z distribuované implementace mezi klienty na centralizovanou implementaci. - Doporučení pro zpracování přechodných chyb |
| Rozhodnutí o návrhu zabezpečení pomáhají zajistit důvěrnost, integritu a dostupnost dat a systémů vaší úlohy. | Tato topologie často snižuje počet dotykových bodů, které má klient se systémem, což snižuje veřejnou plochu a ověřovací body. Agregované backendy mohou zůstat od klientů zcela síťově izolované. - SE:04 Segmentace - SE:08 Posílení zabezpečení |
| Efektivita provozu pomáhá poskytovat kvalitu úloh prostřednictvím standardizovaných procesů a týmové soudržnosti. | Tento model umožňuje vývoj back-endové logiky nezávisle na klientech. Díky tomuto oddělení získáte flexibilitu při změně zřetězených implementací služeb nebo dokonce zdrojů dat, aniž byste museli měnit touchpointy klienta. - OE:04 Nástroje a procesy |
| efektivita výkonu pomáhá vašim úlohám efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu. | Tento návrh může mít menší latenci než návrh, ve kterém klient vytváří více připojení. Ukládání do mezipaměti v implementacích agregace minimalizuje volání back-endových systémů. - PE:03 Výběr služeb - Datový výkon PE:08 |
Pokud tento model představuje kompromisy v rámci pilíře, zvažte je proti cílům ostatních pilířů.
Example
Zvažte aplikaci založenou na mikroslužbách, která poskytuje souhrnné prostředí objednávky pro zákazníka. Když uživatel otevře stránku objednávky, musí aplikace načítat data z více back-endových služeb, jako je služba objednávek, služba dodávek a služba profilů zákazníků.
V architektuře mikroslužeb se tyto služby implementují a nasazují nezávisle. Bez agregace musí klient volat každou službu přímo, což zvyšuje latenci a složitost.
K vyřešení tohoto problému aplikace používá jako vrstvu agregace brány Azure API Management. Klient odešle jeden požadavek na operaci služby API Management, která slouží ke shromažďování informací o objednávce. API Management pak zavolá podpůrná back-endová rozhraní API a vrátí jednotnou odpověď klientovi.
Toto odlehčené skládání můžete implementovat pomocí zásady API Management send-request k načtení dat z více služeb a vytvoření kombinované odpovědi. V tomto příkladu se back-endové služby spouští v prostředí Azure Container Apps a každou back-endovou službu nasadíte jako aplikaci typu kontejner, která zůstane skrytá před přímým přístupem klienta.
Stáhněte si soubor aplikace Visio s touto architekturou.
Tok požadavku se řídí těmito kroky:
Klient odešle požadavek na koncový bod souhrnu objednávky zpřístupněný prostřednictvím API Managementu.
SLUŽBA API Management používá zásadu, která shromažďuje data o objednávkách, dodávkách a profilech zákazníků z back-endových služeb.
API Management skládá odpovědi backendu do jediného datového objektu shrnutí objednávky.
Služba API Management vrátí agregovanou odpověď klientovi.
Zavedením této agregační vrstvy řešení snižuje odezvy mezi klienty a službami a zjednodušuje interakce klientů. Tato vrstva odpovídá za elegantní zvládání nereagujících back-endových služeb a za zabránění řetězení selhání v rámci agregované odpovědi. Zabezpečte zásady služby API Management pomocí časových limitů pro jednotlivé požadavky, podmíněného zpracování chyb a jističů.
Pokud vyprší časový limit jednoho z back-endových volání nebo vrátí chybu, může služba API Management použít chování, které nejlépe vyhovuje dané operaci. Může například vrátit částečnou odpověď, pokud jsou chybějící data přijatelná, nebo může selhat celý požadavek, pokud jsou vyžadována úplná a konzistentní data objednávky. Toto rozhodnutí proveďte explicitně v návrhu zásad, aby klienti měli předvídatelné chování.
Tento přístup funguje dobře, když brána provádí jednoduchou orchestraci, transformaci a sestavování odpovědí. Pokud agregace vyžaduje logiku vlastní domény, složité transformace nebo delší orchestraci, umístěte tuto funkci do vyhrazené vlastní služby za bránou.
Pro monitorování shromážděte telemetrii v celé cestě požadavku, abyste mohli korelovat chování služby API Management s latencí back-endu. Tato viditelnost je důležitá v agregačním vzoru brány, protože jedna operace klienta závisí na několika back-endových voláních a selháních nebo pomalých odpovědích v jakékoli závislosti můžou ovlivnit konečný agregovaný výsledek. Jako platformu centrální pozorovatelnosti použijte Azure Monitor. Shromážděte protokoly a metriky služby API Management pro bránu a cestu provádění zásad a povolte monitorování pro Container Apps, abyste mohli shromažďovat protokoly a metriky aplikací z kontejnerových aplikací v back-endu. Směrujte telemetrii služby API Management a back-endovou telemetrii do pracovního prostoru Log Analytics pro jednotné dotazování, generování výstrah a řešení potíží. Pomocí této telemetrie můžete rozpoznat vzorce překročení časového limitu, určit, která závislost backendu způsobila částečnou nebo neúspěšnou odezvu, a nastavit upozornění na zvýšenou latenci nebo míru chyb.
Další kroky
- Použití externích služeb ze služby API Management
- Zásady odesílání žádostí
- Dokumentace služby Container Apps