1. Qu'est-ce que le sans serveur ?
1. Introduction à la technologie sans serveur
Sans serveur (architecture sans serveur) fait référence à la logique côté serveur mise en œuvre par les développeurs s'exécutant dans un conteneur informatique sans état. Elle est déclenchée par des événements et est entièrement gérée par un tiers. Son état de niveau métier est utilisé par les développeurs et les ressources de stockage. sont enregistrés.
Le sans serveur élimine le besoin pour les développeurs de traiter directement avec les serveurs (qu'il s'agisse de machines physiques, de machines virtuelles, de conteneurs, etc.). Les avantages de l'absence d'hôte réduiront considérablement les frais généraux opérationnels des utilisateurs en termes de maintenance du serveur, et il n'y a pas besoin de s'inquiéter de la mise à niveau du serveur. L'absence d'hôte signifie également que les métriques à surveiller dans l'application seront différentes. En effet, la plupart des services sous-jacents utilisés ne publient plus de métriques traditionnelles telles que le processeur, la mémoire, la taille du disque, etc. Ainsi, il n'est plus nécessaire d'accorder une attention particulière aux détails opérationnels sous-jacents de l'architecture.
Adrian Cockcroft, vice-président de la stratégie d'architecture cloud d'AWS, a un jour donné une manière simple de définir Serverless : " Si votre PaaS peut effectivement démarrer une instance en 20 millisecondes et s'exécuter pendant une demi-seconde, alors on peut l'appeler Serverless ". Et dans la description de l'article A Berkeley View on Serverless Computing : Serverless = FaaS + BaaS .
En se référant au schéma logique technique de l'architecture sans serveur ci-dessus, nous pouvons voir que l'architecture sans serveur s'appuie fortement sur des services tiers (également appelés backend en tant que service, ou "BaaS") ou sur du code personnalisé s'exécutant dans des conteneurs temporaires (fonction comme un service, ou applications "FaaS") , donc FaaS et BaaS peuvent être considérés comme deux implémentations spécifiques de Serverless . Une fonction est la plus petite unité d'exécution de langage abstrait dans une architecture sans serveur. Dans cette architecture "à utiliser au fur et à mesure", il ne s'agit pas de la quantité de CPU ou de RAM ou de toute autre ressource nécessaire pour exécuter une fonction, mais plutôt du temps qu'il faut pour exécuter la fonction, et vous ne payez que pour le le temps que ces fonctions s'exécutent.
Voici une brève analyse des avantages du Serverless, ainsi que de certaines lacunes actuelles :
Les avantages de l'architecture sans serveur
- Vitesse de développement plus rapide : par rapport à IaaS et PaaS, la plate-forme FaaS basée sur la technologie sans serveur résume et extrait la partie logique du code métier client dans le processus d'exécution des applications traditionnelles ( formant le modèle de code de fonction utilisateur + BaaS ), les développeurs n'ont qu'à Selon l'ensemble de fonctions de développement standard de la plate-forme cloud, les développeurs n'ont pas besoin de se soucier du framework utilisé au niveau de la couche inférieure - ils n'ont qu'à développer une logique métier ; ils ne savent pas combien d'instances sont en cours d'exécution et où elles s'exécutent, toutes qui permettent aux développeurs de se concentrer davantage sur Focus on business code.
- Déploiement automatisé intégré : les architectures sans serveur implémentent généralement un déploiement automatisé intégré via des API et divers outils fournis sur la plate-forme. Généralement, ces outils écoutent les modifications apportées au référentiel de code source et se déploient automatiquement en production lorsque le code est mis à jour. Lors du déploiement, l'outil regroupe le code dans une ou plusieurs fonctions, le télécharge sur la plate-forme FaaS et le configure avec l'URL et les déclencheurs d'événements appropriés en réponse aux demandes. De cette façon, chaque requête déclenchera l'exécution de la fonction correspondante, réalisant ainsi le déploiement en temps réel du code.
- Réduire la surcharge des ressources : lorsque la fonction n'est pas demandée, l'instance de la fonction est 0. Lorsqu'il y a une demande, la plate-forme cloud extrait rapidement une instance pour transporter le trafic. Plus important encore : les fonctions peuvent être facturées en fonction de la demande, c'est-à-dire que vous payez une fois pour chaque appel, tandis que les services traditionnels sont facturés en fonction de la spécification de l'instance.
Quelques défauts de l'architecture Serverless :
- Gestion de l'état : pour obtenir une mise à l'échelle libre, l'absence d'état est indispensable. Pour les services avec état, l'utilisation sans serveur perdra en flexibilité. Les services avec état doivent interagir avec le stockage, ce qui augmente inévitablement la latence et la complexité.
- L'environnement informatique est hautement standardisé : le serveur sous-jacent et l'environnement d'exploitation sur lesquels s'exécutent les applications informatiques sans serveur sont transparents pour les utilisateurs, et les utilisateurs ne peuvent ni choisir ni optimiser. L'environnement dans lequel les programmes informatiques sans serveur s'exécutent est hautement standardisé, et certaines dépendances qui dépendent d'environnements d'exploitation spécifiques, de versions de serveur spécifiques ou même de ressources matérielles spécifiques sont difficiles à assurer la compatibilité.
- Tests locaux : À l'heure actuelle, il manque encore des outils de débogage et de développement matures dans le processus de développement utilisant l'architecture Serverless.
- temps de démarrage à froid
2. Technologies clés sans serveur
(1) Axé sur les événements
La fonctionnalité "Calcul uniquement lors de l'exécution" de Serverless Conception de programmation événementielle Ce modèle de conception a été conçu dans le cas de programmes interactifs (Interactive program). Cela signifie également que le système a un énorme changement dans le modèle de programmation. Lorsque nous écrivons des programmes GUI, tels que des programmes de bureau et des applications Web frontales, nous démarrons la logique de traitement correspondante en écoutant les opérations de l'utilisateur sur les boutons, les liens et d'autres composants. Ceci est similaire à Serverless, qui répond au comportement de l'utilisateur uniquement lorsque l'utilisateur l'utilise.
(2) Technologie des conteneurs
La technologie des conteneurs est généralement mise en œuvre via Docker dans l'architecture sans serveur. Le fournisseur de services cloud regroupera le code de chaque fonction dans un conteneur Docker distinct. À l'intérieur d'un conteneur, vous pouvez vous assurer que le code peut s'exécuter dans un environnement isolé sans affecter le fonctionnement d'autres fonctions ou applications.
Lorsqu'une demande arrive, le fournisseur de services cloud exécute la fonction à l'intérieur du conteneur et détruit le conteneur une fois terminé. Cette pratique permet de s'assurer que l'exécution de chaque fonction est de courte durée et ne consomme pas trop de ressources, évitant ainsi le gaspillage de ressources.
En utilisant la technologie des conteneurs, l'architecture sans serveur peut garantir que les fonctions s'exécutent dans un environnement isolé et peuvent être rapidement étendues pour répondre à la demande croissante. Dans le même temps, la technologie des conteneurs peut également améliorer la sécurité des applications, car les autorisations des fonctions peuvent être restreintes pour empêcher les fonctions d'accéder à des données qui ne devraient pas être accessibles.
3. Comparaison avec une architecture technique commune
(1) Architecture traditionnelle-VS- Sans serveur
L'architecture technique d'une application Web Java traditionnelle peut être illustrée par la figure suivante :
Une telle architecture peut rendre le front-end très léger, sans aucune logique d'application, il est uniquement responsable du rendu de l'interface utilisateur et de l'envoi de la requête au back-end via HTTP, et toutes les opérations de données sont effectuées par le back-end Programme Java. Une telle architecture est relativement facile à développer, mais elle est en effet très compliquée à maintenir.Le développement front-end comme le développement back-end nécessitent un personnel très professionnel, une configuration de l'environnement et un personnel spécial pour maintenir la base de données et mettre à jour et mettre à niveau les applications.
Dans l'architecture sans serveur, nous n'avons plus besoin de stocker d'état de session dans le code côté serveur, mais de les stocker directement dans NoSQL, ce qui rendra l'application sans état et favorisera une expansion élastique. Le front-end peut utiliser directement BaaS pour réduire les exigences de codage du back-end.Cette architecture réduit essentiellement le coût de la main-d'œuvre du développement d'applications, réduit le risque de maintenance de l'infrastructure et utilise les capacités du cloud pour faciliter l'expansion et l'itération rapide.
（2）MicroService -VS- Sans serveur
Le microservice (MicroService) est un autre sujet brûlant dans le domaine de l'architecture logicielle. Si les microservices sont basés sur de petits blocs fonctionnels qui se concentrent sur des responsabilités et des fonctions uniques, et utilisent la modularisation pour combiner des applications complexes à grande échelle, alors nous pouvons en outre penser que l'architecture Serverless peut fournir un paradigme d'architecture logicielle plus "fragmentation du code", nous appelez-le Fonction en tant que Services (FaaS). La soi-disant "fonction" (Function) fournit une unité de programme plus petite que les microservices. Par exemple, un microservice pourrait représenter le code nécessaire pour effectuer toutes les opérations CRUD pour un client, tandis qu'une "fonction" dans FaaS pourrait représenter chaque opération qu'un client effectuerait : créer, lire, mettre à jour et supprimer. Lorsque l'événement « créer un compte » est déclenché, la « fonction » correspondante sera exécutée via la fonction AWS Lambda. A partir de ce niveau de signification, nous pouvons simplement assimiler l'architecture Serverless au concept de FaaS.
Le sans serveur est intrinsèquement complémentaire à l'architecture de microservice . Une application sans serveur possède sa propre passerelle, base de données et interface, et vous pouvez également utiliser votre langage préféré (limité par les fournisseurs de services) pour développer des services. En d'autres termes, un Serverless pourrait être une instance de microservice parfaite dans cette situation.
（3）Cloud serveur -VS- Cloud sans serveur
Les trois principales différences entre les plates-formes cloud traditionnelles
- ** Calcul et stockage découplés. ** Le stockage et l'informatique sont mis à l'échelle séparément, provisionnés et tarifés indépendamment. En règle générale, le stockage est fourni par un service cloud distinct et le calcul est sans état.
- ** Exécuter du code sans gérer l'allocation des ressources. **Les utilisateurs fournissent un morceau de code au lieu de demander des ressources, et le cloud fournit automatiquement des ressources pour exécuter ce code.
- Payer au prorata des ressources utilisées, non allouées . La facturation est effectuée en fonction d'une certaine dimension liée à l'exécution (telle que le temps d'exécution), et non en fonction d'une certaine dimension de la plate-forme cloud de base (telle que la taille et le nombre de machines virtuelles allouées).
Quelques comparaisons entre les plates-formes cloud traditionnelles et d'autres détails techniques des plates-formes sans serveur (en prenant AWS comme exemple) :
4. Pratique d'ingénierie de l'industrie sans serveur
- AWS Lambda : Introduction au service de cloud computing AWS Lambda_Comment utiliser le service cloud AWS Lambda-AWS (amazon.com)
- Alibaba Cloud Function Computing Platform : Function Computing FC_Serverless Computing_Serverless_Containers et Middleware-Alibaba Cloud (aliyun.com)
- Plateforme FaaS open source
- etc.
2. FaaS
1、IaaS -> CaaS -> PaaS -> FaaS
-
IaaS (Infrastructure as a Service) : Infrastructure en tant que service. Il s'agit de fournir une infrastructure (telle que l'informatique, le stockage, le réseau, etc.) en tant que service, et les utilisateurs peuvent créer leur propre environnement d'application sur cette base.
-
CaaS (Containers as a Service) : Conteneurs en tant que service. Il s'agit de fournir une technologie de conteneur aux utilisateurs, et les utilisateurs peuvent exécuter leurs propres applications via des conteneurs.
-
PaaS (Platform as a Service) : Plate-forme en tant que service. Il fait référence à la fourniture de plates-formes de développement et d'outils de gestion d'applications. Les utilisateurs n'ont qu'à prêter attention au développement et au fonctionnement des applications, et n'ont pas besoin de prêter attention à l'infrastructure sous-jacente.
-
Sans serveur : architecture sans serveur. Cela signifie qu'il n'est pas nécessaire de gérer et de configurer explicitement les ressources du serveur pour exécuter des applications, et que toute la gestion et la maintenance sous-jacentes relèvent de la responsabilité du fournisseur de la plate-forme. Les utilisateurs n'ont qu'à télécharger leur propre code et attendre que le code soit exécuté automatiquement. Sans serveur = FaaS + BaaS . BaaS (back-end en tant que service)
-
FaaS (fonction en tant que service) Fonction en tant que service : en tant que service de cloud computing, il permet aux développeurs de déployer des fonctions individuelles chez les fournisseurs de cloud au lieu d'applications entières. Le fournisseur de cloud exécute automatiquement la fonction lorsque la demande arrive et la détruit lorsque la demande est terminée. Et le "F" le plus critique dans "FaaS", c'est-à-dire comment la fonction est-elle définie ? Vous pouvez vous référer à la définition suivante de CloudFunction par Alex, l'initiateur du projet OpenFaaS :
2. Technologies clés du FaaS
Discutons brièvement de certaines solutions techniques clés auxquelles il faut faire face dans le FaaS :
(1) Mise à l'échelle élastique (K8 comme base d'orchestration)
La mise à l'échelle automatique est un élément clé de l'optimisation des coûts de calcul des fonctions. La cible principale de la mise à l'échelle automatique est les instances de fonction (certaines architectures FaaS incluent également des instances de déclencheur MQ qui sont démarrées ensemble). Le processus principal de mise à l'échelle élastique comprend : la détection d'indicateurs (déclenchement de la mise à l'échelle élastique) > le calcul de la politique de mise à l'échelle de la planification > la mise à l'échelle finale pour prendre effet , les étapes ci-dessus sont très similaires à k8s HPA, mais le mécanisme de mise en œuvre a changé pour les caractéristiques de la fonction informatique, bien que de cette manière, les capacités actuelles de k8s puissent également répondre efficacement aux exigences de mise à l'échelle élastique de FaaS. Par conséquent, les produits Serverless/FaaS de la communauté open source sont essentiellement implémentés sur la base du développement de produits k8s./FaaS.
Voici le schéma d'architecture du projet open source OpenFaaS basé sur k8s :
En ce qui concerne la mise à l'échelle élastique , en plus du HPA de Kubernetes, il existe des frameworks élastiques d'architecture pilotée par les événements KEDA et KPA (implémentation Knative) dans la communauté. KEDA, le problème central qu'il résout est la mise à l'échelle élastique sous l'architecture événementielle (mise à l'échelle déclenchée par événement) et le problème des instances de 0 -> 1, 1 -> 0. KEDA fonctionne comme un serveur de métriques Kubernetes, permettant aux utilisateurs de utilisez des définitions de ressources personnalisées Kubernetes dédiées pour définir des règles d'autoscaling.
KEDA peut s'exécuter sur le cloud et en périphérie, et peut être intégré de manière native aux composants Kubernetes (tels que Horizontal Pod Autoscaler) et n'a aucune dépendance externe. , la structure globale de KEDA est la suivante :
(2) Mécanisme d'exécution et de chargement des fonctions
L'environnement d'exécution FaaS doit fournir des ressources et un environnement d'exécution de langage isolé pour la sécurité pour l'exécution des fonctions, et fournir des événements d'appel, des informations de contexte et des informations de réponse aux fonctions. L'environnement d'exécution de la fonction doit avoir une spécification d'interface unifiée pour prendre en charge l'accès multilingue et un composant de surveillance et de gestion dédié (similaire à l'agent démarré avec l'instance de fonction) pour maintenir le cycle de vie de l'instance de fonction.
En prenant Lambda d'AWS, une plate-forme FaaS mature dans l'industrie, comme exemple , son architecture d'exécution de fonction est similaire à celle illustrée dans la figure ci-dessous : la zone en pointillés à droite est une instance de fonction , y compris un RuntimeAgent (c'est-à-dire, API Endpoints) pour les fonctions de traitement Surveiller et gérer le processus de la fonction pendant le processus d'appel, et collecter les données d'exécution et les télécharger sur l' HostAgent (service Lambda) en dehors de l'instance de la fonction pour analyse et enregistrement ; Les processus incluent le processus de la fonction qui exécute l'activité de l'utilisateur logique et l'environnement d'exécution fourni par la plate-forme FaaS.
Lambda prend en charge plusieurs langues via Runtime et Runtime API . L'API Runtime et Runtime sont appelées via les spécifications de l'API, et les fonctions utilisateur n'ont besoin que d'implémenter des fonctions d'interface spécifiques de Runtime pour effectuer des opérations telles que l'initialisation, le chargement et l'appel. De plus, le Runtime fournit un environnement spécifique au langage pour transmettre les événements d'appel, les informations de contexte et les réponses entre Lambdas et les fonctions. Les utilisateurs peuvent utiliser l'environnement d'exécution fourni par la plateforme Lambda ou créer leur propre environnement d'exécution.
Chaque version majeure du langage de programmation a un environnement d'exécution distinct avec un identifiant d'exécution unique, tel que python3.10 ou nodejs18.x. Pour configurer une fonction afin d'utiliser une nouvelle version de langue majeure, l'identifiant d'exécution doit être modifié. Étant donné qu'AWS Lambda ne peut pas garantir la rétrocompatibilité entre les principales versions, il s'agit d'une opération discrétionnaire du client. Pour les fonctions définies en tant qu'images de conteneur, vous pouvez choisir le runtime et la distribution Linux
lors de la création de l'image de conteneur . Pour modifier le runtime, la configuration de la fonction doit être mise à jour et une nouvelle image de conteneur doit être créée. Le runtime est associé à une distribution Amazon Linux. L'environnement d'exécution sous-jacent fournit des bibliothèques et des variables d'environnement supplémentaires accessibles à partir du code de la fonction. Dans le cluster k8s, l'intégralité de l'instance de la fonction Execution Environment peut s'exécuter en tant que pod dans un cluster spécifique pour interagir avec d'autres composants k8s ou des composants définis par l'utilisateur. D'après ce qui précède, nous pouvons voir que Lambda implémente le chargement des fonctions en empaquetant uniformément les fonctions utilisateur et en les mettant en miroir au moment de l'exécution. De plus, le chargement du code de la fonction utilisateur peut également être implémenté en montant des répertoires ou en partageant de la mémoire, ce qui ne sera pas développé ici.
(3) Démarrage à froid
Le démarrage à froid fait référence à la phase de préparation d'une instance de fonction utilisateur, de la planification au démarrage jusqu'à la capacité de fournir des services. Examinons les étapes impliquées dans le démarrage d'un conteneur miroir contenant des fonctions utilisateur et des runtimes de fonction dans un cluster k8s traditionnel :
- Pour postuler aux ressources de la fonction de planification, kube-scheduler spécifie les nœuds de planification en fonction de la demande et des calculs de ressources existantes.
- Le processus kubelet du nœud spécifié détecte que le pod est envoyé au nœud et, lors de l'appel de l'environnement d'exécution du conteneur, il extrait l'image du registre.
- Extrayez le conteneur lorsque le conteneur de bas niveau est en cours d'exécution, enregistrez le point de terminaison k8s et effectuez une vérification de l'état (toutes les secondes)
- La vérification de l'état réussit et le conteneur est correctement initialisé dans le cluster.
- (À l'intérieur du conteneur : exécution de la fonction, instance de la fonction, RuntimeAgent, etc. initialisation complète et enregistrement de la fonction)
Le temps d'extraction de l'image est incontrôlable, allant de quelques secondes à des dizaines de secondes voire des minutes.Lorsque le code de la fonction est inclus dans l'image, du fait de l'hétérogénéité de l'image de la fonction et de l'existence d'un grand nombre de difficile à réutiliser. Deuxièmement, il faut généralement plusieurs secondes à kubelet pour créer un conteneur.Une fois le conteneur démarré, le temps de démarrage du processus de la fonction à l'intérieur du conteneur (y compris le démarrage de l'environnement d'exécution, la préparation des dépendances, etc.) prend également du temps.
Pour résumer, la fonction de délai de démarrage à froid est un problème clé dans le FaaS. Actuellement, l'industrie dispose des méthodes suivantes pour l'optimisation du démarrage à froid :
-
Pour le retard de l'extraction d'image, vous pouvez adopter la méthode de séparation du code d'image. L'image elle-même est en couches, vous pouvez donc séparer le code de la fonction utilisateur de la fonction runtime, RuntimeAgent et d'autres couches dépendantes de l'environnement, et le nœud fera avancer la pièce du contenu qui ne change pas Avancez pour gagner du temps.
-
Compte tenu de la perte de temps causée par le démarrage du conteneur, le temps d'exécution de la fonction, RuntimeAgent et d'autres environnements à l'intérieur du conteneur, et le démarrage des composants après le démarrage du conteneur, le délai peut être réduit en préchauffant l'instance de fonction, c'est-à-dire en maintenant une température froide . pool de ressources de démarrage . La plate-forme FaaS peut pré-maintenir un lot de conteneurs de base qui ne contiennent pas de fonctions métier pour former un pool de ressources de démarrage à froid. Après le processus de démarrage à froid, il est lié à une instance de fonction utilisateur et peut être extrait **volume de stockage partagé** ou directement en ligne Chargez l'instance de la fonction utilisateur en récupérant le code , etc., et commencez à fournir des services. La capacité, l'expansion et la contraction du pool de démarrage à froid sont surveillées et gérées de manière uniforme par la plateforme FaaS. (Ou utilisez un environnement d'exécution de conteneur plus léger et efficace : l'une est une technologie de virtualisation légère basée sur KVM, telle que Firecracker ; l'autre est Wasm. La technologie sous-jacente Lambda d'AWS utilise Firecracker, et son temps de démarrage à froid est de niveau ms)
-
Pour les vérifications de l'état, OpenFaaS a essayé de réduire la latence en utilisant RuntimeAgent (chien de garde) pour accepter et traiter le trafic externe à l'avance avant les vérifications de l'état de K8.Cependant, cette méthode présente de nombreux problèmes et n'est pas recommandée pour le moment.
-
Pour le démarrage fastidieux des instances de processus de fonction métier de l'utilisateur à l'intérieur du conteneur, vous pouvez vous référer à la méthode de fork a Process Per Request dans le conteneur tout en conservant une instance de fonction de cache dans OpenFaaS.
De plus, le FaaS général exige que le trafic de l'instance d'instance de fonction soit réduit à 0 lorsque le débit est de 0 (le HPA natif de K8 ne peut pas le faire temporairement, mais KEDA le peut), mais certaines plates-formes faas n'appliquent pas de restrictions à ce sujet, par exemple , la version open source OpenFaaS exécute une instance de fonction par défaut pour transporter le trafic initial, et certaines autres plates-formes adoptent la méthode de maintien d'un pool de ressources de démarrage à froid pour éviter le problème d'une initialisation trop longue.
(4) Comment appeler/déclencher la fonction
-
Basé sur l'architecture des fonctions Web : son essence est d'appeler des fonctions via HTTP. Le cœur ici est que l'environnement d'exécution de l'instance de fonction doit fournir un framework Web et un serveur Web, et la fonction utilisateur est appelée après que la demande entre dans le Runtime. Chaque fonction configure un déclencheur HTTP par défaut et lui attribue un nom de domaine indépendant fixe. Tant que le nom de domaine est demandé, il peut être exécuté comme une fonction de déclencheur HTTP. La fonction peut traiter la demande tant qu'elle implémente l'interface correspondante , et enfin via la passerelle API fournie par la plateforme FaaS Traitement centralisé des requêtes d'interface d'instance de fonction.
-
Architecture pilotée par les événements : les produits de cloud communautaire et public ont le concept de déclencheurs. Le soi-disant déclencheur est en fait la source de l'événement. La source de l'événement peut être reçue par un conteneur sidecar unifié, puis invoquer la fonction par HTTP ; elle peut également être directement reçue par chaque fonction Runtime, puis invoquer la fonction.
-
Basé sur la file d'attente de messages MQ : la consommation de MQ est un type d'activité courant dans les scénarios d'entreprise. Qu'il s'agisse de calcul de données hors ligne ou de messages en temps réel en ligne, MQ sera sélectionné comme middleware pour traiter et dissocier l'activité de manière asynchrone. Par conséquent, le message MQ La file d'attente peut être utilisé comme la plus grande entrée de trafic de toute la plate-forme FaaS.
-
Méthode de déclenchement définie par l'utilisateur : Par exemple, un composant appelé Connector d'OpenFaaS permet aux développeurs de personnaliser la méthode de déclenchement des fonctions.
(5) Autres
Voici quelques points techniques liés au FaaS que j'ai personnellement compilés, qui peuvent ne pas être très complets, et sont à titre indicatif uniquement.
3. Cadre FaaS natif du cloud
(1) OuvrirFonction
OpenFunction est un framework FaaS (Function as a Service) natif du cloud moderne , qui introduit de nombreuses piles de technologies open source excellentes, notamment Knative, Tekton, Shipwright, Dapr, KEDA, etc. Les possibilités sont infinies :
- Shipwright permet aux utilisateurs de choisir et de changer librement d'outils pour la construction d'images pendant le processus de construction de fonctions, et les résume pour fournir une API unifiée ;
- Knative fournit une excellente exécution de fonction synchrone avec de puissantes capacités de mise à l'échelle automatique ;
- KEDA peut évoluer automatiquement en fonction de plusieurs types d'indicateurs et est plus flexible ;
- Dapr peut résumer les capacités générales de différentes applications et réduire la charge de travail de développement d'applications distribuées.
(2) OpenFaaS
OpenFaaS est un projet open source FaaS développé de longue date qui a attiré plus d'attention sur GitHub.Il a fait plus d'explorations dans le mode de traitement des requêtes lorsque CloudFunction est en cours d'exécution. Dans la troisième section de cet article, nous nous concentrerons sur l'introduction de la pratique FaaS.
(3) Knative：Accueil - Knative
Knative est une plateforme open source basée sur Kubernetes conçue pour simplifier et accélérer le processus de développement, de déploiement et de gestion des applications conteneurisées. Il fournit un ensemble de blocs de construction et d'outils pour aider les développeurs à déployer des applications cloud natives modernes sur des clusters Kubernetes, en mettant en œuvre une architecture sans serveur (Serverless) et une orchestration automatisée des conteneurs.
3. Pratique FaaS - OpenFaaS
1. Vue d'ensemble
(1) qu'est-ce que
OpenFaaS est un framework FaaS open source qui permet aux utilisateurs de déployer et d'exécuter leurs propres fonctions dessus. OpenFaaS utilise les conteneurs Docker comme technologie sous-jacente et peut fonctionner sur n'importe quel environnement cloud ou cloud privé. Le projet OpenFaaS vise à transformer les infrastructures de bas niveau telles que les clusters Kubernetes ou les machines virtuelles autonomes en une plate-forme de haut niveau pour la gestion des fonctions sans serveur.
(2) Qu'avez-vous fait
- Appel de fonction : WatchDog est l'implémentation clé d'OpenFaaS pour appeler et surveiller Cloud Function, qui agit comme un proxy inverse pour l'exécution de fonctions et de microservices. Il peut être utilisé indépendamment, ou comme EntryPoint pour les conteneurs OpenFaaS, et démarré dans un conteneur de fonction en tant que " Init Process ". Il dispose d'un HttpServer intégré implémenté dans Golang, qui fournit des fonctions telles que les demandes simultanées, les délais d'attente et les vérifications de l'état. Il permet aux développeurs de personnaliser ses fonctionnalités en chargeant diverses variables d'environnement.
- Mise à l'échelle automatique : OpenFaaS utilise l'AutoScaler auto-conçu pour mettre à l'échelle automatiquement les fonctions.
- Démarrage à froid : OpenFaaS se concentre sur la conception de l'architecture. OpenFaaS ne gère pas un pool de démarrage à froid, puis charge le code métier à la demande. Il espère maintenir un système de fichiers en lecture seule. Le porte-conteneurs est conçu comme une unité immuable pour obtenir la prévisibilité cycle de vie et obtenir une sécurité maximale. Par conséquent, OpenFaaS ne réduit pas le nombre d'instances de fonction à zéro par défaut lorsqu'il n'y a pas de trafic. Il n'est activé qu'en tant que configuration facultative pour la granularité de la fonction. Le trafic global de données de démarrage à froid devrait être transporté par la plus petite instance à éviter d'extraire a La planification des ressources, l'extraction binaire, le démarrage du processus et la vérification de l'état requis par la nouvelle instance génèrent d'énormes frais généraux de démarrage à froid.
(3) Comment utiliser
Présentation - OpenFaaS
OpenFaaS est déployé sur des K8 natifs via helm
2. Principaux composants techniques
Schéma de présentation de la technologie OpenFaaS
La figure ci-dessus est le processus de service abstrait d'OpenFaaS, et ce qui suit est une brève introduction de chaque nœud :
Gateway : Passerelle HTTP pour recevoir les requêtes des utilisateurs et les instructions internes.
NATS Streaming : utilisé pour exécuter des fonctions de manière asynchrone.
Prometheus / AlertManager : utilisé pour collecter les indicateurs de service et les opérations de mise à l'échelle.
faas -netes : fournisseur pour K8S, d'autres fournisseurs tels que Docker Swarm peuvent être personnalisés.
Docker Registry : un référentiel pour extraire des images de fonction.
(1) chien de garde
WatchDog est l'implémentation clé d'OpenFaaS pour l'appel et la surveillance de Cloud Function. Le dernier of-watchdog agit comme un proxy inverse pour l'exécution de fonctions ou de microservices . Il peut être utilisé de manière autonome ou comme EntryPoint pour un conteneur OpenFaaS et démarré dans un conteneur de fonctions en tant que " Init Process ". Il dispose d'un HttpServer intégré implémenté dans Golang, qui fournit des fonctions telles que les demandes simultanées, les délais d'attente et les vérifications de l'état. Il permet aux développeurs de personnaliser ses fonctionnalités en chargeant diverses variables d'environnement. OpenFaaS a lancé deux modes Watchdog, ClassicWatchdog et of-Watchdog. Sont introduits respectivement :
- Mode de travail WatchDog classique :
Dans ce mode, watchdog démarre un serveur HTTP léger écoutant sur le port 8080 , et chaque requête entrante :
- Lire l'en-tête et le corps de la requête
- fork ou exec l'exécutable contenant la fonction réelle
- Écrivez l'en-tête et le corps de la requête dans le stdin du processus de fonction
- Attendre la sortie de la fonction process (ou timeout)
- Lire stdout et stderr de la fonction process
- Renvoyez les octets non lus à l'appelant dans la réponse HTTP
La logique ci-dessus est similaire à l' interface de passerelle commune (CGI) traditionnelle . D'une part, démarrer un processus séparé pour chaque appel de fonction semble inefficace, d'autre part, c'est vraiment pratique, car tout programme (y compris les outils CLI) qui utilise des flux stdio pour le traitement des E/S peut être déployé en tant que fonction OpenFaaS .
En ce qui concerne l'isolation , nous devons faire la distinction entre les fonctions et les appels :
- Différentes fonctions dans OpenFaaS sont toujours distribuées dans différents conteneurs
- Une fonction peut avoir un ou plusieurs conteneurs - selon les options de mise à l'échelle
- Des appels indépendants à la même fonction peuvent se retrouver dans le même conteneur
- Des appels indépendants de la même fonction seront toujours effectués à l'aide de processus différents
- Mode de fonctionnement Watchdog du proxy inverse :
Si le runtime classique est similaire à CGI, alors ce mode d'exécution est similaire au dernier FastCGI . Le runtime s'attend à avoir un serveur HTTP de longue durée derrière le chien de garde, plutôt que de générer un nouveau processus chaque fois que la fonction est appelée. Cela transforme essentiellement le composant de surveillance en un proxy inverse : lorsque le conteneur démarre, le chien de garde du proxy inverse crée également un serveur HTTP léger écoutant sur le port 8080 . Cependant, contrairement au chien de garde classique , le chien de garde du proxy inverse ne crée le processus de la fonction qu'une seule fois et le traite comme un serveur en amont (de longue durée). L'appel de fonction se transforme alors en une requête HTTP vers cet amont.
Cependant, le mode reverse proxy n'a pas vocation à remplacer le mode classique . La force du mode classique est que ses fonctions sont très simples à écrire. C'est également la seule option pour le code sans serveur HTTP. Par exemple, les fonctions écrites dans des scripts Cobol, bash ou PowerShell, etc.
Quand utiliser le mode d'exécution du proxy inverse :
- La fonction doit maintenir l'état entre les appels :
- cache
- Connexions persistantes (par exemple, garder une connexion ouverte entre une fonction et une base de données)
- fonction avec état
- Démarrer un processus par fonction peut être coûteux, introduisant une latence pour chaque appel
- Vous souhaitez exécuter un (micro)service en tant que fonction
Selon Alex Ellis , le créateur d'OpenFaaS , FaaS , et OpenFaaS en particulier, peut être considéré comme un moyen simplifié de déployer des microservices sans s'appuyer sur des abstractions de serveur . Autrement dit, FaaS est l'exemple canonique d'une architecture sans serveur.
Ainsi, les fonctions peuvent être considérées comme un moyen avisé de déployer des microservices en utilisant une approche de proxy inverse. Pratique, rapide et facile. Mais lorsque vous utilisez des fonctions avec état, soyez conscient des avertissements en raison de la possibilité que plusieurs appels se retrouvent dans le même processus :
- Les appels simultanés qui aboutissent dans un processus peuvent déclencher des conditions de concurrence dans votre code (par exemple, une fonction Go avec une variable globale qui n'est pas protégée par un verrou).
- Les appels ultérieurs qui se retrouvent dans un processus peuvent entraîner des fuites de données entre appels (tout comme les microservices traditionnels, bien sûr).
- Étant donné que le processus est réutilisé entre les appels, toute fuite de mémoire dans le code ne sera pas désallouée.
Comparaison des modes de fonctionnement entre wathdog et reverse proxy watchdog :
（2）APIGateway
La passerelle Openfaas fournit un routage externe de l'interface RESTful pour les fonctions personnalisées, l'interface utilisateur intégrée, les requêtes faas-cli et API seront traitées et distribuées par la passerelle Openfaas.
La passerelle Openfaas intègre également Prometheus pour fournir des capacités de surveillance des fonctions et des services, et peut également appeler des API de fournisseur de faas pour gérer les conteneurs.
Faas-provider est un ensemble d'outils SDK implémenté en langage go qui est conforme à la norme API REST Http du fournisseur Openfaas.
Les principales responsabilités d'OpenFaaS API Gateway :
- Opérations CRUD sur les fonctions
- service d'appel de fonction proxy
- Gérer la mise à l'échelle des conteneurs de fonctions
- Gestion des clés de conteneur
- Écoulement des bûches
(3) Interface FaaS-Provider / réseaux de phase
Lecture de référence : La puissance des interfaces dans OpenFaaS (alexellis.io)
(3) Mise à l'échelle automatique
Lecture de référence : Autoscaling - OpenFaaS , Scale to Zero and Back Again avec OpenFaaS
(4) Appel de fonction asynchrone basé sur NATS
Les deux figures suivantes illustrent brièvement le processus d'appel des appels synchrones/asynchrones pour télécharger une fonction de fichier PDF et illustrent comment implémenter des appels de fonction asynchrones via NATS.
3. Autres
(1) Point de vue du développeur OpenFaaS
Lecture complémentaire :