Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Le gestionnaire de fonction Lambda est la méthode dans votre code de fonction qui traite les événements. Lorsque votre fonction est invoquée, Lambda exécute la méthode du gestionnaire. Votre fonction s’exécute jusqu’à ce que le gestionnaire renvoie une réponse, se ferme ou expire.
Cette page explique comment utiliser les gestionnaires de fonctions Lambda en C# pour fonctionner avec l'environnement d'exécution géré .NET, y compris les options de configuration de projet, les conventions de dénomination et les meilleures pratiques. Cette page inclut également un exemple de fonction Lambda C# qui prend des informations sur une commande, produit un reçu sous forme de fichier texte et place ce fichier dans un bucket Amazon Simple Storage Service (S3). Pour plus d’informations sur le déploiement de votre fonction après l’avoir écrite, consultez Créez et déployez des fonctions Lambda C# à l’aide des archives de fichiers .zip ou Déployer des fonctions Lambda .NET avec des images conteneurs.
Rubriques
Configuration de votre projet de gestionnaire C#
Lorsque vous utilisez des fonctions Lambda en C#, le processus consiste à écrire votre code, puis à le déployer sur Lambda. Il existe deux modèles d'exécution différents pour déployer des fonctions Lambda dans .NET : l'approche de bibliothèque de classes et l'approche d'assemblage exécutable.
Dans l'approche de bibliothèque de classes, vous empaquetez votre code de fonction sous forme d'assemblage .NET (.dll) et vous le déployez sur Lambda avec le runtime géré .NET ()dotnet8. Pour le nom du gestionnaire, Lambda attend une chaîne au format. AssemblyName::Namespace.Classname::Methodname Pendant la phase d'initialisation de la fonction, la classe de votre fonction est initialisée et tout code contenu dans le constructeur est exécuté.
Dans l'approche d'assemblage exécutable, vous utilisez la fonctionnalité d'instructions de haut niveaudotnet8). Pour le nom du gestionnaire, vous fournissez à Lambda le nom de l'assembly exécutable à exécuter.
L'exemple principal de cette page illustre l'approche de la bibliothèque de classes. Vous pouvez initialiser votre projet Lambda C# de différentes manières, mais la méthode la plus simple consiste à utiliser la CLI .NET avec la CLI. Amazon.Lambda.Tools Configurez la Amazon.Lambda.Tools CLI en suivant les étapes décrites dansConfiguration de votre environnement de développement .NET. Initialisez ensuite votre projet à l'aide de la commande suivante :
dotnet new lambda.EmptyFunction --name ExampleCSCette commande génère la structure de fichier suivante :
/project-root └ src └ ExampleCS └ Function.cs (contains main handler) └ Readme.md └ aws-lambda-tools-defaults.json └ ExampleCS.csproj └ test └ ExampleCS.Tests └ FunctionTest.cs (contains main handler) └ ExampleCS.Tests.csproj
Dans cette structure de fichier, la logique de gestion principale de votre fonction réside dans le Function.cs fichier.
Exemple de code de fonction Lambda en C#
L'exemple de code de fonction Lambda C# suivant prend en compte les informations relatives à une commande, produit un reçu sous forme de fichier texte et place ce fichier dans un compartiment Amazon S3.
Exemple Fonction Lambda Function.cs
using System;
using System.Text;
using System.Threading.Tasks;
using Amazon.Lambda.Core;
using Amazon.S3;
using Amazon.S3.Model;
// Assembly attribute to enable Lambda function logging
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace ExampleLambda;
public class Order
{
public string OrderId { get; set; } = string.Empty;
public double Amount { get; set; }
public string Item { get; set; } = string.Empty;
}
public class OrderHandler
{
private static readonly AmazonS3Client s3Client = new();
public async Task<string> HandleRequest(Order order, ILambdaContext context)
{
try
{
string? bucketName = Environment.GetEnvironmentVariable("RECEIPT_BUCKET");
if (string.IsNullOrWhiteSpace(bucketName))
{
throw new ArgumentException("RECEIPT_BUCKET environment variable is not set");
}
string receiptContent = $"OrderID: {order.OrderId}\nAmount: ${order.Amount:F2}\nItem: {order.Item}";
string key = $"receipts/{order.OrderId}.txt";
await UploadReceiptToS3(bucketName, key, receiptContent);
context.Logger.LogInformation($"Successfully processed order {order.OrderId} and stored receipt in S3 bucket {bucketName}");
return "Success";
}
catch (Exception ex)
{
context.Logger.LogError($"Failed to process order: {ex.Message}");
throw;
}
}
private async Task UploadReceiptToS3(string bucketName, string key, string receiptContent)
{
try
{
var putRequest = new PutObjectRequest
{
BucketName = bucketName,
Key = key,
ContentBody = receiptContent,
ContentType = "text/plain"
};
await s3Client.PutObjectAsync(putRequest);
}
catch (AmazonS3Exception ex)
{
throw new Exception($"Failed to upload receipt to S3: {ex.Message}", ex);
}
}
}Ce fichier Function.cs comprend les sections suivantes :
-
usinginstructions : utilisez-les pour importer les classes C# requises par votre fonction Lambda. -
[assembly: LambdaSerializer(...)]:LambdaSerializerest un attribut d'assemblage qui indique à Lambda de convertir automatiquement les charges utiles des événements JSON en objets C# avant de les transmettre à votre fonction. -
namespace ExampleLambda: Ceci définit l'espace de noms. En C#, le nom de l'espace de noms ne doit pas nécessairement correspondre au nom du fichier. -
public class Order {...}: Ceci définit la forme de l'événement d'entrée attendu. -
public class OrderHandler {...}: Ceci définit votre classe C#. Vous y définirez la méthode du gestionnaire principal et toutes les autres méthodes auxiliaires. -
private static readonly AmazonS3Client s3Client = new();: Cela initialise un client Amazon S3 avec la chaîne de fournisseurs d'informations d'identification par défaut, en dehors de la méthode du gestionnaire principal. Cela oblige Lambda à exécuter ce code pendant la phase d'initialisation. -
public async ... HandleRequest (Order order, ILambdaContext context): il s’agit de la méthode de gestion principale, qui contient la logique principale de votre application. -
private async Task UploadReceiptToS3(...) {}: il s’agit d’une méthode auxiliaire référencée par la méthode de gestion principalehandleRequest.
Comme cette fonction nécessite un client du SDK Amazon S3, vous devez l'ajouter aux dépendances de votre projet. Vous pouvez le faire en accédant à la commande suivante src/ExampleCS et en l'exécutant :
dotnet add package AWSSDK.S3Par défaut, le aws-lambda-tools-defaults.json fichier généré ne contient profile aucune region information relative à votre fonction. Mettez également à jour la function-handler chaîne avec la valeur correcte (ExampleCS::ExampleLambda.OrderHandler::HandleRequest). Vous pouvez effectuer cette mise à jour manuellement et ajouter les métadonnées nécessaires pour utiliser un profil d'identification et une région spécifiques pour votre fonction. Par exemple, votre aws-lambda-tools-defaults.json fichier doit ressembler à ceci :
{
"Information": [
"This file provides default values for the deployment wizard inside Visual Studio and the AWS Lambda commands added to the .NET Core CLI.",
"To learn more about the Lambda commands with the .NET Core CLI execute the following command at the command line in the project root directory.",
"dotnet lambda help",
"All the command line options for the Lambda command can be specified in this file."
],
"profile": "default",
"region": "us-east-1",
"configuration": "Release",
"function-architecture": "x86_64",
"function-runtime": "dotnet8",
"function-memory-size": 512,
"function-timeout": 30,
"function-handler": "ExampleCS::ExampleLambda.OrderHandler::HandleRequest"
}Pour que cette fonction fonctionne correctement, son rôle d’exécution doit autoriser l’action s3:PutObject. Si vous utilisez la dotnet lambda deploy-function commande (c'est-à-diredotnet lambda deploy-function ExampleCS), la AWSLambdaExecute politique indiquée dans les instructions de la CLI contient les autorisations nécessaires pour que vous puissiez invoquer cette fonction avec succès.
Assurez-vous également que
Enfin, assurez-vous de définir la variable d'RECEIPT_BUCKETenvironnement. Après une invocation réussie, le compartiment Amazon S3 doit contenir un fichier de reçu.
Gestionnaires de bibliothèques de classes
L'exemple de code principal de cette page illustre un gestionnaire de bibliothèque de classes. Les gestionnaires de bibliothèques de classes ont la structure suivante :
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace NAMESPACE;
...
public class CLASSNAME {
public async Task<string> METHODNAME (...) {
...
}
}Lorsque vous créez une fonction Lambda, vous devez fournir à Lambda des informations sur le gestionnaire de votre fonction sous la forme d'une chaîne dans le champ Handler. Cette chaîne indique à Lambda quelle méthode de votre code doit être exécutée lorsque votre fonction est invoquée. En C#, pour les gestionnaires de bibliothèques de classes, le format de la chaîne du gestionnaire est ASSEMBLY::TYPE::METHOD le suivant :
-
ASSEMBLYest le nom du fichier d'assemblage .NET de votre application. Si vous utilisez laAmazon.Lambda.ToolsCLI pour créer votre application et que vous ne définissez pas le nom de l'assembly à l'aide de laAssemblyNamepropriété du.csprojfichier, ilASSEMBLYs'agit simplement du nom de votre.csprojfichier. -
TYPEest le nom complet du type de gestionnaire, qui estNAMESPACE.CLASSNAME. -
METHODest le nom de la principale méthode de gestion de votre code, qui estMETHODNAME.
Pour l'exemple de code principal de cette page, si l'assemblage est nomméExampleCS, la chaîne complète du gestionnaire estExampleCS::ExampleLambda.OrderHandler::HandleRequest.
Gestionnaires d'assemblages exécutables
Vous pouvez également définir des fonctions Lambda en C# sous forme d'assemblage exécutable. Les gestionnaires d'assemblages exécutables utilisent la fonctionnalité d'instructions de haut niveau de C#, dans laquelle le compilateur génère la Main() méthode et y insère le code de votre fonction. Lors de l'utilisation d'assemblages exécutables, l'exécution Lambda doit être amorcée. Pour ce faire, utilisez la LambdaBootstrapBuilder.Create méthode contenue dans votre code. Les entrées de cette méthode sont la fonction de gestion principale ainsi que le sérialiseur Lambda à utiliser. Voici un exemple de gestionnaire d'assemblage exécutable en C# :
namespace GetProductHandler;
IDatabaseRepository repo = new DatabaseRepository();
await LambdaBootstrapBuilder.Create<APIGatewayProxyRequest>(Handler, new DefaultLambdaJsonSerializer())
.Build()
.RunAsync();
async Task<APIGatewayProxyResponse> Handler(APIGatewayProxyRequest apigProxyEvent, ILambdaContext context)
{
var id = apigProxyEvent.PathParameters["id"];
var databaseRecord = await this.repo.GetById(id);
return new APIGatewayProxyResponse
{
StatusCode = (int)HttpStatusCode.OK,
Body = JsonSerializer.Serialize(databaseRecord)
};
};Dans le champ Handler pour les gestionnaires d'assemblages exécutables, la chaîne de gestionnaire qui indique à Lambda comment exécuter votre code est le nom de l'assemblage. Dans cet exemple, c'estGetProductHandler.
Signatures de gestionnaire valides pour les fonctions C#
En C#, les signatures valides du gestionnaire Lambda prennent entre 0 et 2 arguments. Généralement, la signature de votre gestionnaire comporte deux arguments, comme indiqué dans l'exemple principal :
public async Task<string> HandleRequest(Order order, ILambdaContext context)Lorsque vous fournissez deux arguments, le premier argument doit être l'entrée de l'événement et le second doit être l'objet de contexte Lambda. Les deux arguments sont facultatifs. Par exemple, les signatures de gestionnaire Lambda suivantes sont également valides en C# :
-
public async Task<string> HandleRequest() -
public async Task<string> HandleRequest(Order order) -
public async Task<string> HandleRequest(ILambdaContext context)
Outre la syntaxe de base de la signature du gestionnaire, il existe quelques restrictions supplémentaires :
-
Vous ne pouvez pas utiliser le
unsafemot clé dans la signature du gestionnaire. Cependant, vous pouvez utiliser leunsafecontexte de la méthode du gestionnaire et de ses dépendances. Pour plus d'informations, consultez unsafe (référence C#)sur le site Web de documentation Microsoft. -
Le gestionnaire ne doit pas utiliser le
paramsmot-clé, ni l'utiliserArgIteratorcomme paramètre d'entrée ou de retour. Ces mots clés prennent en charge un nombre variable de paramètres. Le nombre maximum d'arguments que votre gestionnaire peut accepter est de deux. -
Le gestionnaire n'est peut-être pas une méthode générique. En d'autres termes, il ne peut pas utiliser de paramètres de type génériques tels que
<T>. -
Lambda ne prend pas en charge les gestionnaires asynchrones contenant
async voidla signature.
Convention de nommage du gestionnaire
Les gestionnaires Lambda en C# ne sont pas soumis à des restrictions de dénomination strictes. Cependant, vous devez vous assurer de fournir la chaîne de gestionnaire correcte à Lambda lorsque vous déployez votre fonction. La bonne chaîne de gestionnaire dépend du fait que vous déployez un gestionnaire de bibliothèque de classes ou un gestionnaire d'assemblage exécutable.
Bien que vous puissiez utiliser n'importe quel nom pour votre gestionnaire, les noms de fonctions en C# sont généralement disponibles. PascalCase De plus, même si le nom du fichier ne doit pas nécessairement correspondre au nom de la classe ou au nom du gestionnaire, il est généralement recommandé d'utiliser un nom de fichier comme OrderHandler.cs si le nom de votre classe l'était. OrderHandler Par exemple, dans cet exemple, vous pouvez modifier le nom de fichier de Function.cs àOrderHandler.cs.
Sérialisation dans les fonctions Lambda en C#
JSON est le format d’entrée le plus courant et standard pour les fonctions Lambda. Dans cet exemple, la fonction exige une entrée similaire à l’exemple suivant :
{
"orderId": "12345",
"amount": 199.99,
"item": "Wireless Headphones"
}En C#, vous pouvez définir la forme de l'événement d'entrée attendu dans une classe. Dans cet exemple, nous définissons la Order classe pour modéliser cette entrée :
public class Order
{
public string OrderId { get; set; } = string.Empty;
public double Amount { get; set; }
public string Item { get; set; } = string.Empty;
}Si votre fonction Lambda utilise des types d'entrée ou de sortie autres qu'un objet Stream, vous devez ajouter une bibliothèque de sérialisation à votre application. Cela vous permet de convertir l'entrée JSON en une instance de la classe que vous avez définie. Il existe deux méthodes de sérialisation pour les fonctions C# dans Lambda : la sérialisation basée sur la réflexion et la sérialisation générée par la source.
Sérialisation basée sur la réflexion
AWS fournit des bibliothèques prédéfinies que vous pouvez rapidement ajouter à votre application. Ces bibliothèques implémentent la sérialisation à l'aide de la réflexion
-
Amazon.Lambda.Serialization.SystemTextJson— Dans le backend, ce package permet d'System.Text.Jsoneffectuer des tâches de sérialisation. -
Amazon.Lambda.Serialization.Json— Dans le backend, ce package permet d'Newtonsoft.Jsoneffectuer des tâches de sérialisation.
Vous pouvez également créer votre propre bibliothèque de sérialisation en implémentant l'interface ILambdaSerializer, disponible dans la bibliothèque Amazon.Lambda.Core. Cette interface définit deux méthodes :
-
T Deserialize<T>(Stream requestStream);Vous implémentez cette méthode afin de désérialiser la charge utile de la demande à partir de l'API
Invokedans l'objet qui est transféré à votre gestionnaire de fonction Lambda. -
T Serialize<T>(T response, Stream responseStream);Vous implémentez cette méthode pour sérialiser le résultat renvoyé à partir de votre gestionnaire de fonction Lambda dans la charge utile de la réponse renvoyée par l'opération d'API
Invoke.
L'exemple principal de cette page utilise la sérialisation basée sur la réflexion. La sérialisation basée sur la réflexion fonctionne immédiatement AWS Lambda et ne nécessite aucune configuration supplémentaire, ce qui en fait un bon choix pour des raisons de simplicité. Cependant, cela nécessite une utilisation plus importante de la mémoire des fonctions. Vous pouvez également constater des latences de fonctionnement plus élevées en raison de la réflexion sur le temps d'exécution.
Sérialisation générée à la source
Avec la sérialisation générée par la source, le code de sérialisation est généré au moment de la compilation. Cela élimine le besoin de réflexion et peut améliorer les performances de votre fonction. Pour utiliser la sérialisation générée par la source dans votre fonction, vous devez effectuer les opérations suivantes :
-
Créez une nouvelle classe partielle qui hérite de
JsonSerializerContext, en ajoutant des attributsJsonSerializablepour tous les types qui nécessitent une sérialisation ou une désérialisation. -
Configurez le
LambdaSerializerafin d'utiliser unSourceGeneratorLambdaJsonSerializer<T>. -
Mettez à jour toute sérialisation et désérialisation manuelles dans le code de votre application pour utiliser la classe nouvellement créée.
L'exemple suivant montre comment vous pouvez modifier l'exemple principal de cette page, qui utilise la sérialisation basée sur la réflexion, pour utiliser plutôt la sérialisation générée par la source.
using System.Text.Json;
using System.Text.Json.Serialization;
...
public class Order
{
public string OrderId { get; set; } = string.Empty;
public double Amount { get; set; }
public string Item { get; set; } = string.Empty;
}
[JsonSerializable(typeof(Order))]
public partial class OrderJsonContext : JsonSerializerContext {}
public class OrderHandler
{
...
public async Task<string> HandleRequest(string input, ILambdaContext context)
{
var order = JsonSerializer.Deserialize(input, OrderJsonContext.Default.Order);
...
}
}La sérialisation générée par la source nécessite plus de configuration que la sérialisation basée sur la réflexion. Cependant, les fonctions utilisant la génération de code source ont tendance à utiliser moins de mémoire et à offrir de meilleures performances en raison de la génération de code au moment de la compilation. Pour éliminer les démarrages à froid liés aux fonctions, envisagez de passer à la sérialisation générée par la source.
Note
Si vous souhaitez utiliser la ahead-of-time compilation native (AOT) avec Lambda, vous devez utiliser la sérialisation générée par la source.
Accès et utilisation de l’objet de contexte Lambda
L’objet de contexte Lambda contient des informations sur l’invocation, la fonction et l’environnement d’exécution. Dans cet exemple, l'objet de contexte est de type Amazon.Lambda.Core.ILambdaContext et constitue le deuxième argument de la fonction de gestion principale.
public async Task<string> HandleRequest(Order order, ILambdaContext context) {
...
}L'objet de contexte est une entrée facultative. Pour plus d'informations sur les signatures de gestionnaires acceptées valides, consultezSignatures de gestionnaire valides pour les fonctions C#.
L'objet de contexte est utile pour générer des journaux de fonctions pour Amazon CloudWatch. Vous pouvez utiliser context.getLogger() cette méthode pour obtenir un LambdaLogger objet à enregistrer. Dans cet exemple, nous pouvons utiliser l'enregistreur pour enregistrer un message d'erreur si le traitement échoue pour une raison quelconque :
context.Logger.LogError($"Failed to process order: {ex.Message}");En dehors de la journalisation, vous pouvez également utiliser l'objet de contexte pour surveiller les fonctions. Pour plus d’informations sur la copie d’objets, consultez Utilisation de l’objet de contexte Lambda pour récupérer les informations de la fonction C#.
Utilisation de la SDK pour .NET v3 dans votre gestionnaire
Vous utiliserez souvent les fonctions Lambda pour interagir avec d'autres AWS ressources ou pour les mettre à jour. Le moyen le plus simple d'interagir avec ces ressources est d'utiliser la SDK pour .NET version 3.
Note
Le SDK pour .NET (v2) est obsolète. Nous vous recommandons de n'utiliser que la SDK pour .NET version 3.
Vous pouvez ajouter des dépendances du SDK à votre projet à l'aide de la Amazon.Lambda.Tools commande suivante :
dotnet add package<package_name>
Par exemple, dans l'exemple principal de cette page, nous devons utiliser l'API Amazon S3 pour télécharger un reçu dans S3. Nous pouvons importer le client du SDK Amazon S3 à l'aide de la commande suivante :
dotnet add package AWSSDK.S3Cette commande ajoute la dépendance à votre projet. Vous devriez également voir une ligne similaire à la suivante dans le .csproj fichier de votre projet :
<PackageReference Include="AWSSDK.S3" Version="3.7.2.18" />Importez ensuite les dépendances directement dans votre code C# :
using Amazon.S3;
using Amazon.S3.Model;L'exemple de code initialise ensuite un client Amazon S3 (en utilisant la chaîne de fournisseurs d'informations d'identification par défaut) comme suit :
private static readonly AmazonS3Client s3Client = new();Dans cet exemple, nous avons initialisé notre client Amazon S3 en dehors de la fonction de gestion principale pour éviter d'avoir à l'initialiser à chaque fois que nous invoquons notre fonction. Après avoir initialisé votre client SDK, vous pouvez l'utiliser pour interagir avec d'autres AWS services. L’exemple de code appelle l’API Amazon S3 PutObject comme suit :
var putRequest = new PutObjectRequest
{
BucketName = bucketName,
Key = key,
ContentBody = receiptContent,
ContentType = "text/plain"
};
await s3Client.PutObjectAsync(putRequest);Accès aux variables d’environnement
Dans le code de votre gestionnaire, vous pouvez référencer n’importe quelle variable d’environnement à l’aide de la méthode System.Environment.GetEnvironmentVariable. Dans cet exemple, nous référençons la variable d'RECEIPT_BUCKETenvironnement définie à l'aide des lignes de code suivantes :
string? bucketName = Environment.GetEnvironmentVariable("RECEIPT_BUCKET");
if (string.IsNullOrWhiteSpace(bucketName))
{
throw new ArgumentException("RECEIPT_BUCKET environment variable is not set");
}Utilisation de l'état global
Lambda exécute votre code statique et le constructeur de classe pendant la phase d’initialisation avant d’invoquer votre fonction pour la première fois. Les ressources créées lors de l'initialisation restent en mémoire entre les invocations, ce qui vous évite d'avoir à les créer à chaque fois que vous appelez votre fonction.
Dans l'exemple de code, le code d'initialisation du client S3 ne fait pas partie de la méthode de gestion principale. Le moteur d'exécution initialise le client avant que la fonction ne gère son premier événement, ce qui peut entraîner des délais de traitement plus longs. Les événements suivants sont beaucoup plus rapides car Lambda n'a pas besoin d'initialiser à nouveau le client.
Simplifiez le code de la fonction à l'aide du cadre d'annotations Lambda
Lambda Annotations
Pour un exemple d'application complète utilisant les annotations Lambda, consultez l' PhotoAssetManagerawsdocs/aws-doc-sdk-examples GitHub Le Function.cs fichier principal du PamApiAnnotations répertoire utilise les annotations Lambda. À titre de comparaison, le PamApi répertoire contient des fichiers équivalents écrits selon le modèle de programmation Lambda standard.
Injection de dépendances grâce au cadre d'annotations Lambda
Vous pouvez également utiliser le cadre d'annotations Lambda pour ajouter l'injection de dépendance à vos fonctions Lambda en utilisant une syntaxe que vous connaissez bien. Lorsque vous ajoutez un attribut [LambdaStartup] à un fichier Startup.cs, le cadre d'annotations Lambda génère le code nécessaire au moment de la compilation.
[LambdaStartup]
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
services.AddSingleton<IDatabaseRepository, DatabaseRepository>();
}
}Votre fonction Lambda peut injecter des services en utilisant l'injection de constructeur ou en injectant dans des méthodes individuelles à l'aide de l'attribut [FromServices].
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace GetProductHandler;
public class Function
{
private readonly IDatabaseRepository _repo;
public Function(IDatabaseRepository repo)
{
this._repo = repo;
}
[LambdaFunction]
[HttpApi(LambdaHttpMethod.Get, "/product/{id}")]
public async Task<Product> FunctionHandler([FromServices] IDatabaseRepository repository, string id)
{
return await this._repo.GetById(id);
}
}Pratiques exemplaires de codage pour les fonctions Lambda C#
Respectez les directives de la liste suivante pour utiliser les pratiques exemplaires de codage lors de la création de vos fonctions Lambda :
-
Séparez le gestionnaire Lambda de votre logique principale. Cela vous permet de créer une fonction testable plus unitaire.
-
Contrôlez les dépendances du package de déploiement de vos fonctions. L’environnement d’exécution AWS Lambda contient un certain nombre de bibliothèques. Pour activer le dernier ensemble de mises à jour des fonctionnalités et de la sécurité, Lambda met régulièrement à jour ces bibliothèques. Ces mises à jour peuvent introduire de subtiles modifications dans le comportement de votre fonction Lambda. Pour disposer du contrôle total des dépendances que votre fonction utilise, empaquetez toutes vos dépendances avec votre package de déploiement.
-
Réduisez la complexité de vos dépendances. Privilégiez les infrastructures plus simples qui se chargent rapidement au démarrage de l’environnement d’exécution.
-
Réduisez la taille de votre package de déploiement selon ses besoins d’exécution. Cela contribue à réduire le temps nécessaire au téléchargement et à la décompression de votre package de déploiement avant l’invocation. Pour les fonctions créées dans .NET, évitez de télécharger l'intégralité de la bibliothèque du AWS SDK dans le cadre de votre package de déploiement. À la place, appuyez-vous de façon sélective sur les modules qui sélectionnent les composants du kit SDK dont vous avez besoin (par exemple, DynamoDB, modules du kit SDK Amazon S3 et bibliothèques principales Lambda).
-
Tirez parti de la réutilisation de l’environnement d’exécution pour améliorer les performances de votre fonction. Initialisez les clients SDK et les connexions à la base de données en dehors du gestionnaire de fonctions et mettez en cache les actifs statiques localement dans le répertoire
/tmp. Les invocations ultérieures traitées par la même instance de votre fonction peuvent réutiliser ces ressources. Cela permet d’économiser des coûts, tout en réduisant le temps d’exécution de la fonction.Pour éviter des éventuelles fuites de données entre les invocations, n’utilisez pas l’environnement d’exécution pour stocker des données utilisateur, des événements ou d’autres informations ayant un impact sur la sécurité. Si votre fonction repose sur un état réversible qui ne peut pas être stocké en mémoire dans le gestionnaire, envisagez de créer une fonction distincte ou des versions distinctes d’une fonction pour chaque utilisateur.
-
Utilisez une directive keep-alive pour maintenir les connexions persistantes. Lambda purge les connexions inactives au fil du temps. Si vous tentez de réutiliser une connexion inactive lorsque vous invoquez une fonction, cela entraîne une erreur de connexion. Pour maintenir votre connexion persistante, utilisez la directive Keep-alive associée à votre environnement d’exécution. Pour obtenir un exemple, consultez Réutilisation des connexions avec Keep-Alive dans Node.js.
-
Utilisez des variables d’environnement pour transmettre des paramètres opérationnels à votre fonction. Par exemple, si vous écrivez dans un compartiment Amazon S3 au lieu de coder en dur le nom du compartiment dans lequel vous écrivez, configurez le nom du compartiment comme variable d’environnement.
-
Évitez d’utiliser des invocations récursives dans votre fonction Lambda, lorsque la fonction s’invoque elle-même ou démarre un processus susceptible de l’invoquer à nouveau. Cela peut entraîner un volume involontaire d’invocations de fonction et des coûts accrus. Si vous constatez un volume involontaire d’invocations, définissez immédiatement la simultanéité réservée à la fonction sur
0afin de limiter toutes les invocations de la fonction, pendant que vous mettez à jour le code. -
N'utilisez pas de code non documenté ni public APIs dans votre code de fonction Lambda. Pour les AWS Lambda environnements d'exécution gérés, Lambda applique régulièrement des mises à jour de sécurité et fonctionnelles aux applications internes de Lambda. APIs Ces mises à jour internes de l'API peuvent être rétroincompatibles, ce qui peut entraîner des conséquences imprévues, telles que des échecs d'invocation si votre fonction dépend de ces mises à jour non publiques. APIs Consultez la référence de l'API pour obtenir une liste des API accessibles au public APIs.
-
Écriture du code idempotent. L’écriture de code idempotent pour vos fonctions garantit ne gestion identique des événements dupliqués. Votre code doit valider correctement les événements et gérer correctement les événements dupliqués. Pour de plus amples informations, veuillez consulterComment faire en sorte que ma fonction Lambda soit idempotente ?
.
