FAQ OpenResty | Comment OpenResty est utilisé en pratique

API7.ai

February 10, 2023

OpenResty (NGINX + Lua)

  1. Quelques questions-réponses sur OpenResty, API Gateway et Lua
  2. FAQ OpenResty | Permissions des processus privilégiés, phases d'exécution et plus
  3. FAQ OpenResty | Structure réseau pour les tests, fonctionnalités liées à SSL, DSL, outil ab
  4. FAQ OpenResty | Chargement dynamique, NYI et mise en cache de Shared Dict

À ce stade, nous avons terminé la dernière section sur OpenResty, la passerelle API pour les microservices. Félicitations pour ne pas avoir pris de retard, pour avoir appris et pratiqué activement, et pour avoir laissé vos réflexions avec enthousiasme.

J'ai sélectionné quelques questions typiques et intéressantes ici pour les partager avec vous. Examinons ces 5 questions pour aujourd'hui.

Question 1 : Comment OpenResty est utilisé en pratique

Description : Le cours est presque terminé, et je peux globalement le comprendre, mais ma propre pratique est encore limitée (je ne l'utilise pas actuellement dans mon travail). Cependant, c'est une série d'articles très utile. Merci à l'auteur de continuer à partager, et je l'introduirai plus tard dans mon travail.

Je voudrais parler de l'introduction d'OpenResty au travail, un sujet qui mérite d'être discuté.

OpenResty est basé sur NGINX et ajoute le module C lua-nginx-module ainsi que de nombreuses bibliothèques lua-resty, donc OpenResty est une bonne alternative à NGINX, ce qui est la manière la plus économique de commencer à utiliser OpenResty. Bien sûr, ce processus de remplacement comporte des risques, donc vous devez être conscient des trois points suivants.

Premièrement, assurez-vous que la version de NGINX en ligne est la même que la version principale d'OpenResty, par exemple OpenResty 1.15.8.1 utilise NGINX 1.15.8. Si la version actuelle de NGINX en ligne est plus récente que la dernière version d'OpenResty, vous devez procéder avec prudence. Après tout, OpenResty est encore lent à se mettre à jour et est en retard de six mois à un an par rapport à la version principale de NGINX. Si la version de NGINX en ligne est la même ou inférieure à celle d'OpenResty, alors vous avez les prérequis pour la mise à niveau.

Deuxièmement, les tests. Les tests sont l'un des aspects les plus importants. Il y a peu de risques à utiliser OpenResty pour remplacer NGINX, mais des risques existent toujours. Par exemple, s'il y a des modules C personnalisés qui doivent être compilés, la version d'openssl dont dépend OpenResty, et si le patch qu'OpenResty applique à NGINX aura un impact sur l'activité. Vous devez reproduire une partie du trafic métier pour vérifier cela.

Troisièmement, le basculement du trafic. Après la validation de base, vous devez encore vérifier la mise en production progressive du trafic réel en ligne. Pour revenir rapidement en arrière, nous pouvons ouvrir quelques nouveaux serveurs pour déployer OpenResty au lieu de remplacer directement le service NGINX d'origine. S'il n'y a pas de problèmes, nous pouvons soit mettre à jour le fichier binaire à chaud, soit progressivement retirer et remplacer NGINX du LB pour effectuer la mise à niveau.

En plus de remplacer NGINX, OpenResty a deux autres points d'entrée faciles : WAF et les passerelles API. Ces deux scénarios ont des exigences élevées en termes de performance et de dynamisme et ont des projets open source correspondants qui peuvent être utilisés directement, ce que j'ai couvert en partie auparavant.

Si nous continuons à approfondir OpenResty au niveau métier, nous devons prendre en compte plus de facteurs au-delà de la technologie, comme la facilité à recruter des ingénieurs spécialisés en OpenResty, si OpenResty peut s'intégrer aux systèmes techniques existants de l'entreprise, etc.

Généralement, il est bon de commencer par remplacer NGINX et ensuite d'étendre progressivement l'utilisation d'OpenResty.

Question 2 : Encapsulation de base de données pour OpenResty

Description : Selon l'article précédent, nous devrions utiliser .. (opérateur de concaténation de chaînes) le moins possible, surtout dans le chemin critique du code. Mais lors de l'accès à la base de données, je dois construire des instructions SQL dynamiquement en insérant des variables dans les instructions, ce qui devrait être un scénario d'utilisation courant. Mais pour cette exigence, je pense que la concaténation de chaînes est la manière la plus simple, et je ne vois pas d'autre moyen simple et performant.

Vous pouvez d'abord analyser avec SystemTap ou d'autres outils que nous avons présentés dans les articles précédents pour voir si la concaténation des instructions SQL est le goulot d'étranglement du système. Si ce n'est pas le cas, il n'est pas nécessaire de l'optimiser. Après tout, l'optimisation prématurée est la racine de tous les maux.

Si le goulot d'étranglement est effectivement la concaténation des instructions SQL, alors nous pouvons utiliser l'instruction prepare de la base de données pour faire l'optimisation ou un tableau pour faire la concaténation. Mais le support de prepare par lua-resty-mysql est en statut TODO, donc nous ne pouvons utiliser que la concaténation par tableau. C'est aussi un problème courant avec certaines bibliothèques lua-resty, qui implémentent la plupart des fonctionnalités et fonctionnent normalement mais ne sont pas mises à jour à temps. En plus de l'instruction prepare de la base de données, lua-resty-redis n'a pas de support pour cluster.

La concaténation de chaînes et les bibliothèques lua-resty sont le genre de problèmes qu'OpenResty veut résoudre complètement avec DSL - en utilisant la technologie du compilateur pour générer automatiquement des tableaux pour concaténer des chaînes, en cachant ces détails aux utilisateurs de niveau supérieur ; en utilisant DSL wirelang pour générer automatiquement diverses bibliothèques de communication réseau lua-resty, éliminant ainsi le besoin de les écrire manuellement.

Cela semble merveilleux, n'est-ce pas ? Mais nous devons faire face à un problème : le code généré automatiquement est peu convivial pour les développeurs. Si vous voulez apprendre ou modifier le code généré, vous devez apprendre la technologie du compilateur et un DSL qui pourrait ne pas être open source, ce qui rend la barrière à l'entrée dans la communauté de plus en plus élevée.

Question 3 : Framework Web pour OpenResty

Description : Je veux faire un projet Web avec OpenResty, mais c'est pénible principalement parce que je ne trouve pas de framework mature, et je dois construire beaucoup de roues. Par exemple, le problème des opérations de base de données. Je n'ai pas trouvé de bibliothèque qui peut construire dynamiquement des instructions SQL et des opérations cohérentes. Donc, je voudrais demander à l'auteur, pourriez-vous recommander un bon framework web ?

Dans le dépôt awesome-resty, nous pouvons voir qu'il y a une catégorie spéciale pour les frameworks web, il y a 20 projets open source, mais la plupart sont stagnants. Parmi eux, Lapis, lor et vanilla sont trois projets que vous pouvez essayer pour voir lequel est le plus adapté.

En effet, sans un framework web solide pour le soutenir, OpenResty est submergé lorsqu'il s'agit de grands projets, ce qui est l'une des raisons pour lesquelles peu de gens utilisent OpenResty pour les systèmes métier.

Question 4 : Comment changer le content-length dans l'en-tête de réponse après avoir modifié le corps de la réponse ?

Description : Si je dois modifier le contenu du corps de la réponse, je ne peux faire des modifications que dans le filtre de corps, mais cela entraînera une incohérence entre la longueur du corps et la longueur de content-length. Comment devrais-je gérer cela ?

Dans ce cas, nous devons définir l'en-tête de réponse content-length à nil dans la phase de filtre d'en-tête avant le filtre de corps et ne pas le retourner, puis diffuser la sortie.

Voici un exemple de code :

server {
    listen 8080;
    location /test {
            proxy_pass http://api7.ai;
            header_filter_by_lua_block {
                     ngx.header.content_length = nil
            }
            body_filter_by_lua_block {
                    ngx.arg[1] = ngx.arg[1] .. "abc"
            }
     }
}

Comme vous pouvez le voir dans ce code, dans la phase de filtre de corps, ngx.arg[1] représente le corps de la réponse. Si nous ajoutons la chaîne abc après, l'en-tête de réponse content-length sera inexact, donc nous pouvons le désactiver dans la phase de filtre d'en-tête.

De plus, cet exemple montre comment les différentes phases d'OpenResty fonctionnent ensemble, ce que j'espère que vous remarquerez et réfléchirez.

Question 5 : Chemins des packages Lua dans OpenResty

Description : Le lua_package_path semble être configuré comme le chemin de recherche des dépendances Lua. Pour content_by_lua_file, j'ai expérimenté et constaté qu'il ne recherche que sous le préfixe basé sur le chemin relatif au fichier fourni par la directive, et non sous lua_package_path. Je ne sais pas si ma compréhension est correcte.

lua_package_path est utilisé pour charger les modules Lua, par exemple, lorsque nous appelons require 'cjson', nous allons dans le répertoire spécifié dans lua_package_path et cherchons le module cjson. En revanche, content_by_lua_file est suivi d'un chemin de fichier sur le disque.

location /test {
     content_by_lua_file /path/test.lua;
 }

Si ce n'est pas un chemin absolu mais un chemin relatif.

 content_by_lua_file path/test.lua;

Alors une concaténation sera faite en utilisant le répertoire -p spécifié au démarrage d'OpenResty pour obtenir le chemin absolu.

Enfin, vous êtes invités à continuer à écrire vos questions dans la section des commentaires, et je continuerai à y répondre. J'espère qu'à travers la communication et les questions-réponses, je pourrai vous aider à transformer ce que vous apprenez en ce que vous obtenez. Vous êtes également invités à partager cet article afin que nous puissions communiquer et nous améliorer ensemble.