Cvičení – přidání kontrol stavu webové aplikace
Contoso Shoes potřebuje způsob, jak zkontrolovat stav webové aplikace na úrovni rozhraní API a také její závislosti. V aplikaci chcete implementovat vyhrazený koncový bod kontroly stavu, který v pravidelných intervalech hlásí stav rozhraní API.
Aktuální stav a problém
V aktuálním návrhu aplikace protokoluje chyby, pokud v kódu rozhraní API dochází k problémům za běhu nebo volání závislých služeb selžou, například neúspěšné databázové dotazy. Tento přístup je užitečný při řešení potíží po incidentu.
Tento přístup ale není proaktivní. Aplikace Azure Služba a externí monitorovací nástroje nemají způsob, jak zkontrolovat stav samotné aplikace. Tato mezera má vliv na řadu případů použití, jako je způsob distribuce zatížení. Aktuální implementace spoléhá výhradně na to, že plán služby App Service nejlépe distribuuje provoz napříč instancemi bez kontroly stavu aplikace. V jednom nahlášeném incidentu byl provoz směrován do instancí služby App Service, které nejsou v pořádku, což vede k neúspěšným požadavkům.
Specifikace
Vaším úkolem je sestavit vyhrazenou službu Health Service jako rozšíření už nasazeného kódu.
Zavedení rozhraní API pro kontrolu stavu ve vaší aplikaci Rozhraní API musí zkontrolovat stav aplikace a její závislosti a vrátit indikaci stavu. Rozhraní API by například pravidelně mělo kontrolovat operace čtení a zápisu do služby Azure Cosmos DB. Tyto funkce implementujte jako samostatné sondy, aby se nezávisle kontrolovaly čtení a zápisy.
Tip
Rozšiřte kontrolu stavu na nefunkční služby, jako je Azure Key Vault a Azure Container Registry. Tento krok je důležitý, protože pokud u těchto služeb dojde k výpadku, můžete zaznamenat dopad na možnost horizontálního navýšení kapacity nebo vydržet restartování instance služby App Service.
Koncový bod rozhraní API pro kontrolu stavu se často volá z více zdrojů a neměl by snižovat výkon rozhraní API. Například plán služby Aplikace Azure musí odesílat požadavky do koncového bodu dvakrát za minutu a rozhodovat se o tom, do kterých instancí služby App Service se má provoz distribuovat.
Optimalizujte výkon rozhraní API pro kontrolu stavu tak, že do mezipaměti do mezipaměti 10 sekund dochází k ukládání paměti. Ne každý dotaz na koncový bod kontroly stavu by měl vést k back-endovému volání. Některé z těchto odpovědí je možné obsluhovat z mezipaměti.
Zpřístupnění dat kontroly stavu ve službě Azure Monitor pro budoucí analýzu
Doporučený přístup
Pokud chcete začít s návrhem, doporučujeme následující přístup:
1–Kontroly stavu
Všechny dotazy, které rozhraní API pro kontrolu stavu odesílá, se musí provádět asynchronně a paralelně. Navrhujte kontroly stavu pro důležité komponenty, jako je databáze. Rozhraní API by mělo pravidelně kontrolovat operace čtení a zápisu. Tyto funkce implementujte jako samostatné sondy, aby se nezávisle kontrolovaly čtení a zápisy.
Používejte požadavky, které napodobují skutečné chování aplikace bez příliš velkého zatížení služeb jen z sond stavu. Pokud chcete také testovat požadavky na zápis, musíte navrhnout způsob efektivního odebrání testovacích dat, aby se nezmíchal se skutečnými uživatelskými daty.
2– Vzor ukládání do mezipaměti
Aby se zabránilo přetížení podřízených služeb kontrolou stavu, mělo by rozhraní API pro kontrolu stavu ukládat výsledky do mezipaměti po dobu konfigurovatelného počtu sekund. Zamyslete se nad možnými způsoby, jak tohoto cíle dosáhnout.
Kontrola práce
Tady je příklad služby Application Health Service. Pokryli jste všechny aspekty návrhu?
- Je koncový bod kontroly stavu kompatibilní s funkcí kontroly stavu služby Aplikace Azure?
- Zahrnuli jste kontroly závislostí modulu runtime? Co jste použili jako proxy/test?
- Čtení a zápis ve službě Cosmos DB
- Rozhraní API třetích stran
- Ukážili jste výsledky kontroly stavu do mezipaměti, abyste snížili režii na výkon?
- Protokolovali jste události ve svých kontrolách stavu? Povšimněte si úspěchů a selhání?
- Použili jste u protokolů kontroly stavu vzorkování protokolů Aplikace Azure lication Insights?