Trucchi e suggerimenti
Questo documento descrive le best practice per la progettazione, l'implementazione, il test e il deployment di Cloud Run Functions.
Correttezza
Questa sezione descrive le best practice generali per la progettazione e l'implementazione di Cloud Run functions.
Scrivere funzioni idempotenti
Le funzioni devono produrre lo stesso risultato anche se vengono chiamate più volte. In questo modo puoi riprovare un'invocazione se la precedente non va a buon fine a metà del codice. Per saperne di più, consulta Riprovare le funzioni basate su eventi.
Assicurati che le funzioni HTTP inviino una risposta HTTP
Se la funzione è attivata tramite HTTP, ricorda di inviare una risposta HTTP, come mostrato di seguito. In caso contrario, la funzione verrà eseguita fino al timeout. In questo caso, ti verrà addebitato l'intero periodo di timeout. I timeout possono anche causare un comportamento imprevedibile o avvii a freddo nelle invocazioni successive, con conseguente comportamento imprevedibile o latenza aggiuntiva.
Node.js
Python
Go
Java
C#
using Google.Cloud.Functions.Framework; using Microsoft.AspNetCore.Http; using Microsoft.Extensions.Logging; using System.IO; using System.Text.Json; using System.Threading.Tasks; namespace HelloHttp; public class Function : IHttpFunction { private readonly ILogger _logger; public Function(ILogger<Function> logger) => _logger = logger; public async Task HandleAsync(HttpContext context) { HttpRequest request = context.Request; // Check URL parameters for "name" field // "world" is the default value string name = ((string) request.Query["name"]) ?? "world"; // If there's a body, parse it as JSON and check for "name" field. using TextReader reader = new StreamReader(request.Body); string text = await reader.ReadToEndAsync(); if (text.Length > 0) { try { JsonElement json = JsonSerializer.Deserialize<JsonElement>(text); if (json.TryGetProperty("name", out JsonElement nameElement) && nameElement.ValueKind == JsonValueKind.String) { name = nameElement.GetString(); } } catch (JsonException parseException) { _logger.LogError(parseException, "Error parsing JSON request"); } } await context.Response.WriteAsync($"Hello {name}!", context.RequestAborted); } }
Ruby
PHP
<?php use Google\CloudFunctions\FunctionsFramework; use Psr\Http\Message\ServerRequestInterface; // Register the function with Functions Framework. // This enables omitting the `FUNCTIONS_SIGNATURE_TYPE=http` environment // variable when deploying. The `FUNCTION_TARGET` environment variable should // match the first parameter. FunctionsFramework::http('helloHttp', 'helloHttp'); function helloHttp(ServerRequestInterface $request): string { $name = 'World'; $body = $request->getBody()->getContents(); if (!empty($body)) { $json = json_decode($body, true); if (json_last_error() != JSON_ERROR_NONE) { throw new RuntimeException(sprintf( 'Could not parse body: %s', json_last_error_msg() )); } $name = $json['name'] ?? $name; } $queryString = $request->getQueryParams(); $name = $queryString['name'] ?? $name; return sprintf('Hello, %s!', htmlspecialchars($name)); }
Non avviare attività in background
L'attività in background è tutto ciò che accade dopo la chiusura della funzione.
Una chiamata di funzione termina quando la funzione restituisce o segnala
il completamento, ad esempio chiamando l'argomento callback
nelle funzioni basate su eventi Node.js. Qualsiasi codice eseguito dopo l'interruzione normale non può accedere alla CPU e
non farà alcun progresso.
Inoltre, quando una chiamata successiva viene eseguita nello stesso ambiente,
l'attività in background riprende, interferendo con la nuova chiamata. Ciò potrebbe
comportare errori e comportamenti imprevisti difficili da diagnosticare. L'accesso
alla rete dopo la terminazione di una funzione di solito comporta il ripristino delle connessioni
(codice di errore ECONNRESET
).
L'attività in background può spesso essere rilevata nei log delle singole chiamate, trovando qualsiasi elemento registrato dopo la riga che indica che la chiamata è terminata. L'attività in background a volte può essere nascosta più in profondità nel codice, soprattutto quando sono presenti operazioni asincrone come callback o timer. Controlla il codice per assicurarti che tutte le operazioni asincrone vengano completate prima di terminare la funzione.
Eliminare sempre i file temporanei
Lo spazio di archiviazione del disco locale nella directory temporanea è un file system in memoria. I file che scrivi consumano la memoria disponibile per la tua funzione e a volte persistono tra le chiamate. Se non elimini esplicitamente questi file, alla fine potresti riscontrare un errore di memoria insufficiente e un successivo riavvio a freddo.
Puoi visualizzare la memoria utilizzata da una singola funzione selezionandola nell'elenco delle funzioni nella consoleGoogle Cloud e scegliendo il grafico Utilizzo della memoria.
Non tentare di scrivere al di fuori della directory temporanea e assicurati di utilizzare metodi indipendenti dalla piattaforma/dal sistema operativo per creare i percorsi dei file.
Puoi ridurre i requisiti di memoria durante l'elaborazione di file più grandi utilizzando il pipelining. Ad esempio, puoi elaborare un file su Cloud Storage creando un flusso di lettura, passandolo attraverso un processo basato sul flusso e scrivendo il flusso di output direttamente in Cloud Storage.
Framework di Functions
Quando esegui il deployment di una funzione, Functions Framework viene aggiunto automaticamente come dipendenza, utilizzando la sua versione attuale. Per garantire che le stesse dipendenze vengano installate in modo coerente in ambienti diversi, ti consigliamo di bloccare la funzione su una versione specifica di Functions Framework.
A questo scopo, includi la versione che preferisci nel file di blocco pertinente
(ad esempio, package-lock.json
per Node.js o requirements.txt
per Python).
Strumenti
Questa sezione fornisce linee guida su come utilizzare gli strumenti per implementare, testare e interagire con le funzioni Cloud Run.
Sviluppo locale
Il deployment della funzione richiede un po' di tempo, quindi spesso è più veloce testare il codice della funzione localmente.
Segnalazione degli errori
Nei linguaggi che utilizzano la gestione delle eccezioni, non generare eccezioni non rilevate, perché forzano gli avvii a freddo nelle invocazioni future. Consulta la guida di Error Reporting per informazioni su come segnalare correttamente gli errori.
Non uscire manualmente
L'uscita manuale può causare un comportamento imprevisto. Utilizza invece le seguenti espressioni idiomatiche specifiche per la lingua:
Node.js
Non utilizzare process.exit()
. Le funzioni HTTP devono inviare una risposta con
res.status(200).send(message)
, mentre le funzioni basate sugli eventi
termineranno una volta restituite (in modo implicito o esplicito).
Python
Non utilizzare sys.exit()
. Le funzioni HTTP devono restituire esplicitamente
una risposta come stringa e le funzioni basate su eventi vengono chiuse una volta
che restituiscono un valore (in modo implicito o esplicito).
Vai
Non utilizzare os.Exit()
. Le funzioni HTTP devono restituire esplicitamente
una risposta come stringa e le funzioni basate su eventi vengono chiuse una volta
che restituiscono un valore (in modo implicito o esplicito).
Java
Non utilizzare System.exit()
. Le funzioni HTTP devono inviare una risposta con
response.getWriter().write(message)
, mentre le funzioni basate sugli eventi
termineranno una volta restituite (in modo implicito o esplicito).
C#
Non utilizzare System.Environment.Exit()
. Le funzioni HTTP devono inviare una risposta con
context.Response.WriteAsync(message)
, mentre le funzioni basate sugli eventi
termineranno una volta restituite (in modo implicito o esplicito).
Ruby
Non utilizzare exit()
o abort()
. Le funzioni HTTP devono restituire esplicitamente
una risposta come stringa e le funzioni basate su eventi vengono chiuse una volta
che restituiscono un valore (in modo implicito o esplicito).
PHP
Non utilizzare exit()
o die()
. Le funzioni HTTP devono restituire esplicitamente
una risposta come stringa e le funzioni basate su eventi vengono chiuse una volta
che restituiscono un valore (in modo implicito o esplicito).
Utilizzare SendGrid per inviare email
Cloud Run Functions non consente connessioni in uscita sulla porta 25, pertanto non puoi stabilire connessioni non sicure a un server SMTP. Il modo consigliato per inviare email è utilizzare SendGrid. Puoi trovare altre opzioni per l'invio di email nel tutorial Invio di email da un'istanza per Compute Engine.
Prestazioni
Questa sezione descrive le best practice per ottimizzare il rendimento.
Utilizzare le dipendenze in modo strategico
Poiché le funzioni sono stateless, l'ambiente di esecuzione viene spesso inizializzato da zero (durante quello che è noto come avvio a freddo). Quando si verifica un avvio a freddo, viene valutato il contesto globale della funzione.
Se le tue funzioni importano moduli, il tempo di caricamento di questi moduli può aumentare la latenza di chiamata durante un avvio a freddo. Puoi ridurre questa latenza, nonché il tempo necessario per il deployment della funzione, caricando correttamente le dipendenze e non caricando le dipendenze che la funzione non utilizza.
Utilizza le variabili globali per riutilizzare gli oggetti nelle chiamate future
Non è garantito che lo stato di una funzione venga conservato per le chiamate future. Tuttavia, Cloud Run Functions spesso ricicla l'ambiente di esecuzione di una chiamata precedente. Se dichiari una variabile nell'ambito globale, il suo valore può essere riutilizzato nelle invocazioni successive senza dover essere ricalcolato.
In questo modo puoi memorizzare nella cache gli oggetti che potrebbero essere costosi da ricreare a ogni invocazione di funzione. Lo spostamento di questi oggetti dal corpo della funzione all'ambito globale può comportare miglioramenti significativi delle prestazioni. Il seguente esempio crea un oggetto pesante una sola volta per istanza di funzione e lo condivide tra tutte le chiamate di funzione che raggiungono l'istanza specificata:
Node.js
Python
Go
Java
C#
using Google.Cloud.Functions.Framework; using Microsoft.AspNetCore.Http; using System.Linq; using System.Threading.Tasks; namespace Scopes; public class Function : IHttpFunction { // Global (server-wide) scope. // This computation runs at server cold-start. // Warning: Class variables used in functions code must be thread-safe. private static readonly int GlobalVariable = HeavyComputation(); // Note that one instance of this class (Function) is created per invocation, // so calling HeavyComputation in the constructor would not have the same // benefit. public async Task HandleAsync(HttpContext context) { // Per-function-invocation scope. // This computation runs every time this function is called. int functionVariable = LightComputation(); await context.Response.WriteAsync( $"Global: {GlobalVariable}; function: {functionVariable}", context.RequestAborted); } private static int LightComputation() { int[] numbers = { 1, 2, 3, 4, 5, 6, 7, 8, 9 }; return numbers.Sum(); } private static int HeavyComputation() { int[] numbers = { 1, 2, 3, 4, 5, 6, 7, 8, 9 }; return numbers.Aggregate((current, next) => current * next); } }
Ruby
PHP
use Psr\Http\Message\ServerRequestInterface; function scopeDemo(ServerRequestInterface $request): string { // Heavy computations should be cached between invocations. // The PHP runtime does NOT preserve variables between invocations, so we // must write their values to a file or otherwise cache them. // (All writable directories in Cloud Functions are in-memory, so // file-based caching operations are typically fast.) // You can also use PSR-6 caching libraries for this task: // https://packagist.org/providers/psr/cache-implementation $cachePath = sys_get_temp_dir() . '/cached_value.txt'; $response = ''; if (file_exists($cachePath)) { // Read cached value from file, using file locking to prevent race // conditions between function executions. $response .= 'Reading cached value.' . PHP_EOL; $fh = fopen($cachePath, 'r'); flock($fh, LOCK_EX); $instanceVar = stream_get_contents($fh); flock($fh, LOCK_UN); } else { // Compute cached value + write to file, using file locking to prevent // race conditions between function executions. $response .= 'Cache empty, computing value.' . PHP_EOL; $instanceVar = _heavyComputation(); file_put_contents($cachePath, $instanceVar, LOCK_EX); } // Lighter computations can re-run on each function invocation. $functionVar = _lightComputation(); $response .= 'Per instance: ' . $instanceVar . PHP_EOL; $response .= 'Per function: ' . $functionVar . PHP_EOL; return $response; }
È particolarmente importante memorizzare nella cache le connessioni di rete, i riferimenti alle librerie e gli oggetti client API nell'ambito globale. Per esempi, consulta la sezione Ottimizzare il networking.
Esegui l'inizializzazione lazy delle variabili globali
Se inizializzi le variabili nell'ambito globale, il codice di inizializzazione verrà sempre
eseguito tramite una chiamata di avviamento a freddo, aumentando la latenza della funzione.
In alcuni casi, ciò causa timeout intermittenti ai servizi chiamati
se non vengono gestiti in modo appropriato in un blocco try
/catch
. Se
alcuni oggetti non vengono utilizzati in tutti i percorsi del codice, valuta la possibilità di inizializzarli in modo differito
su richiesta:
Node.js
Python
Go
Java
C#
using Google.Cloud.Functions.Framework; using Microsoft.AspNetCore.Http; using System; using System.Linq; using System.Threading; using System.Threading.Tasks; namespace LazyFields; public class Function : IHttpFunction { // This computation runs at server cold-start. // Warning: Class variables used in functions code must be thread-safe. private static readonly int NonLazyGlobal = FileWideComputation(); // This variable is initialized at server cold-start, but the // computation is only performed when the function needs the result. private static readonly Lazy<int> LazyGlobal = new Lazy<int>( FunctionSpecificComputation, LazyThreadSafetyMode.ExecutionAndPublication); public async Task HandleAsync(HttpContext context) { // In a more complex function, there might be some paths that use LazyGlobal.Value, // and others that don't. The computation is only performed when necessary, and // only once per server. await context.Response.WriteAsync( $"Lazy global: {LazyGlobal.Value}; non-lazy global: {NonLazyGlobal}", context.RequestAborted); } private static int FunctionSpecificComputation() { int[] numbers = { 1, 2, 3, 4, 5, 6, 7, 8, 9 }; return numbers.Sum(); } private static int FileWideComputation() { int[] numbers = { 1, 2, 3, 4, 5, 6, 7, 8, 9 }; return numbers.Aggregate((current, next) => current * next); } }
Ruby
PHP
Le funzioni PHP non possono conservare le variabili tra le richieste. L'esempio di ambiti riportato sopra utilizza il caricamento differito per memorizzare nella cache i valori delle variabili globali in un file.
Ciò è particolarmente importante se definisci più funzioni in un unico file e funzioni diverse utilizzano variabili diverse. A meno che tu non utilizzi l'inizializzazione differita, potresti sprecare risorse per variabili inizializzate ma mai utilizzate.
Ridurre gli avvii a freddo impostando un numero minimo di istanze
Per impostazione predefinita, Cloud Run Functions adatta il numero di istanze in base al numero di richieste in entrata. Puoi modificare questo comportamento predefinito impostando un numero minimo di istanze che le funzioni Cloud Run devono mantenere pronte per gestire le richieste. L'impostazione di un numero minimo di istanze riduce gli avvii a freddo della tua applicazione. Ti consigliamo di impostare un numero minimo di istanze se la tua applicazione è sensibile alla latenza.
Per scoprire come impostare un numero minimo di istanze, consulta Utilizzare le istanze minime.
Risorse aggiuntive
Scopri di più sull'ottimizzazione del rendimento nel video "Google Cloud Performance Atlas" Tempo di avvio a freddo di Cloud Run Functions.