xRPC sera bientôt disponible, découvrez plus de détails sur l'écosystème APISIX
API7.ai
January 21, 2021
À mesure que les scénarios et les exigences métier deviennent plus complexes et diversifiés, de plus en plus de normes et de protocoles émergent. Apache APISIX, en tant que projet open source de premier plan de la Fondation Apache, participe activement et promeut l'expansion des aspects liés à son écosystème.
Dans cet article, nous vous présenterons des exemples du futur framework xRPC d'Apache APISIX et des plugins multilingues sous deux angles : le proxy multiprotocole et le support multilingue.
Proxy Multiprotocole
Dans Apache APISIX, chaque requête correspond à un objet Route. Actuellement, il existe deux principaux scénarios de proxy pour Apache APISIX.
Le premier est le proxy de protocole HTTP, qui est actuellement le proxy de requêtes le plus couramment utilisé dans APISIX. Basé sur le proxy de protocole HTTP, Apache APISIX met en œuvre actuellement des dizaines de capacités de gestion du trafic, telles que le contrôle fin du flux, la sécurité et l'observabilité.
Le second est un proxy de protocole dynamique et un équilibrage de charge basés sur TCP et UDP, qui fournit les capacités d'admission de trafic les plus basiques ainsi que des capacités de journalisation au niveau des liens. Ce modèle de proxy peut gérer toute requête basée sur les protocoles TCP/UDP, comme MySQL, Redis, Mongo ou DNS. Cependant, comme il s'agit d'un proxy basé sur TCP/UDP sans protocoles de couche application supérieure, il ne peut obtenir que des informations de base sur le quaternion, ce qui le rend un peu moins évolutif.
Pourquoi xRPC
En raison des limitations de Stream Route en termes de proxy de protocoles, et de notre désir de prendre en charge davantage de protocoles de couche application sur APISIX pour servir plus d'utilisateurs et de scénarios d'application, le framework xRPC est né.
Le framework xRPC permet d'étendre très facilement les capacités de protocole, à la fois pour des protocoles de données spécifiques et privés, avec une granularité précise et un contrôle de niveau 7 similaire aux proxies de protocole HTTP, comme l'observabilité au niveau des requêtes, le contrôle d'accès avancé et les politiques de proxy.
Qu'est-ce que xRPC
xRPC signifie littéralement que X est une représentation abstraite d'une ressource de protocole. Et RPC est ce que nous considérons comme toutes les ressources passant par la passerelle en tant que processus de dispatch, c'est-à-dire qu'il s'agit d'un framework d'extension de protocole. Ainsi, en termes de positionnement, xRPC est un framework de base plutôt qu'une implémentation d'un protocole spécifique.
Comme vous pouvez le voir dans l'architecture ci-dessus, xRPC est un framework basé sur les extensions d'APISIX Core. Sur ce framework, les utilisateurs peuvent implémenter différents protocoles de couche application, comme Redis, MySQL, Mongo et Postgres. Sur ces différents protocoles, vous pouvez abstraire certains facteurs communs et implémenter des capacités de plugin associées afin que les différents protocoles puissent partager ces capacités.
Ainsi, le rôle principal de xRPC peut être résumé comme suit : fournir un accès à des protocoles de couche application standardisés, permettre le partage de capacités entre protocoles, et permettre aux utilisateurs d'étendre des protocoles personnalisés.
Exemples de scénarios d'application
Avec le framework de protocole xRPC en place, quels scénarios peut-il adresser ? Voici quelques exemples.
- Exemple 1 : Redis ne supporte pas TLS dans les versions antérieures. Si notre système contient plusieurs versions de Redis, et que nous ne pouvons pas mettre à niveau Redis en production pour certaines raisons, mais que nous avons besoin d'ajouter la capacité TLS. Dans ce cas, nous pouvons utiliser le protocole Redis basé sur xPRC pour résoudre cette situation.
- Exemple 2 : Lorsque nous voulons limiter la fréquence de certaines IP ou appelants et que nous souhaitons visualiser la fréquence de chaque source d'appel, ce que Redis ne supporte pas. Cela est parfaitement résolu en utilisant le protocole Redis, étendu par xRPC.
- Exemple 3 : Si vous souhaitez utiliser MySQL pour activer temporairement la fonction de requête lente, il vous suffit d'accéder au protocole MySQL et de configurer la politique pertinente dans APISIX, ce qui vous évite l'étape fastidieuse de vous connecter à chaque instance machine par machine.
Bien sûr, il existe de nombreux scénarios d'application similaires, et nous espérons qu'après la sortie de cette fonctionnalité, vous pourrez l'expérimenter et la pratiquer davantage dans des applications réelles. Le processus d'invocation de xPRC est illustré dans le diagramme suivant.
Une fois que les services en amont sont pris en charge par Apache APISIX, les différents services d'application en amont peuvent être gérés de manière unifiée. Des fonctions telles que la journalisation, la surveillance, la sécurité et le dépannage peuvent toutes être accomplies via un ensemble standardisé de politiques.
Phases d'implémentation prévues
La conception actuelle du framework xRPC d'Apache APISIX est initialement divisée en 5 phases.
- Phase 1 : Lecture des données et décodage du protocole.
- Phase 2 : Phase d'accès. Fournit une fonction d'accès aux plugins, permettant de réaliser des scénarios de demande en matière de sécurité, de contrôle de flux et d'accès.
- Phase 3 : Transfert de données et équilibrage de charge. Fournit un support d'accès pour des politiques et algorithmes d'équilibrage de charge personnalisés.
- Phase 4 : Envoi des données et encodage du protocole.
- Phase 5 : Phase de journalisation. Fournit un accès aux plugins pour réaliser des scénarios de demande de journalisation et de logging.
Écosystème Multilingue
Afin de répondre à une base de langages de calcul de plus en plus riche et étendue, la création d'un support de code pour un environnement multilingue est devenue le premier seuil pour faire face au développement technologique futur. Apache APISIX a également fait beaucoup d'exploration et de pratique sur la voie du développement multilingue.
Par exemple, il a récemment implémenté le support de WebAssembly. Pour plus de détails et de fonctionnalités, veuillez vous référer à l'article "Apache APISIX Embraces WASM Ecology". Bien sûr, le support de WASM dans Apache APISIX est encore expérimental, et nous continuerons à améliorer ce support à l'avenir. Si vous êtes intéressé par ce projet, n'hésitez pas à contribuer au projet wasm-nginx-module.
En attendant, Apache APISIX supporte déjà plusieurs langages de développement via le "xPluginRunner Multilanguage Plugin Runtime" avant que le support de WASM ne soit implémenté. C'est-à-dire que lors du développement de plugins APISIX, les utilisateurs peuvent écrire et étendre les plugins APISIX non seulement avec du code Lua, qui est nativement supporté par APISIX, mais aussi avec leurs langages familiers, comme Go, Java et Python.
xPluginRunner
L'implémentation de xPluginRunner est illustrée dans la figure ci-dessus. Le processus de communication entier est "avant" et "après" l'exécution des plugins intégrés, APISIX initiera des requêtes RPC locales au runtime de plugin de chaque langage. Dans le plugin runner, le calcul et le traitement des politiques au sein de chaque plugin sont implémentés, et le résultat est finalement renvoyé à APISIX pour une prise de décision ultérieure basée sur le résultat de la réponse.
Le xPluginRunner sert de pont de communication avec Apache APISIX, et implémente principalement l'analyse des protocoles de données privés et l'encapsulation et la désencapsulation des messages RPC.
Actuellement, la solution xPluginRunner d'Apache APISIX est à un stade relativement stable, et nous savons grâce aux retours de la communauté que certaines entreprises ont commencé à l'essayer dans des environnements de production. Si vous êtes intéressé par ce projet, vous êtes également invité à participer aux différents projets de plugins de langage de développement.
Enfin, nous vous montrerons comment développer des plugins APISIX basés sur Java Plugin Runner avec un exemple simple en Java.
Exemple de Java Plugin Runner
Tout d'abord, lors du développement du plugin, nous devons implémenter l'interface PluginFilter. La méthode name dans l'interface est principalement utilisée pour identifier et extraire le nom du plugin, et la méthode filter est utilisée pour filtrer la requête (c'est-à-dire exécuter la logique principale du plugin).
Un point supplémentaire à noter est que les paramètres request et response apparaissant dans le code ci-dessus ont une logique fixe dans le Runner (tous les Runners s'appliquent) :
- Si vous souhaitez que la requête continue à être transférée et que vous ne faites que quelques paramètres de politique (comme la réécriture des paramètres de la requête, des en-têtes, etc.), vous pouvez simplement manipuler l'objet
request. - Si vous souhaitez terminer la requête, vous pouvez le faire avec l'objet
response(par exemple, définir le corps de la réponse, les en-têtes de réponse, les codes d'état, etc.).
APISIX terminera la requête actuelle dès qu'il détecte que l'objet response dans le Runner a été manipulé.
Une fois le développement du plugin terminé, il est temps de pratiquer l'application dans APISIX.
Tout d'abord, compilez le Runner et les plugins du projet en fichiers jar et configurez le chemin absolu des fichiers jar dans le fichier de configuration principal d'APISIX de la manière suivante.
Enfin, redémarrez Apache APISIX et vous êtes prêt pour les sessions de configuration de routage et de plugin, ainsi que pour la validation des requêtes.
Résumé
Cet article vous présente la future sortie du framework xRPC pour Apache APISIX et les détails associés, ainsi qu'une démonstration détaillée du support de développement multilingue d'Apache APISIX.
L'article montre également les détails du support de développement multilingue d'Apache APISIX. Il montre les efforts orientés vers l'écosystème d'Apache APISIX à la fois sous l'angle du proxy multiprotocole et du support multilingue.
N'hésitez pas à démarrer une discussion dans GitHub Discussions ou à communiquer via la liste de diffusion.