Impostare le regole di ridimensionamento nelle app Azure Container
App Azure Container gestisce il ridimensionamento orizzontale automatico tramite un set di regole di ridimensionamento dichiarative. Quando una revisione dell'app contenitore aumenta, vengono create nuove istanze della revisione su richiesta. Queste istanze sono note come repliche.
L'aggiunta o la modifica delle regole di ridimensionamento crea una nuova revisione dell'app contenitore. Una revisione è uno snapshot non modificabile dell'app contenitore. Per informazioni sui tipi di modifiche che attivano una nuova revisione, vedere Tipi di modifiche delle revisioni.
I processi di App contenitore basate su eventi usano regole di ridimensionamento per attivare le esecuzioni in base agli eventi.
Definizione del piano
Il ridimensionamento è la combinazione di limiti, regole e comportamento.
I limiti definiscono il numero minimo e massimo possibile di repliche per revisione man mano che l'app contenitore viene ridimensionata.
Limite di scalabilità Valore predefinito Valore minimo Valore massimo Numero minimo di repliche per revisione 0 0 Le repliche massime configurabili sono 300 in portale di Azure e 1.000 nell'interfaccia della riga di comando di Azure. Numero massimo di repliche per revisione 10 1 Le repliche massime configurabili sono 300 in portale di Azure e 1.000 nell'interfaccia della riga di comando di Azure. Le regole sono i criteri usati dalle app contenitore per decidere quando aggiungere o rimuovere repliche.
Le regole di scalabilità vengono implementate come HTTP, TCP (Transmission Control Protocol) o personalizzate.
Il comportamento è la combinazione di regole e limiti per determinare le decisioni di scalabilità nel tempo.
Il comportamento della scalabilità spiega come vengono prese decisioni sulla scalabilità.
Quando si definiscono le regole di ridimensionamento, è importante considerare gli elementi seguenti:
- Non vengono addebitati addebiti per l'utilizzo se l'app contenitore viene ridimensionata a zero.
- Le repliche che non elaborano, ma rimangono in memoria potrebbero essere fatturate a una velocità di inattività inferiore. Per altre informazioni, vedereFatturazione.
- Se si vuole assicurarsi che un'istanza della revisione sia sempre in esecuzione, impostare il numero minimo di repliche su 1 o superiore.
Regole di scalabilità
Il ridimensionamento è basato su tre diverse categorie di trigger:
- HTTP: in base al numero di richieste HTTP simultanee alla revisione.
- TCP: in base al numero di connessioni TCP simultanee alla revisione.
- Personalizzato: basato su CPU, memoria o origini dati basate su eventi supportate, ad esempio:
- Bus di servizio di Azure
- Hub eventi di Azure
- Apache Kafka
- Redis
Se si definiscono più regole di scalabilità, l'app contenitore inizia a ridimensionare una volta soddisfatta la prima condizione di tutte le regole.
HTTP
Con una regola di ridimensionamento HTTP, è possibile controllare la soglia delle richieste HTTP simultanee che determinano la scalabilità delle revisioni dell'app contenitore. Ogni 15 secondi, il numero di richieste simultanee viene calcolato come numero di richieste negli ultimi 15 secondi diviso per 15. I processi di App contenitore non supportano le regole di ridimensionamento HTTP.
Nell'esempio seguente la revisione aumenta fino a cinque repliche e può essere ridimensionata a zero. La proprietà di ridimensionamento è impostata su 100 richieste simultanee al secondo.
Esempio
La http
sezione definisce una regola di scalabilità HTTP.
Proprietà Scale | Descrizione | Default value | Valore minimo | Valore massimo |
---|---|---|---|---|
concurrentRequests |
Quando il numero di richieste HTTP supera questo valore, viene aggiunta un'altra replica. Le repliche continuano ad aggiungere al pool fino all'importo maxReplicas . |
10 | 1 | n/d |
{
...
"resources": {
...
"properties": {
...
"template": {
...
"scale": {
"minReplicas": 0,
"maxReplicas": 5,
"rules": [{
"name": "http-rule",
"http": {
"metadata": {
"concurrentRequests": "100"
}
}
}]
}
}
}
}
}
Nota
Impostare la properties.configuration.activeRevisionsMode
proprietà dell'app contenitore su single
, quando si usano regole di scalabilità di eventi non HTTP.
Definire una regola di scalabilità HTTP usando il --scale-rule-http-concurrency
parametro nei create
comandi o update
.
Parametro dell'interfaccia della riga di comando | Descrizione | Default value | Valore minimo | Valore massimo |
---|---|---|---|---|
--scale-rule-http-concurrency |
Quando il numero di richieste HTTP simultanee supera questo valore, viene aggiunta un'altra replica. Le repliche continuano ad aggiungere al pool fino all'importo max-replicas . |
10 | 1 | n/d |
az containerapp create \
--name <CONTAINER_APP_NAME> \
--resource-group <RESOURCE_GROUP> \
--environment <ENVIRONMENT_NAME> \
--image <CONTAINER_IMAGE_LOCATION>
--min-replicas 0 \
--max-replicas 5 \
--scale-rule-name azure-http-rule \
--scale-rule-type http \
--scale-rule-http-concurrency 100
Passare all'app contenitore nel portale di Azure
Selezionare Ridimensiona.
Selezionare Modifica e distribuzione.
Selezionare la scheda Scala .
Selezionare l'intervallo minimo e massimo di repliche.
Selezionare Aggiungi.
Nella casella Nome regola immettere un nome di regola.
Nell'elenco a discesa Tipo selezionare Scalabilità HTTP.
Nella casella Richieste simultanee immettere il numero desiderato di richieste simultanee per l'app contenitore.
TCP
Con una regola di ridimensionamento TCP, è possibile controllare la soglia delle connessioni TCP simultanee che determinano la scalabilità dell'app. Ogni 15 secondi, il numero di connessioni simultanee viene calcolato come numero di connessioni negli ultimi 15 secondi diviso per 15. I processi di App contenitore non supportano le regole di ridimensionamento TCP.
Nell'esempio seguente la revisione dell'app contenitore aumenta il numero di istanze fino a cinque repliche e può passare a zero. La soglia di ridimensionamento è impostata su 100 connessioni simultanee al secondo.
Esempio
La tcp
sezione definisce una regola di scalabilità TCP.
Proprietà Scale | Descrizione | Default value | Valore minimo | Valore massimo |
---|---|---|---|---|
concurrentConnections |
Quando il numero di connessioni TCP simultanee supera questo valore, viene aggiunta un'altra replica. Le repliche continuano a essere aggiunte fino all'importo maxReplicas man mano che aumenta il numero di connessioni simultanee. |
10 | 1 | n/d |
{
...
"resources": {
...
"properties": {
...
"template": {
...
"scale": {
"minReplicas": 0,
"maxReplicas": 5,
"rules": [{
"name": "tcp-rule",
"tcp": {
"metadata": {
"concurrentConnections": "100"
}
}
}]
}
}
}
}
}
Definire una regola di scalabilità TCP usando il --scale-rule-tcp-concurrency
parametro nei create
comandi o update
.
Parametro dell'interfaccia della riga di comando | Descrizione | Default value | Valore minimo | Valore massimo |
---|---|---|---|---|
--scale-rule-tcp-concurrency |
Quando il numero di connessioni TCP simultanee supera questo valore, viene aggiunta un'altra replica. Le repliche continuano a essere aggiunte fino all'importo max-replicas man mano che aumenta il numero di connessioni simultanee. |
10 | 1 | n/d |
az containerapp create \
--name <CONTAINER_APP_NAME> \
--resource-group <RESOURCE_GROUP> \
--environment <ENVIRONMENT_NAME> \
--image <CONTAINER_IMAGE_LOCATION>
--min-replicas 0 \
--max-replicas 5 \
--scale-rule-name azure-tcp-rule \
--scale-rule-type tcp \
--scale-rule-tcp-concurrency 100
Non supportato nella portale di Azure. Usare l'interfaccia della riga di comando di Azure o Azure Resource Manager per configurare una regola di scalabilità TCP.
Personalizzazione
È possibile creare una regola di ridimensionamento personalizzata di App contenitore in base a qualsiasi scaler KEDA basato su ScaledObject con queste impostazioni predefinite:
Impostazioni predefinite | Secondi |
---|---|
Intervallo di polling | 30 |
Periodo di raffreddamento | 300 |
Per i processi di App contenitore basate su eventi, è possibile creare una regola di ridimensionamento personalizzata basata su qualsiasi scaler KEDA basato su ScaledJob.
Nell'esempio seguente viene illustrato come creare una regola di scalabilità personalizzata.
Esempio
Questo esempio illustra come convertire un bus di servizio di Azure scaler in una regola di scalabilità di App contenitore, ma si usa lo stesso processo per qualsiasi altra specifica di scala KEDA basata su ScaledObject.
Per l'autenticazione, i parametri di autenticazione del scaler KEDA convertno in segreti di App contenitore.
La procedura seguente illustra come convertire un scaler KEDA in una regola di scalabilità di app contenitore. Questo frammento di codice è un estratto di un modello di Resource Manager per mostrare dove ogni sezione rientra nel contesto del modello complessivo.
{
...
"resources": {
...
"properties": {
...
"configuration": {
...
"secrets": [
{
"name": "<NAME>",
"value": "<VALUE>"
}
]
},
"template": {
...
"scale": {
"minReplicas": 0,
"maxReplicas": 5,
"rules": [
{
"name": "<RULE_NAME>",
"custom": {
"metadata": {
...
},
"auth": [
{
"secretRef": "<NAME>",
"triggerParameter": "<PARAMETER>"
}
]
}
}
]
}
}
}
}
}
Fare riferimento a questo estratto per informazioni di contesto sul modo in cui gli esempi seguenti si adattano al modello di Resource Manager.
Prima di tutto, si definiscono il tipo e i metadati della regola di scalabilità.
Nella specifica del scaler KEDA trovare il
type
valore.triggers: - type: azure-servicebus metadata: queueName: my-queue namespace: service-bus-namespace messageCount: "5"
Nel modello di Resource Manager immettere il valore del scaler
type
nellacustom.type
proprietà della regola di scalabilità.... "rules": [ { "name": "azure-servicebus-queue-rule", "custom": { "type": "azure-servicebus", "metadata": { "queueName": "my-queue", "namespace": "service-bus-namespace", "messageCount": "5" } } } ] ...
Nella specifica del scaler KEDA trovare i
metadata
valori.triggers: - type: azure-servicebus metadata: queueName: my-queue namespace: service-bus-namespace messageCount: "5"
Nel modello di Resource Manager aggiungere tutti i valori dei metadati alla
custom.metadata
sezione della regola di scalabilità.... "rules": [ { "name": "azure-servicebus-queue-rule", "custom": { "type": "azure-servicebus", "metadata": { "queueName": "my-queue", "namespace": "service-bus-namespace", "messageCount": "5" } } } ] ...
Autenticazione
Un scaler KEDA supporta l'uso di segreti in un triggerAuthentication a cui fa riferimento la authenticationRef
proprietà . È possibile eseguire il mapping dell'oggetto TriggerAuthentication alla regola di scalabilità di App contenitore.
Nota
Le regole di scalabilità di App contenitore supportano solo i riferimenti ai segreti. Altri tipi di autenticazione, ad esempio l'identità del pod, non sono supportati.
Trovare l'oggetto
TriggerAuthentication
a cui fa riferimento la specifica KEDAScaledObject
.Dalla specifica KEDA trovare ogni
secretTargetRef
TriggerAuthentication
oggetto e il relativo segreto associato.apiVersion: v1 kind: Secret metadata: name: my-secrets namespace: my-project type: Opaque data: connection-string-secret: <SERVICE_BUS_CONNECTION_STRING> --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: secretTargetRef: - parameter: connection name: my-secrets key: connection-string-secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-rule namespace: default spec: scaleTargetRef: name: my-scale-target triggers: - type: azure-servicebus metadata: queueName: my-queue namespace: service-bus-namespace messageCount: "5" authenticationRef: name: azure-servicebus-auth
Nel modello di Resource Manager aggiungere tutte le voci alla
auth
matrice della regola di scalabilità.Aggiungere un segreto alla matrice dell'app
secrets
contenitore contenente il valore del segreto.Impostare il valore della
triggerParameter
proprietà sul valore dellaTriggerAuthentication
proprietà della proprietà .key
Impostare il valore della
secretRef
proprietà sul nome del segreto app contenitore.
{ ... "resources": { ... "properties": { ... "configuration": { ... "secrets": [ { "name": "connection-string-secret", "value": "<SERVICE_BUS_CONNECTION_STRING>" } ] }, "template": { ... "scale": { "minReplicas": 0, "maxReplicas": 5, "rules": [ { "name": "azure-servicebus-queue-rule", "custom": { "type": "azure-servicebus", "metadata": { "queueName": "my-queue", "namespace": "service-bus-namespace", "messageCount": "5" }, "auth": [ { "secretRef": "connection-string-secret", "triggerParameter": "connection" } ] } } ] } } } } }
Alcuni scaler supportano i metadati con il
FromEnv
suffisso per fare riferimento a un valore in una variabile di ambiente. App contenitore esamina il primo contenitore elencato nel modello di Resource Manager per la variabile di ambiente.Per altre informazioni sulla sicurezza, vedere la sezione considerazioni.
Nella specifica del scaler KEDA trovare il
type
valore.triggers: - type: azure-servicebus metadata: queueName: my-queue namespace: service-bus-namespace messageCount: "5"
Nel comando dell'interfaccia della riga di comando impostare il
--scale-rule-type
parametro sul valore della specificatype
.az containerapp create \ --name <CONTAINER_APP_NAME> \ --resource-group <RESOURCE_GROUP> \ --environment <ENVIRONMENT_NAME> \ --image <CONTAINER_IMAGE_LOCATION> --min-replicas 0 \ --max-replicas 5 \ --secrets "connection-string-secret=<SERVICE_BUS_CONNECTION_STRING>" \ --scale-rule-name azure-servicebus-queue-rule \ --scale-rule-type azure-servicebus \ --scale-rule-metadata "queueName=my-queue" \ "namespace=service-bus-namespace" \ "messageCount=5" \ --scale-rule-auth "connection=connection-string-secret"
Nella specifica del scaler KEDA trovare i
metadata
valori.triggers: - type: azure-servicebus metadata: queueName: my-queue namespace: service-bus-namespace messageCount: "5"
Nel comando dell'interfaccia della riga di comando impostare il
--scale-rule-metadata
parametro sui valori dei metadati.È necessario trasformare i valori da un formato YAML a una coppia chiave/valore da usare nella riga di comando. Separare ogni coppia chiave/valore con uno spazio.
az containerapp create \ --name <CONTAINER_APP_NAME> \ --resource-group <RESOURCE_GROUP> \ --environment <ENVIRONMENT_NAME> \ --image <CONTAINER_IMAGE_LOCATION> --min-replicas 0 \ --max-replicas 5 \ --secrets "connection-string-secret=<SERVICE_BUS_CONNECTION_STRING>" \ --scale-rule-name azure-servicebus-queue-rule \ --scale-rule-type azure-servicebus \ --scale-rule-metadata "queueName=my-queue" \ "namespace=service-bus-namespace" \ "messageCount=5" \ --scale-rule-auth "connection=connection-string-secret"
Autenticazione
Un scaler KEDA supporta l'uso di segreti in un triggerAuthentication a cui fa riferimento la proprietà authenticationRef. È possibile eseguire il mapping dell'oggetto TriggerAuthentication alla regola di scalabilità di App contenitore.
Nota
Le regole di scalabilità di App contenitore supportano solo i riferimenti ai segreti. Altri tipi di autenticazione, ad esempio l'identità del pod, non sono supportati.
Trovare l'oggetto
TriggerAuthentication
a cui fa riferimento la specifica KEDAScaledObject
. Identificare ognisecretTargetRef
TriggerAuthentication
oggetto.apiVersion: v1 kind: Secret metadata: name: my-secrets namespace: my-project type: Opaque data: connection-string-secret: <SERVICE_BUS_CONNECTION_STRING> --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: secretTargetRef: - parameter: connection name: my-secrets key: connection-string-secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-rule namespace: default spec: scaleTargetRef: name: my-scale-target triggers: - type: azure-servicebus metadata: queueName: my-queue namespace: service-bus-namespace messageCount: "5" authenticationRef: name: azure-servicebus-auth
Nell'app contenitore creare i segreti che corrispondono alle
secretTargetRef
proprietà.Nel comando dell'interfaccia della riga di comando impostare i parametri per ogni
secretTargetRef
voce.Creare una voce privata con il
--secrets
parametro . Se sono presenti più segreti, separarli con uno spazio.Creare una voce di autenticazione con il
--scale-rule-auth
parametro . Se sono presenti più voci, separarle con uno spazio.
az containerapp create \ --name <CONTAINER_APP_NAME> \ --resource-group <RESOURCE_GROUP> \ --environment <ENVIRONMENT_NAME> \ --image <CONTAINER_IMAGE_LOCATION> --min-replicas 0 \ --max-replicas 5 \ --secrets "connection-string-secret=<SERVICE_BUS_CONNECTION_STRING>" \ --scale-rule-name azure-servicebus-queue-rule \ --scale-rule-type azure-servicebus \ --scale-rule-metadata "queueName=my-queue" \ "namespace=service-bus-namespace" \ "messageCount=5" \ --scale-rule-auth "connection=connection-string-secret"
Passare all'app contenitore nel portale di Azure.
Selezionare Ridimensiona.
Selezionare Modifica e distribuzione.
Selezionare la scheda Scalabilità e repliche .
Selezionare l'intervallo minimo e massimo di repliche.
Selezionare Aggiungi.
Nella casella Nome regola immettere un nome di regola.
Nell'elenco a discesa Tipo selezionare Personalizzato.
Nella specifica del scaler KEDA trovare il
type
valore.triggers: - type: azure-servicebus metadata: queueName: my-queue namespace: service-bus-namespace messageCount: "5"
Nella casella Tipo di regola personalizzata immettere il valore di scaler
type
.Nella specifica del scaler KEDA trovare i
metadata
valori.triggers: - type: azure-servicebus metadata: queueName: my-queue namespace: service-bus-namespace messageCount: "5"
Nel portale individuare la sezione Metadati e selezionare Aggiungi. Immettere il nome e il valore per ogni elemento nella sezione metadati della specifica KEDA
ScaledObject
.
Autenticazione
Un scaler KEDA supporta l'uso di segreti in un triggerAuthentication a cui fa riferimento la proprietà authenticationRef. È possibile eseguire il mapping dell'oggetto TriggerAuthentication alla regola di scalabilità di App contenitore.
Nota
Le regole di scalabilità di App contenitore supportano solo i riferimenti ai segreti. Altri tipi di autenticazione, ad esempio l'identità del pod, non sono supportati.
Nell'app contenitore creare i segreti a cui si vuole fare riferimento.
Trovare l'oggetto
TriggerAuthentication
a cui fa riferimento la specifica KEDAScaledObject
. Identificare ognisecretTargetRef
TriggerAuthentication
oggetto.apiVersion: v1 kind: Secret metadata: name: my-secrets namespace: my-project type: Opaque data: connection-string-secret: <SERVICE_BUS_CONNECTION_STRING> --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: secretTargetRef: - parameter: connection name: my-secrets key: connection-string-secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-rule namespace: default spec: scaleTargetRef: name: my-scale-target triggers: - type: azure-servicebus metadata: queueName: my-queue namespace: service-bus-namespace messageCount: "5" authenticationRef: name: azure-servicebus-auth
Nella sezione Autenticazione selezionare Aggiungi per creare una voce per ogni parametro KEDA
secretTargetRef
.
Regola di scalabilità predefinita
Se non si crea una regola di scalabilità, la regola di scalabilità predefinita viene applicata all'app contenitore.
Trigger | Numero minimo di repliche | Numero massimo di repliche |
---|---|---|
HTTP | 0 | 10 |
Importante
Assicurarsi di creare una regola di scalabilità o impostare minReplicas
su 1 o più se non si abilita l'ingresso. Se l'ingresso è disabilitato e non si definisce una minReplicas
regola di scalabilità personalizzata o , l'app contenitore verrà ridimensionata a zero e non sarà possibile avviare il backup.
Comportamento della scalabilità
Il comportamento di ridimensionamento ha le impostazioni predefinite seguenti:
Parametro | Valore |
---|---|
Intervallo di polling | 30 secondi |
Periodo di raffreddamento | 300 secondi |
Finestra di stabilizzazione con scalabilità orizzontale | 0 secondi |
Finestra di stabilizzazione ridimensionamento | 300 secondi |
Aumentare le prestazioni | 1, 4, 100% di corrente |
Passaggio di riduzione | 100% dell'attuale |
Algoritmo di ridimensionamento | desiredReplicas = ceil(currentMetricValue / targetMetricValue) |
- L'intervallo di polling è la frequenza con cui le origini eventi vengono sottoposte a query da KEDA. Questo valore non si applica alle regole di scalabilità HTTP e TCP.
- Il periodo di raffreddamento è il periodo di tempo trascorso l'ultimo evento osservato prima che l'applicazione si riduce al numero minimo di repliche.
- La finestra di stabilizzazione con scalabilità orizzontale è il tempo di attesa prima di eseguire una decisione di aumento delle prestazioni dopo che sono state soddisfatte le condizioni di aumento delle prestazioni.
- L'intervallo di stabilizzazione con riduzione delle prestazioni è il tempo di attesa prima di eseguire una decisione di riduzione quando sono state soddisfatte le condizioni di riduzione delle prestazioni.
- Il passaggio di aumento delle prestazioni è la frequenza con cui vengono aggiunte nuove istanze. Inizia con 1, 4, 8, 16, 32, ... fino al numero massimo di repliche configurato.
- Il passaggio di riduzione è la frequenza con cui vengono rimosse le repliche. Per impostazione predefinita, il 100% delle repliche che devono essere arrestate vengono rimosse.
- L'algoritmo di ridimensionamento è la formula usata per calcolare il numero di repliche desiderato corrente.
Esempio
Per la regola di scalabilità seguente:
"minReplicas": 0,
"maxReplicas": 20,
"rules": [
{
"name": "azure-servicebus-queue-rule",
"custom": {
"type": "azure-servicebus",
"metadata": {
"queueName": "my-queue",
"namespace": "service-bus-namespace",
"messageCount": "5"
}
}
}
]
Con il ridimensionamento orizzontale dell'app, KEDA inizia con una coda vuota ed esegue i passaggi seguenti:
- Controllare
my-queue
ogni 30 secondi. - Se la lunghezza della coda è uguale a 0, tornare a (1).
- Se la lunghezza della coda è > 0, ridimensionare l'app a 1.
- Se la lunghezza della coda è 50, calcolare
desiredReplicas = ceil(50/5) = 10
. - Ridimensionare l'app in
min(maxReplicaCount, desiredReplicas, max(4, 2*currentReplicaCount))
- Tornare a (1).
Se l'app è stata ridimensionata fino al numero massimo di repliche pari a 20, il ridimensionamento passa attraverso gli stessi passaggi precedenti. La riduzione delle prestazioni si verifica solo se la condizione è stata soddisfatta per 300 secondi (finestra di stabilizzazione ridotta). Quando la lunghezza della coda è 0, KEDA attende 300 secondi (periodo di raffreddamento) prima di ridimensionare l'app su 0.
Considerazioni
In modalità "più revisioni", l'aggiunta di un nuovo trigger di scalabilità crea una nuova revisione dell'applicazione, ma la revisione precedente rimane disponibile con le regole di scalabilità precedenti. Usare la pagina Gestione revisioni per gestire le allocazioni del traffico.
Non vengono addebitati addebiti per l'utilizzo quando un'applicazione viene ridimensionata a zero. Per altre informazioni sui prezzi, vedere Fatturazione nelle app Azure Container.
È necessario abilitare la protezione dei dati per tutte le app .NET nelle app Contenitore di Azure. Per informazioni dettagliate, vedere Distribuzione e ridimensionamento di un'app ASP.NET Core in App Azure Container.
Limitazioni note
La scalabilità verticale non è supportata.
Le quantità di replica sono un importo di destinazione, non una garanzia.
Se si usano attori Dapr per gestire gli stati, tenere presente che il ridimensionamento a zero non è supportato. Dapr usa attori virtuali per gestire le chiamate asincrone, il che significa che la rappresentazione in memoria non è associata alla propria identità o durata.