Quelle est la différence entre OpenResty et NGINX ?
API7.ai
September 9, 2022
Les avantages d'OpenResty sont évidents. Avant d'entrer dans les détails, passons brièvement en revue le processus de développement d'OpenResty, ce qui vous aidera à mieux comprendre le contenu qui suit.
Processus de développement d'OpenResty
OpenResty n'a pas été construit à partir de zéro comme d'autres langages de développement, mais repose sur des composants open source matures - NGINX et LuaJIT. OpenResty est né en 2007, mais sa première version n'a pas choisi Lua, mais Perl, ce qui est largement dû à la préférence technique de l'auteur.
Cependant, les performances de Perl étaient loin de répondre aux exigences, donc dans la deuxième version, Perl a été remplacé par Lua. Cependant, dans le projet officiel d'OpenResty, Perl joue toujours un rôle important. Les projets de l'écosystème OpenResty sont construits avec Perl, comme le framework de test, Linter, CLI, etc. Nous les présenterons progressivement plus tard.
Parce que les avantages de haute performance et de dynamisme d'OpenResty sont très adaptés aux besoins des activités CDN, OpenResty est rapidement devenu la norme technique des CDN. De plus, grâce aux riches bibliothèques lua-resty-*, OpenResty a commencé à se libérer progressivement de l'ombre de NGINX et à former son propre écosystème, largement utilisé dans les passerelles API, les WAF logiciels, et d'autres domaines.
Je dis souvent qu'OpenResty est une technologie largement utilisée, mais pas une technologie à la mode, ce qui semble contradictoire. Qu'est-ce que cela signifie ?
Elle est largement utilisée car OpenResty est maintenant le cinquième serveur web le plus utilisé au monde.
Elle n'est pas populaire car la proportion d'utilisation d'OpenResty pour construire des systèmes métier n'est pas élevée. La plupart des utilisateurs utilisent OpenResty pour traiter le trafic d'entrée, et ils ne plongent pas profondément dans le métier. Donc naturellement, l'utilisation d'OpenResty est seulement superficielle, et suffit à répondre aux besoins actuels. Cela est bien sûr aussi lié au manque de frameworks web matures et d'écosystèmes comme Java et Python pour OpenResty.
Après avoir dit tout cela, je vais maintenant me concentrer sur quelques aspects du projet open source OpenResty qui méritent d'être loués et appris.
Points forts d'OpenResty
Documentation détaillée et cas de test
Oui, la documentation et les tests sont des indicateurs critiques de la fiabilité d'un projet open source, même avant la qualité du code et les performances.
La documentation d'OpenResty est très détaillée, et l'auteur a écrit chaque point à noter dans la documentation. La plupart du temps, il suffit de lire attentivement la documentation pour résoudre le problème rencontré sans avoir à chercher sur Google ou à parcourir le code source. Pour plus de commodité, OpenResty est également livré avec un outil en ligne de commande, restydoc, conçu pour vous aider à consulter la documentation via le shell et éviter les interruptions dans le processus de codage.
Cependant, il n'y a qu'un ou deux extraits de code disponibles dans la documentation, et il n'y a pas d'exemples complets et complexes. Où puis-je trouver de tels exemples ?
Pour OpenResty, c'est naturellement le répertoire /t, qui contient tous les cas de test. Chaque cas de test comprend la configuration complète de NGINX et le code Lua, ainsi que les données d'entrée de test et les sorties attendues. Cependant, le framework de test d'OpenResty est entièrement différent des autres frameworks de test de type assertion, que je présenterai plus tard dans un chapitre particulier.
Synchronisation non bloquante
La coroutine est une nouvelle fonctionnalité que de nombreux langages de script ont ajoutée ces dernières années pour améliorer les performances. Mais elles ne sont pas parfaitement implémentées, certaines sont du sucre syntaxique, et d'autres nécessitent des déclarations explicites de mots-clés.
OpenResty a supporté les coroutines dès le début et implémente un modèle de programmation synchrone non bloquant. Ceci est important car les programmeurs sont aussi des humains, et le code devrait être plus aligné avec les habitudes de pensée humaines. Les rappels explicites et les mots-clés async interrompent la pensée et rendent le débogage difficile.
Alors, qu'est-ce que la synchronisation non bloquante ? Parlons d'abord de la synchronisation. C'est très simple : exécuter séquentiellement selon le code. Par exemple, le pseudocode suivant :
local res, err = query-mysql(sql) local value, err = query-redis(key)
Dans la même requête, si nous devons attendre que le résultat de la requête MySQL revienne avant de continuer à interroger Redis, c'est synchrone ; si nous n'avons pas besoin d'attendre le retour de MySQL et que nous pouvons continuer à interroger Redis, alors c'est asynchrone. Pour OpenResty, la plupart des opérations sont synchrones. Seules les API liées aux minuteries en arrière-plan, comme ngx.timer, sont des opérations asynchrones.
Quant au non-blocage, qui est un concept facilement confondu avec l'asynchrone, lorsque nous parlons de blocage ici, nous entendons bloquer le thread du système d'exploitation. Continuons avec l'exemple ci-dessus, en supposant qu'il faut 1s pour interroger MySQL. Si pendant cette 1s, les ressources du système d'exploitation (CPU) sont inactives et attendent bêtement le retour, c'est du blocage ; si le CPU profite de l'occasion pour traiter d'autres demandes de connexion, c'est du non-blocage. Le non-blocage est également la clé pour réaliser des concurrences élevées comme C10K et C100K.
Le concept de synchronisation non bloquante est essentiel. Cependant, à mon avis, ce concept ne devrait pas être compris par analogie car une analogie inappropriée risque de vous embrouiller encore plus.
Dans OpenResty, le pseudocode ci-dessus peut directement réaliser la synchronisation non bloquante sans mots-clés explicites. Cela montre encore une fois que faciliter l'utilisation pour les développeurs est l'un des concepts d'OpenResty.
Dynamisme
Un énorme avantage d'OpenResty, qui n'a pas été pleinement exploité, est son dynamisme.
Les serveurs web traditionnels, comme NGINX, nous obligent à modifier le fichier de configuration sur le disque et à le recharger pour qu'il prenne effet en cas de changement, car ils ne fournissent pas d'API pour contrôler le comportement en temps d'exécution. Par conséquent, dans les microservices nécessitant des changements fréquents, NGINX a essayé plusieurs fois, mais rien n'a été amélioré. Et l'émergence soudaine d'Envoy, avec l'API de contrôle dynamique xDS, pose une menace significative d'attaques de réduction de dimension à NGINX.
Contrairement à NGINX et Envoy, OpenResty est contrôlé par le langage de script Lua, et le dynamisme est un avantage naturel de Lua. Par exemple, grâce à l'API Lua fournie dans le module lua-nginx-module d'OpenResty, nous pouvons contrôler dynamiquement les routes, les upstreams, les certificats SSL, les requêtes, les réponses, etc. Plus encore, nous pouvons modifier la logique de traitement du métier sans redémarrer OpenResty, sans être limité à l'API Lua fournie par OpenResty.
Voici une excellente analogie pour vous aider à comprendre ce qui a été dit sur le dynamisme ci-dessus. Imaginez simplement un serveur web comme une voiture qui roule à grande vitesse sur l'autoroute, NGINX doit s'arrêter pour changer les pneus et la couleur de la peinture ; Envoy peut changer les pneus et les couleurs en roulant ; et OpenResty, en plus des capacités précédentes, peut aussi se transformer en SUV sans s'arrêter.
Après avoir maîtrisé cette capacité magique, le cercle de compétence et l'imagination d'OpenResty se sont étendus à d'autres domaines, comme le Serverless et l'informatique en périphérie.
Que devrions-nous apprendre ?
Après avoir parlé de tant de fonctionnalités clés d'OpenResty, que devrions-nous apprendre ? Je préfère me concentrer sur la ligne principale plutôt que de saisir les détails pour que nous puissions construire un système de connaissances avec un contexte clair.
Vous devez savoir que peu importe à quel point un cours est complet, il est impossible de couvrir tous les problèmes et ne peut pas directement vous aider à résoudre chaque bug et exception en ligne.
Revenons à l'étude d'OpenResty, à mon avis, si vous voulez bien apprendre OpenResty, vous devriez comprendre les huit points clés suivants :
- Modèle de programmation synchrone non bloquant
- Rôle des différentes phases Request/Response
- Différences entre LuaJIT et Lua
- API OpenResty et bibliothèques environnantes
- Coroutine et cosocket
- Framework de test unitaire et outils de test de performance
- Graphique de flamme et chaîne d'outils environnante
- Optimisation des performances
Ces points sont essentiels dans notre étude, et je les aborderai séparément dans chaque chapitre. Cependant, dans le processus d'apprentissage, j'espère que vous pourrez tirer des conclusions et lire certains chapitres en profondeur selon vos intérêts et votre contexte.
Si vous êtes un débutant avec OpenResty, vous pouvez suivre la progression du cours, installer OpenResty dans votre environnement, et exécuter et modifier le code d'exemple. N'oubliez pas, votre objectif est de construire une vue d'ensemble d'OpenResty, pas de vous attarder sur un seul point de connaissance. Bien sûr, si vous avez des questions, n'hésitez pas à nous contacter en chat en direct.
Si vous utilisez OpenResty dans votre projet, c'est génial ! Cependant, je crois que lorsque vous lirez les chapitres sur LuaJIT et l'optimisation des performances, vous aurez plus de résonance et d'applications pratiques, et vous verrez l'amélioration des performances avant et après l'optimisation dans votre projet.
De plus, si vous souhaitez contribuer au code d'OpenResty et aux bibliothèques environnantes, le plus grand obstacle n'est pas de comprendre les principes d'OpenResty ou de savoir écrire des modules C NGINX, mais les cas de test et les normes de code. J'ai vu trop de contributeurs d'OpenResty (moi y compris) modifier à plusieurs reprises les cas de test et les styles de code sur un PR, et il y a trop de règles non écrites. Donc, les sections sur les normes de code et les tests unitaires du cours sont pour vous.
Et si vous êtes un ingénieur QA, même si vous n'utilisez pas OpenResty, le framework de test d'OpenResty et l'ensemble d'outils d'analyse de performance vous donneront beaucoup d'inspiration. Après tout, l'investissement et l'accumulation d'OpenResty dans les tests sont assez profonds.