Come funziona un'invocazione

your code ── invoke('hello') ──▶ gateway (data plane)
                                   • checks the key and the user's token
                                   • finds the project from the host
                                   • adds x-aura-role, x-aura-user-id, x-aura-project-id
                                   │  message bus (request / reply)
                                   ▼
                           functions service
                                   • access policy: only invoke is public
                                   • reads the function, reserves one invocation of the plan quota
                                   │  HTTP
                                   ▼
                            edge runtime
                                   • loads code, limits and variables
                                   • starts an isolated V8 worker
                                   • rebuilds the request you described
                                   ▼
                             your function ── Response ──▶ back along the same path

Il gateway e il servizio funzioni dialogano tramite un bus di messaggi. Un messaggio su quel bus ha un limite di dimensione, motivo per cui una richiesta o una risposta superiore a circa 256 KiB non viene superata: vedere limiti.

• Un lavoratore per chiamata. L'edge runtime avvia un nuovo lavoratore V8 isolato per ogni invocazione, con il limite di memoria e il timeout della funzione. Niente in memoria sopravvive da una chiamata alla successiva: non mantenere lo stato in una variabile. Usa il tuo database o spazio di archiviazione.
• Il codice viene memorizzato nella cache per alcuni secondi. Il runtime conserva il codice e i limiti di una funzione per 5 secondi e li rilascia durante la distribuzione. Le variabili vengono lette ad ogni chiamata.
• La tua richiesta è stata ricostruita. Il runtime crea la richiesta che hai descritto (method, path, headers, body) e la passa al tuo gestore Deno.serve. Una funzione quindi si comporta come qualsiasi server HTTP.
• Il runtime impone il timeout. Allo scadere di timeout_secs cancella il lavoratore; il chiamante vede un errore dopo circa quel ritardo.
• Le funzioni WASM vengono eseguite all'interno del servizio stesso, con limiti di memoria, tempo e istruzioni. Una funzione WASM può riportare le righe di registro, che appaiono nel campo logs della risposta; una funzione Deno non può.

Il servizio ha due modi per restituire la risposta della funzione, scelta dall'intestazione della richiesta X-Aurabase-Invoke-Mode.

La busta esiste in modo che una risposta JSON possa contenere lo stato, le intestazioni e la durata della chiamata. Il suo limite è che i byte non possono viaggiare in JSON: ecco perché una risposta binaria necessita della modalità raw. L'SDK sceglie la modalità da responseType.

In modalità raw il servizio aggiunge x-aurabase-invoke-origin: function alle risposte della tua funzione. Un errore che proviene dal gateway o dal runtime non lo trasporta. Questo è il modo in cui l'SDK separa FunctionsHttpError (la tua funzione ha risposto) da FunctionsRelayError (la piattaforma non è riuscita).

Tre timeout sono annidati in modo che nessuno termini prima di quello al suo interno:

gateway 380 s  ⊃  message bus 370 s  ⊃  function timeout_secs (≤ 300 s) + margin

Il servizio attende il runtime per timeout_secs più un margine. Poiché il runtime annulla il lavoratore in timeout_secs, normalmente viene visualizzato un errore dalla funzione in quel momento e un 504 TIMEOUT solo se il runtime stesso smette di rispondere. Un 504 significa quindi che la funzione è stata avviata e potrebbe aver avuto degli effetti: non ripetere alla cieca una chiamata non idempotente.

Misurazione e quota:

1. Prima della chiamata, il servizio riserva una chiamata dalla quota del piano. Se la quota è esaurita, la chiamata si interrompe qui con 403.
2. Dopo la chiamata registra l'invocazione e la sua durata in millisecondi.
3. Se la chiamata fallisce prima che la tua funzione risponda, la prenotazione viene rilasciata e non viene conteggiato nulla.

• Mantieni ogni chiamata breve e senza stato. Per lavori lunghi, accoda un lavoro.
• Mantenere richieste e risposte piccole; inserisci i file in Archiviazione e passa un riferimento.
• Rendi le funzioni idempotenti: un lavoro ripetuto, un tentativo del client dopo un errore di rete o una consegna cron duplicata possono eseguire il codice due volte.
• Autorizza sulle intestazioni di identità della piattaforma, perché sono gli unici valori che il chiamante non può falsificare. Vedi sicurezza.
• Misura la tua latenza: ogni chiamata paga l'avvio di un lavoratore. Una funzione minima ha riportato duration_ms: 74 su uno stack locale.