Oefening: statuscontroles voor webtoepassingen toevoegen
Contoso Shoes heeft een manier nodig om de status van de webtoepassing op API-niveau en de bijbehorende afhankelijkheden te controleren. U wilt een toegewezen eindpunt voor statuscontrole implementeren in de toepassing, waarmee de STATUS van de API regelmatig wordt gerapporteerd.
Huidige status en probleem
In het huidige ontwerp registreert de toepassing fouten wanneer er runtimeproblemen zijn in de API-code of aanroepen naar afhankelijke services mislukken, zoals mislukte databasequery's. Deze aanpak is handig bij het oplossen van problemen nadat een incident is opgetreden.
De aanpak is echter niet proactief. Azure-app Service en de externe bewakingshulpprogramma's hebben geen manier om de status van de toepassing zelf te controleren. Deze kloof heeft invloed op veel gebruiksvoorbeelden, zoals de verdeling van de belasting. De huidige implementatie is uitsluitend afhankelijk van de beste inspanning van het App Service-plan om verkeer gelijkmatig over exemplaren te verdelen zonder de status van de toepassing te controleren. In één gerapporteerd incident is verkeer doorgestuurd naar beschadigde App Service-exemplaren, wat resulteert in mislukte aanvragen.
Specificatie
Uw taak is om de toegewezen health-service te bouwen als een extensie voor de al geïmplementeerde code.
Introduceer een statuscontrole-API in uw toepassing. De API moet de status van de toepassing en de bijbehorende afhankelijkheden controleren en een statusindicatie retourneren. De API moet bijvoorbeeld periodiek lees- en schrijfbewerkingen controleren naar Azure Cosmos DB. Implementeer deze functies als afzonderlijke tests, zodat lees- en schrijfbewerkingen onafhankelijk worden gecontroleerd.
Tip
Breid de statuscontrole uit naar niet-functionele services, zoals Azure Key Vault en Azure Container Registry. Deze stap is belangrijk, omdat als deze services te maken hebben met een storing, u mogelijk last hebt van de mogelijkheid om uit te schalen of bestand te zijn tegen het opnieuw opstarten van een App Service-exemplaar.
Het eindpunt van de statuscontrole-API wordt vaak aangeroepen door meerdere bronnen en mag de prestaties van de API niet verminderen. Het Azure-app Service-plan moet bijvoorbeeld twee keer per minuut aanvragen verzenden naar een eindpunt en weloverwogen beslissingen nemen over naar welke App Service-exemplaren verkeer moeten worden gedistribueerd.
Optimaliseer de prestaties van de statuscontrole-API door geheugen gedurende 10 seconden in de cache te plaatsen. Niet elke query naar het eindpunt van de statuscontrole moet resulteren in een back-end-aanroep. Sommige van deze antwoorden kunnen worden geleverd vanuit de cache.
Zorg ervoor dat statuscontrolegegevens beschikbaar zijn in Azure Monitor voor toekomstige analyse.
Aanbevolen benadering
Om aan de slag te gaan met uw ontwerp, raden we de volgende aanpak aan:
1–Statuscontroles
Alle query's die de API voor statuscontrole verzendt, moeten asynchroon en parallel worden uitgevoerd. Ontwerp statuscontroles op basis van de kritieke onderdelen, zoals de database. De API moet regelmatig lees- en schrijfbewerkingen controleren. Implementeer deze functies als afzonderlijke tests, zodat lees- en schrijfbewerkingen onafhankelijk worden gecontroleerd.
Gebruik aanvragen die echt toepassingsgedrag nabootsen zonder te veel belasting op de services te plaatsen, alleen vanuit de statustests. Als u ook schrijfaanvragen wilt testen, moet u een manier ontwerpen om testgegevens efficiënt te verwijderen, zodat deze niet worden gecombineerd met echte gebruikersgegevens.
2-Cachepatroon
Om te voorkomen dat de downstreamservices overbelast raken met statuscontroles, moet de API voor statuscontrole resultaten gedurende een configureerbaar aantal seconden in de cache opslaan. Denk aan mogelijke manieren om dit doel te bereiken.
Controleer uw werk
Hier volgt een voorbeeld van Application Health Service. Heb je alle aspecten in je ontwerp behandeld?
- Is het statuscontrole-eindpunt compatibel met de statuscontrolefunctie van Azure-app service?
- Hebt u controles voor runtime-afhankelijkheden opgenomen? Wat hebt u gebruikt als proxy/test?
- Lees-/schrijfbewerkingen in Cosmos DB
- API van derden
- Hebt u de resultaten van de statuscontrole in de cache opgeslagen om de overhead van de prestaties te verminderen?
- Hebt u gebeurtenissen in uw statuscontroles geregistreerd? Let op de successen en de fouten?
- Hebt u Azure-toepassing Insights-logboeksampling toegepast op de statuscontrolelogboeken?