Overwegingen bij het ontwerpen van toepassingen voor bedrijfskritieke workloads
De basislijn bedrijfskritieke referentiearchitectuur maakt gebruik van een eenvoudige online catalogustoepassing om een zeer betrouwbare workload te illustreren. Gebruikers kunnen door een catalogus met items bladeren, itemdetails bekijken en beoordelingen en opmerkingen posten voor items. Dit artikel richt zich op de betrouwbaarheids- en tolerantieaspecten van een bedrijfskritieke toepassing, zoals asynchrone aanvraagverwerking en het bereiken van hoge doorvoer binnen een oplossing.
Belangrijk
Een referentie-implementatie op productieniveau die de essentiële ontwikkeling van toepassingen laat zien op ondersteuning voor Azure de richtlijnen in dit artikel. U kunt deze implementatie gebruiken als basis voor verdere ontwikkeling van oplossingen in uw eerste stap naar productie.
Samenstelling van toepassing
Voor bedrijfskritieke toepassingen op grote schaal moet u de architectuur optimaliseren voor end-to-end schaalbaarheid en tolerantie. U kunt onderdelen scheiden in functionele eenheden die onafhankelijk van elkaar kunnen werken. Pas deze scheiding toe op alle niveaus op de toepassingsstack, zodat elk deel van het systeem onafhankelijk kan worden geschaald en aan wijzigingen in de vraag kan voldoen. De implementatie demonstreert deze aanpak.
De toepassing maakt gebruik van stateless API-eindpunten die langlopende schrijfaanvragen asynchroon ontkoppelen via een berichtenbroker. Met de samenstelling van de workload kunt u op elk gewenst moment hele AKS-clusters (Azure Kubernetes Service) en andere afhankelijkheden in de stempel verwijderen en opnieuw maken. De belangrijkste onderdelen van de toepassing zijn:
Gebruikersinterface (UI): een webtoepassing met één pagina waartoe gebruikers toegang hebben. De gebruikersinterface wordt gehost in de statische website van een Azure Storage-account die als host fungeert.
API (
CatalogService): een REST API die wordt aangeroepen door de UI-toepassing, maar nog steeds beschikbaar is voor andere potentiële clienttoepassingen.Worker (
BackgroundProcessor): een achtergrondmedewerker die luistert naar nieuwe gebeurtenissen in de berichtenbus en de schrijfaanvragen naar de database verwerkt. Met dit onderdeel worden geen API's weergegeven.Health Service-API (
HealthService): een API die de status van de toepassing rapporteert door te controleren of kritieke onderdelen werken, zoals de database of berichtenbus.
De workload bestaat uit de API-, werkrol- en statuscontroletoepassingen. Een toegewezen AKS-naamruimte die als host fungeert voor workload de workload als containers. Er wordt geen directe communicatie tussen de pods uitgevoerd. De pods zijn staatloos en kunnen onafhankelijk worden geschaald.
Andere ondersteunende onderdelen die in het cluster worden uitgevoerd, zijn onder andere:
Een NGINX-ingangscontroller: stuurt binnenkomende aanvragen naar de workload en taakverdelingen tussen pods. De NGINX-ingangscontroller wordt weergegeven via Azure Load Balancer met een openbaar IP-adres, maar kan alleen worden geopend via Azure Front Door.
Certificaatbeheerder: De automatische inrichting van TLS-certificaten (Transport Layer Security) van Jetstack
cert-managermet behulp van Let's Encrypt voor de regels voor inkomend verkeer.Geheimenarchief CSI-stuurprogramma: de Azure Key Vault-provider voor Het CSI-stuurprogramma geheimenarchief leest veilig geheimen, zoals verbindingsreeks s uit Key Vault.
Bewakingsagent: de standaardCONFIGURATIE VAN OMSAgentForLinux wordt aangepast om de hoeveelheid bewakingsgegevens te verminderen die naar de Werkruimte Azure Monitor-logboeken worden verzonden.
Databaseverbinding
Vanwege de tijdelijke aard van implementatiestempels, vermijdt u zo veel mogelijk persistente status binnen de stempel. U moet de status behouden in een extern gegevensarchief. Ter ondersteuning van de serviceniveaudoelstelling (SLO) voor betrouwbaarheid maakt u een tolerant gegevensarchief. U wordt aangeraden beheerde of PaaS-oplossingen (Platform as a Service) te gebruiken in combinatie met systeemeigen SDK-bibliotheken die automatisch time-outs, verbroken verbindingen en andere foutstatussen verwerken.
In de referentie-implementatie fungeert Azure Cosmos DB als het belangrijkste gegevensarchief voor de toepassing. Azure Cosmos DB biedt schrijfbewerkingen in meerdere regio's. Elke stempel kan naar de Azure Cosmos DB-replica in dezelfde regio schrijven en Azure Cosmos DB verwerkt intern gegevensreplicatie en synchronisatie tussen regio's. Azure Cosmos DB for NoSQL ondersteunt alle mogelijkheden van de database-engine.
Zie Data Platform voor bedrijfskritieke workloads voor meer informatie.
Notitie
Gebruik Azure Cosmos DB voor NoSQL voor nieuwe toepassingen. Voor verouderde toepassingen die gebruikmaken van een ander NoSQL-protocol, evalueert u het migratiepad naar Azure Cosmos DB.
Voor bedrijfskritieke toepassingen die prioriteit geven aan beschikbaarheid ten opzichte van de prestaties, raden we aan schrijfbewerkingen in één regio en leesbewerkingen met een sterk consistentieniveau te gebruiken.
Deze architectuur maakt gebruik van Storage om de status tijdelijk op te slaan in de stempel voor controlepunten van Azure Event Hubs.
Alle workloadonderdelen gebruiken de Azure Cosmos DB .NET Core SDK om te communiceren met de database. De SDK bevat robuuste logica voor het onderhouden van databaseverbindingen en het afhandelen van fouten. Belangrijke configuratie-instellingen zijn:
Directe connectiviteitsmodus: deze instelling is een standaardinstelling voor .NET SDK v3 omdat deze betere prestaties biedt. De directe connectiviteitsmodus heeft minder netwerkhops in vergelijking met de gatewaymodus, die gebruikmaakt van HTTP.
Antwoord van inhoud retourneren bij schrijven: deze benadering is uitgeschakeld, zodat de Azure Cosmos DB-client het document niet kan retourneren van bewerkingen voor maken, upsert en patchen en vervangen, waardoor netwerkverkeer wordt verminderd. Voor verdere verwerking op de client is deze instelling niet vereist.
Aangepaste serialisatie: met dit proces wordt het naamgevingsbeleid voor JSON-eigenschappen ingesteld om
JsonNamingPolicy.CamelCase.NET-eigenschappen te vertalen naar standaard JSON-eigenschappen. U kunt JSON-eigenschappen ook vertalen naar .NET-eigenschappen. De standaardwaarde negeren negeert eigenschappen met null-waarden, zoalsJsonIgnoreCondition.WhenWritingNull, tijdens serialisatie.ApplicationRegion: Deze eigenschap is ingesteld op de regio van de zegel, waarmee de SDK het dichtstbijzijnde verbindingseindpunt kan vinden. Het eindpunt moet zich bij voorkeur in dezelfde regio bevinden.
Het volgende codeblok wordt weergegeven in de referentie-implementatie:
//
// /src/app/AlwaysOn.Shared/Services/CosmosDbService.cs
//
CosmosClientBuilder clientBuilder = new CosmosClientBuilder(sysConfig.CosmosEndpointUri, sysConfig.CosmosApiKey)
.WithConnectionModeDirect()
.WithContentResponseOnWrite(false)
.WithRequestTimeout(TimeSpan.FromSeconds(sysConfig.ComsosRequestTimeoutSeconds))
.WithThrottlingRetryOptions(TimeSpan.FromSeconds(sysConfig.ComsosRetryWaitSeconds), sysConfig.ComsosMaxRetryCount)
.WithCustomSerializer(new CosmosNetSerializer(Globals.JsonSerializerOptions));
if (sysConfig.AzureRegion != "unknown")
{
clientBuilder = clientBuilder.WithApplicationRegion(sysConfig.AzureRegion);
}
_dbClient = clientBuilder.Build();
Asynchrone berichten
Wanneer u losse koppeling implementeert, hebben services geen afhankelijkheden van andere services. Dankzij het losse aspect kan een service onafhankelijk van elkaar werken. Het koppelingsaspect maakt communicatie tussen services mogelijk via goed gedefinieerde interfaces. Voor een bedrijfskritieke toepassing voorkomt losse koppeling dat downstreamfouten trapsgewijs worden uitgevoerd naar front-ends of andere implementatiestempels, die hoge beschikbaarheid bieden.
De belangrijkste kenmerken van asynchrone berichten zijn:
Services hoeven niet hetzelfde rekenplatform, dezelfde programmeertaal of hetzelfde besturingssysteem te gebruiken.
Services worden onafhankelijk geschaald.
Downstreamfouten hebben geen invloed op clienttransacties.
Transactionele integriteit is moeilijk te onderhouden omdat gegevens worden gemaakt en persistentie plaatsvinden in afzonderlijke services. Transactionele integriteit is een uitdaging voor berichten- en persistentieservices. Zie Idempotent message processing (Idempotent message processing) voor meer informatie.
End-to-end tracering vereist complexe indeling.
U wordt aangeraden bekende ontwerppatronen te gebruiken, zoals het patroon Load Leveling op basis van wachtrij en het patroon Concurrerende consumenten. Deze patronen verdelen de belasting van de producent naar de consumenten en maken asynchrone verwerking door consumenten mogelijk. Met de werkrol kan de API bijvoorbeeld de aanvraag accepteren en snel terugkeren naar de aanroeper, en de werkrol verwerkt een schrijfbewerking voor de database afzonderlijk.
Event Hubs brokers berichten tussen de API en worker.
Belangrijk
Gebruik de berichtenbroker niet als een permanent gegevensarchief voor langere tijd. De Event Hubs-service ondersteunt de opnamefunctie. Met de functie vastleggen kan een Event Hub automatisch een kopie van de berichten schrijven naar een gekoppeld opslagaccount. Dit proces bepaalt het gebruik en fungeert als mechanisme voor het maken van back-ups van berichten.
Details van implementatie van schrijfbewerkingen
Schrijfbewerkingen, zoals postclassificatie en opmerking, worden asynchroon verwerkt. De API verzendt eerst een bericht met alle relevante informatie, zoals het type actie en de opmerkingengegevens, naar de berichtenwachtrij en retourneert HTTP 202 (Accepted) onmiddellijk met de Location koptekst van het object dat wordt gemaakt.
BackgroundProcessor exemplaren verwerken berichten in de wachtrij en verwerken de werkelijke databasecommunicatie voor schrijfbewerkingen. BackgroundProcessor wordt dynamisch ingeschaald en uitgeschaald op basis van het volume van het wachtrijbericht. De uitschaallimiet van processorexemplaren wordt gedefinieerd door het maximum aantal Event Hubs-partities. Dit is 32 voor Basic-lagen en Standard-lagen, 100 voor de Premium-laag en 1024 voor de Dedicated-laag.
De Azure Event Hubs Processor-bibliotheek in BackgroundProcessor Azure Blob Storage gebruikt voor het beheren van het eigendom van partities, de taakverdeling tussen verschillende werkrolinstanties en het gebruik van controlepunten om de voortgang bij te houden. De controlepunten worden na elke gebeurtenis niet naar blobopslag geschreven omdat er een dure vertraging voor elk bericht wordt toegevoegd. In plaats daarvan worden de controlepunten geschreven in een timerlus en kunt u de duur configureren. De standaardinstelling is 10 seconden.
Het volgende codeblok wordt weergegeven in de referentie-implementatie:
while (!stoppingToken.IsCancellationRequested)
{
await Task.Delay(TimeSpan.FromSeconds(_sysConfig.BackendCheckpointLoopSeconds), stoppingToken);
if (!stoppingToken.IsCancellationRequested && !checkpointEvents.IsEmpty)
{
string lastPartition = null;
try
{
foreach (var partition in checkpointEvents.Keys)
{
lastPartition = partition;
if (checkpointEvents.TryRemove(partition, out ProcessEventArgs lastProcessEventArgs))
{
if (lastProcessEventArgs.HasEvent)
{
_logger.LogDebug("Scheduled checkpointing for partition {partition}. Offset={offset}", partition, lastProcessEventArgs.Data.Offset);
await lastProcessEventArgs.UpdateCheckpointAsync();
}
}
}
}
catch (Exception e)
{
_logger.LogError(e, "Exception during checkpointing loop for partition={lastPartition}", lastPartition);
}
}
}
Als de processortoepassing een fout tegenkomt of wordt gestopt voordat het bericht kan worden verwerkt:
Een ander exemplaar haalt het bericht op voor het opnieuw verwerken, omdat het niet goed is gecontroleerd in Storage.
Er treedt een conflict op als de vorige werkrol het document in de database heeft behouden voordat de werkrol is mislukt. Deze fout treedt op omdat dezelfde id en partitiesleutel worden gebruikt. De processor kan het bericht veilig negeren omdat het document al is opgeslagen.
Een nieuwe instantie herhaalt de stappen en voltooit persistentie als de vorige werkrol is beëindigd voordat deze naar de database is geschreven.
Details van implementatie van bewerkingen lezen
De API verwerkt leesbewerkingen rechtstreeks en retourneert onmiddellijk gegevens terug naar de gebruiker.
Er is geen back-channelmethode tot stand gebracht om met de client te communiceren als de bewerking is voltooid. De clienttoepassing moet proactief de API opvragen voor updates over het item dat is opgegeven in de Location HTTP-header.
Schaalbaarheid
Afzonderlijke workloadonderdelen moeten onafhankelijk worden uitgeschaald omdat elk onderdeel verschillende belastingspatronen heeft. De schaalvereisten zijn afhankelijk van de functionaliteit van de service. Bepaalde services zijn rechtstreeks van invloed op gebruikers en moeten agressief worden uitgeschaald om snelle reacties en een positieve gebruikerservaring te garanderen.
De implementatie verpakt de services als containerinstallatiekopieën en gebruikt Helm-grafieken om de services op elke stempel te implementeren. De services zijn geconfigureerd voor de verwachte Kubernetes-aanvragen en -limieten en een vooraf geconfigureerde regel voor automatisch schalen. De CatalogService onderdelen van de BackgroundProcessor workload kunnen afzonderlijk worden ingeschaald en uitgeschaald omdat beide services staatloos zijn.
Gebruikers communiceren rechtstreeks met de CatalogService, dus dit deel van de workload moet reageren onder elke belasting. Er zijn minimaal drie exemplaren voor elk cluster om te worden verdeeld over drie beschikbaarheidszones in een Azure-regio. Met de horizontale automatische schaalaanpassing van pods (HPA) in AKS worden zo nodig automatisch meer pods toegevoegd. Met de functie voor automatische schaalaanpassing van Azure Cosmos DB kunt u aanvraageenheden (RU's) die beschikbaar zijn voor de verzameling dynamisch verhogen en verminderen. De CatalogService en Azure Cosmos DB combineren om een schaaleenheid binnen een stempel te vormen.
De HPA wordt geïmplementeerd met een Helm-grafiek met een configureerbaar maximumaantal en een minimumaantal replica's. De belastingstest heeft vastgesteld dat elk exemplaar ongeveer 250 aanvragen per seconde kan verwerken met een standaardgebruikspatroon.
De BackgroundProcessor service heeft verschillende vereisten en wordt beschouwd als een achtergrondmedewerker die een beperkt effect heeft op de gebruikerservaring. Heeft dus BackgroundProcessor een andere configuratie voor automatisch schalen in vergelijking met CatalogService, en kan worden geschaald tussen 2 en 32 exemplaren. Bepaal deze limiet op basis van het aantal partities dat u in de Event Hubs gebruikt. U hebt niet meer werkrollen nodig dan partities.
| Onderdeel | minReplicas |
maxReplicas |
|---|---|---|
| CatalogService | 3 | 20 |
| BackgroundProcessor | 2 | 32 |
Elk onderdeel van de workload met afhankelijkheden, zoals ingress-nginx de instelling voor budgetten voor podonderbreking (PDBs) is geconfigureerd om ervoor te zorgen dat er een minimum aantal exemplaren beschikbaar blijft wanneer clusters worden gewijzigd.
Het volgende codeblok wordt weergegeven in de referentie-implementatie:
#
# /src/app/charts/healthservice/templates/pdb.yaml
# Example pod distribution budget configuration.
#
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: {{ .Chart.Name }}-pdb
spec:
minAvailable: 1
selector:
matchLabels:
app: {{ .Chart.Name }}
Notitie
Bepaal het werkelijke minimumaantal en het maximum aantal pods voor elk onderdeel door middel van belastingstests. Het aantal pods kan per workload verschillen.
Instrumentatie
Gebruik instrumentatie om prestatieknelpunten en gezondheidsproblemen te evalueren die workloadonderdelen in het systeem kunnen introduceren. Om u te helpen beslissingen te kwantificeren, moet elk onderdeel voldoende informatie verzenden via metrische gegevens en traceringslogboeken. Houd rekening met de volgende belangrijke overwegingen bij het instrumentatie van uw toepassing:
- Logboeken, metrische gegevens en andere telemetriegegevens verzenden naar het logboeksysteem van de stempel.
- Gebruik gestructureerde logboekregistratie in plaats van tekst zonder opmaak, zodat u gegevens kunt opvragen.
- Implementeer gebeurteniscorrelatie om een end-to-end transactieweergave te krijgen. In de referentie-implementatie bevat elk API-antwoord een bewerkings-id als een HTTP-header voor tracering.
- Vertrouw niet alleen op stdout-logboekregistratie of consolelogboekregistratie. Maar u kunt deze logboeken gebruiken om onmiddellijk problemen met een mislukte pod op te lossen.
Deze architectuur implementeert gedistribueerde tracering met Application Insights en een Werkruimte voor Azure Monitor-logboeken voor toepassingsbewakingsgegevens. Gebruik Azure Monitor-logboeken voor logboeken en metrische gegevens van workload- en infrastructuuronderdelen. Deze architectuur implementeert volledige end-to-end tracering van aanvragen die afkomstig zijn van de API, doorloop Event Hubs en vervolgens naar Azure Cosmos DB.
Belangrijk
Implementeer zegelbewakingsresources in een afzonderlijke bewakingsresourcegroep. De resources hebben een andere levenscyclus dan het stempel zelf. Zie Bewakingsgegevens voor stempelresources voor meer informatie.
Implementatiedetails van toepassingsbewaking
Het BackgroundProcessor onderdeel maakt gebruik van het Microsoft.ApplicationInsights.WorkerService NuGet-pakket om out-of-the-box instrumentatie uit de toepassing te halen. Serilog wordt ook gebruikt voor alle logboekregistratie in de toepassing. Application Insights is geconfigureerd als een sink naast de console-sink. Een TelemetryClient exemplaar voor Application Insights wordt alleen rechtstreeks gebruikt wanneer het nodig is om andere metrische gegevens bij te houden.
Het volgende codeblok wordt weergegeven in de referentie-implementatie:
//
// /src/app/AlwaysOn.BackgroundProcessor/Program.cs
//
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureServices((hostContext, services) =>
{
Log.Logger = new LoggerConfiguration()
.ReadFrom.Configuration(hostContext.Configuration)
.Enrich.FromLogContext()
.WriteTo.Console(outputTemplate: "[{Timestamp:yyyy-MM-dd HH:mm:ss.fff zzz} {Level:u3}] {Message:lj} {Properties:j}{NewLine}{Exception}")
.WriteTo.ApplicationInsights(hostContext.Configuration[SysConfiguration.ApplicationInsightsConnStringKeyName], TelemetryConverter.Traces)
.CreateLogger();
}
Om praktische tracering van aanvragen te demonstreren, retourneert elke geslaagde en mislukte API-aanvraag de header Correlatie-id naar de aanroeper. Het ondersteuningsteam van de toepassing kan application Insights doorzoeken met deze id en een gedetailleerde weergave krijgen van de volledige transactie, die wordt geïllustreerd in het voorgaande diagram.
Het volgende codeblok wordt weergegeven in de referentie-implementatie:
//
// /src/app/AlwaysOn.CatalogService/Startup.cs
//
app.Use(async (context, next) =>
{
context.Response.OnStarting(o =>
{
if (o is HttpContext ctx)
{
// ... code omitted for brevity
context.Response.Headers.Add("X-Server-Location", sysConfig.AzureRegion);
context.Response.Headers.Add("X-Correlation-ID", Activity.Current?.RootId);
context.Response.Headers.Add("X-Requested-Api-Version", ctx.GetRequestedApiVersion()?.ToString());
}
return Task.CompletedTask;
}, context);
await next();
});
Notitie
Adaptieve steekproeven zijn standaard ingeschakeld in de Application Insights SDK. Adaptieve steekproeven betekent dat niet elke aanvraag naar de cloud wordt verzonden en doorzoekbaar is op id. Bedrijfskritieke toepassingsteams moeten elke aanvraag betrouwbaar traceren. Daarom heeft de referentie-implementatie adaptieve steekproeven uitgeschakeld in de productieomgeving.
Implementatiedetails van Kubernetes-bewaking
U kunt diagnostische instellingen gebruiken om AKS-logboeken en metrische gegevens te verzenden naar Azure Monitor-logboeken. U kunt ook de functie containerinzichten gebruiken met AKS. Schakel containerinzichten in om de OMSAgentForLinux te implementeren via een Kubernetes DaemonSet op elk van de knooppunten in AKS-clusters. De OMSAgentForLinux kan meer logboeken en metrische gegevens verzamelen vanuit het Kubernetes-cluster en deze verzenden naar de bijbehorende Werkruimte van Azure Monitor-logboeken. Deze werkruimte bevat gedetailleerde gegevens over pods, implementaties, services en de algehele status van het cluster.
Uitgebreide logboekregistratie kan negatieve gevolgen hebben voor de kosten en biedt geen voordelen. Daarom worden stdout-logboekverzameling en Prometheus-scraping uitgeschakeld voor de workloadpods in de containerinzichtconfiguratie, omdat alle traceringen al zijn vastgelegd via Application Insights, waardoor dubbele records worden gegenereerd.
Het volgende codeblok wordt weergegeven in de referentie-implementatie:
#
# /src/config/monitoring/container-azm-ms-agentconfig.yaml
# This is just a snippet showing the relevant part.
#
[log_collection_settings]
[log_collection_settings.stdout]
enabled = false
exclude_namespaces = ["kube-system"]
Zie het volledige configuratiebestand voor meer informatie.
Toepassingsstatuscontrole
U kunt toepassingsbewaking en waarneembaarheid gebruiken om systeemproblemen snel te identificeren en het statusmodel te informeren over de huidige toepassingsstatus. U kunt statuscontrole weergeven via statuseindpunten. Statustests gebruiken statuscontrolegegevens om informatie te verstrekken. De belangrijkste load balancer gebruikt die informatie om het beschadigde onderdeel onmiddellijk uit de rotatie te halen.
Deze architectuur past statuscontrole toe op de volgende niveaus:
Workloadpods die worden uitgevoerd op AKS. Deze pods hebben status- en levensstatustests, zodat AKS hun levenscyclus kan beheren.
Health Service, een toegewezen onderdeel in het cluster. Azure Front Door is geconfigureerd om Health Service in elke stempel te testen en beschadigde stempels te verwijderen van automatisch taakverdeling.
Details van Health Service-implementatie
HealthService is een workloadonderdeel dat naast andere onderdelen wordt uitgevoerd, zoals CatalogService en BackgroundProcessor, op het rekencluster. HealthService biedt een REST API die azure Front Door-statuscontroleaanroepen aanroept om de beschikbaarheid van een stempel te bepalen. In tegenstelling tot eenvoudige livenesstests is Health Service een complexer onderdeel dat de status van afhankelijkheden biedt naast de eigen status.
Health Service reageert niet als het AKS-cluster niet beschikbaar is, waardoor de werkbelasting niet in orde is. Wanneer de service wordt uitgevoerd, worden periodieke controles uitgevoerd op kritieke onderdelen van de oplossing. Alle controles worden asynchroon en parallel uitgevoerd. Als een van de controles mislukt, is het hele stempel niet beschikbaar.
Waarschuwing
Statustests van Azure Front Door kunnen een aanzienlijke belasting voor Health Service opleggen, omdat aanvragen afkomstig zijn van meerdere aanwezigheidspunten (PoP). Implementeer effectieve caching om te voorkomen dat de downstreamonderdelen overbelast raken.
Health Service wordt ook gebruikt voor expliciet geconfigureerde URL-pingtests met de Application Insights-resource van elke stempel.
Zie Application Health Service voor meer informatie over de HealthService implementatie.
Volgende stap
Feedback
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie: https://aka.ms/ContentUserFeedback.
Feedback verzenden en weergeven voor