Partie 1 : Comment construire une passerelle API Microservices avec OpenResty

Dans cet article, passons aux chapitres sur OpenResty en action. J'utiliserai trois chapitres pour vous présenter comment implémenter une passerelle API de microservices. Dans ce processus, nous aborderons non seulement les connaissances sur OpenResty que nous avons apprises précédemment, mais je vous montrerai également comment construire un nouveau produit et un projet open source à partir de zéro, en tenant compte de multiples dimensions telles que l'industrie, le produit et le choix technologique.

Que fait une passerelle API de microservices ?

Commençons par examiner le rôle de la passerelle API de microservices. L'image ci-dessous en donne une brève description :

Comme nous le savons tous, la passerelle API n'est pas un concept nouveau. Elle existe depuis plus de dix ans. Sa fonction principale est de servir d'entrée de trafic et de traiter les requêtes liées aux activités de manière unifiée. Ainsi, les requêtes peuvent être traitées de manière plus sûre, rapide et précise. Elle possède les fonctions traditionnelles suivantes :

• Proxy inverse et équilibrage de charge, qui sont cohérents avec le positionnement et les fonctions de NGINX ;
• Fonctions dynamiques telles que l'amont dynamique, le certificat SSL dynamique, et la limitation dynamique du débit et du taux en temps réel, qui sont des fonctions que la version open source de NGINX ne possède pas ;
• Vérifications de santé actives et passives des amonts, ainsi que les disjoncteurs de service ;
• Extension basée sur la passerelle API pour devenir une plateforme de gestion du cycle de vie complet des API.

Ces dernières années, le trafic lié aux activités n'est plus uniquement initié par les clients PC et les navigateurs, mais provient davantage des téléphones mobiles et des appareils IoT. Avec la popularisation future de la 5G, ce trafic augmentera. Parallèlement, avec l'évolution de la structure de l'architecture des microservices, le trafic entre les services commence également à croître de manière explosive. Dans ce nouveau scénario d'activité, de plus en plus de fonctions avancées de la passerelle API ont naturellement émergé :

1. Compatible avec le cloud natif, l'architecture doit devenir légère et facile à conteneuriser.
2. Intégration avec Prometheus, Zipkin, SkyWalking et d'autres composants de statistiques et de surveillance.
3. Support du proxy gRPC, et conversion de protocole entre HTTP et gRPC, transformant la requête HTTP de l'utilisateur en requête gRPC interne.
4. Assumer le rôle de partie dépendante OpenID, se connecter aux services des fournisseurs d'authentification tels que Auth0 et Okta, et considérer la sécurité du trafic comme une priorité absolue.
5. Réaliser le Serverless en exécutant dynamiquement les fonctions de l'utilisateur en temps réel, rendant les nœuds périphériques de la passerelle plus flexibles.
6. Ne pas enfermer les utilisateurs et supporter une architecture de déploiement hybride.
7. Le nœud de la passerelle doit être sans état et pouvoir s'étendre et se réduire à volonté.

Lorsqu'une passerelle API de microservices possède les fonctions mentionnées ci-dessus, le service de l'utilisateur peut se concentrer uniquement sur l'activité elle-même. Ces fonctions qui n'ont rien à voir avec la mise en œuvre de l'activité peuvent être résolues au niveau de la passerelle indépendante. Par exemple, la découverte de services, le disjoncteur, l'authentification, la limitation de débit, les statistiques, l'analyse de performance, etc.

De ce point de vue, la passerelle API peut remplacer toutes les fonctions de NGINX et gérer le trafic nord-sud ; elle peut également remplir le rôle du plan de contrôle Istio et du plan de données Envoy pour gérer le trafic est-ouest.

Pourquoi réinventer la roue ?

Parce que le statut de la passerelle API de microservices est si important, il a toujours été un champ de bataille, et les géants traditionnels de l'IT sont présents dans ce domaine depuis longtemps. Selon le rapport sur le cycle de vie des API publié par Gartner en 2018, Google, CA, IBM, Red Hat et Salesforce sont tous des leaders du marché, et Apache APISIX, plus familier aux développeurs, figure parmi les visionnaires.

Alors, la question est : pourquoi devons-nous réinventer une nouvelle roue ?

En bref, c'est parce qu'aucune des passerelles API actuelles pour les microservices ne répond à nos besoins. Examinons d'abord les produits commerciaux propriétaires. Ils ont des fonctions complètes, couvrant la gestion du cycle de vie complet des API, la conception, les SDK multilingues, la documentation, les tests et la publication, et fournissent des services SaaS. Certains sont intégrés au cloud public, ce qui est très pratique à utiliser. Mais en même temps, ils apportent également deux points douloureux.

Le premier point douloureux est le problème de l'enfermement sur une plateforme. La passerelle API est l'entrée du trafic d'activité. Contrairement au trafic non lié à l'activité accéléré par les CDN tels que les images et les vidéos, qui peuvent être migrés à volonté, la passerelle API liera beaucoup de logique liée à l'activité. Une fois que vous utilisez une solution propriétaire, il est difficile de migrer vers d'autres plateformes de manière fluide et à faible coût.

Le deuxième point douloureux est le problème de l'impossibilité de développement ultérieur. Généralement, les grandes et moyennes entreprises auront leurs propres besoins uniques et auront besoin d'un développement personnalisé, mais à ce moment-là, vous ne pouvez compter que sur le fabricant et ne pouvez pas faire de développement secondaire.

C'est une des raisons pour lesquelles les solutions open source de passerelle API sont devenues populaires. Cependant, les produits open source existants ne sont pas omnipotents et ont également de nombreuses lacunes :

1. Dépendance à des bases de données relationnelles telles que PostgreSQL et MySQL. De cette manière, le nœud de la passerelle ne peut interroger la base de données que lorsque la configuration change. Cela non seulement ralentit la prise d'effet de la configuration, mais ajoute également de la complexité au code, le rendant difficile à comprendre. En même temps, la base de données deviendra également un point unique et un goulot d'étranglement de performance du système, ce qui ne garantit pas une haute disponibilité globale. Si vous utilisez la passerelle API dans un environnement Kubernetes, la base de données relationnelle sera encore plus encombrante, ce qui n'est pas propice à une mise à l'échelle rapide.
2. Les plugins ne peuvent pas être chargés à chaud. Lorsque vous ajoutez un nouveau plugin ou modifiez le code d'un plugin existant, vous devez recharger le service pour qu'il prenne effet. C'est la même chose que la nécessité de recharger après avoir modifié la configuration de NGINX, ce qui affectera les requêtes des utilisateurs.
3. La structure du code est complexe et difficile à maîtriser. Certains projets open source ont fait des encapsulations orientées objet à plusieurs niveaux, et une logique simple est devenue floue. Mais, pour le scénario de la passerelle API, une expression directe sera plus claire et plus efficace, et elle est également plus propice au développement secondaire.

Par conséquent, nous avons besoin d'une passerelle API plus légère, compatible avec le cloud natif et conviviale pour le développement. Bien sûr, nous ne pouvons pas construire une voiture en vase clos. Nous devons comprendre en profondeur les caractéristiques des passerelles API existantes. À ce stade, le panorama de la Cloud Native Computing Foundation (CNCF) est une bonne référence :

Composants et concepts de base de la passerelle API

Bien sûr, avant de l'implémenter, nous devons comprendre les composants de base de la passerelle API. Selon les fonctions de la passerelle API que nous avons mentionnées précédemment, elle a besoin d'au moins les composants suivants pour fonctionner.

Le premier est Route. Il correspond à la requête du client en définissant certaines règles, puis charge et exécute le plugin correspondant en fonction du résultat de la correspondance, et transfère la requête à l'amont spécifié. Ces règles de correspondance de routage peuvent être composées de host, uri, header, etc. Le location familier dans NGINX est une implémentation du routage.

Le deuxième est le plugin, l'âme de la passerelle API. Des fonctions telles que l'authentification, la limitation de débit et de taux, la restriction d'IP, Prometheus, Zipkin, etc., sont toutes implémentées via des plugins. Comme il s'agit d'un plugin, il doit être plug-and-play ; de plus, les plugins ne peuvent pas interagir entre eux. Tout comme nous construisons des blocs Lego, nous devons utiliser des règles uniformes et des interfaces de développement convenues pour interagir avec la couche inférieure.

Ensuite, il y a le schema. Comme il s'agit d'une passerelle pour traiter les API, il est nécessaire de vérifier le format de l'API, comme les types de données, le contenu des champs autorisés, les champs obligatoires, etc. À ce stade, une couche de schema est nécessaire pour une définition et une vérification unifiées et indépendantes.

Enfin, il y a le stockage. Il est utilisé pour stocker les différentes configurations des utilisateurs et est responsable de les pousser vers tous les nœuds de la passerelle en cas de changement. C'est un composant de base très critique au niveau inférieur. Son choix détermine comment les plugins de la couche supérieure sont écrits, si le système peut maintenir une haute disponibilité et une extensibilité, etc., nous devons donc prendre une décision réfléchie.

En plus de ces composants de base, nous devons également abstraire plusieurs concepts communs des passerelles API, qui sont communs parmi les différentes passerelles API.

Route

Parlons d'abord de Route. Une route contiendra trois parties : les conditions de correspondance, les plugins liés et l'amont, comme le montre la figure suivante :

Nous pouvons effectuer toutes les configurations directement dans Route, ce qui est le plus simple. Mais dans le cas de nombreuses API et amonts, cela entraînera beaucoup de configurations en double. À ce stade, nous avons besoin des deux concepts de Service et Upstream pour faire une couche d'abstraction.

Service

Examinons ensuite Service. C'est une abstraction d'un certain type d'API, et peut également être comprise comme une abstraction d'un groupe de Routes. Il a généralement une correspondance 1:1 avec les services amont, et la relation entre Routes et Services est généralement N:1. J'ai également utilisé une image pour représenter cela :

Grâce à cette couche d'abstraction de Service, nous pouvons séparer les Plugins et Upstreams en double. Ainsi, lorsque le Plugin et l'Upstream changent, nous n'avons besoin de modifier que le Service au lieu de modifier les données liées à plusieurs Routes.

Upstream

Enfin, parlons d'Upstream. En continuant avec l'exemple ci-dessus, si les amonts dans les deux Routes sont les mêmes, mais que les plugins liés sont différents, alors nous pouvons abstraire les amonts séparément, comme le montre la figure suivante :

De cette manière, lorsque le nœud amont change, Route est complètement inconscient, et tout est traité à l'intérieur d'Upstream.

À partir du processus de dérivation de ces trois concepts principaux, nous pouvons également voir que ces abstractions sont basées sur des scénarios d'utilisation pratiques plutôt que sur l'imagination. Elles s'appliquent à toutes les passerelles API, indépendamment des solutions techniques spécifiques.

Résumé

Dans cet article, nous avons présenté le rôle, les fonctions, les composants de base et les concepts abstraits de la passerelle API de microservices, qui sont la base de la passerelle API.

Voici une question à laquelle vous pouvez réfléchir : "En ce qui concerne le trafic traditionnel nord-sud et le trafic est-ouest entre les microservices, pensez-vous que la passerelle API peut gérer les deux ?" Si vous utilisez déjà une passerelle API, vous pouvez également noter vos réflexions sur le choix technologique. N'hésitez pas à communiquer et à discuter, et vous êtes invités à partager cet article avec vos collègues et amis pour apprendre et progresser ensemble.

À suivre : Partie 2 : Comment construire une passerelle API de microservices avec OpenResty Partie 3 : Comment construire une passerelle API de microservices avec OpenResty