API Gateway pour Web3 : Comment APISIX renforce Hyperchain
August 9, 2021
Aperçu
En tant que fournisseur d'infrastructure et de solutions de blockchain de consortium de niveau entreprise de premier plan, Hyperchain Technologies s'engage à construire une infrastructure innovante et à favoriser le développement numérique de la société. Au cours de sa croissance rapide, Hyperchain a rencontré de nombreux problèmes lors de la mise en place de sa plateforme blockchain Hyperchain, notamment :
- Absence de gestion standardisée du trafic avec un risque potentiel d'effondrement du système
- Contrôle de sécurité et gestion de l'authentification incomplets
- Contrôle des permissions peu pratique
- Coût élevé des adresses IP publiques
- Instabilité des nœuds blockchain : un seul nœud vulnérable aux attaques
- Manque de gestion unifiée de plusieurs protocoles
Hyperchain a essayé Kong et NGINX, mais malheureusement, ils ne répondaient pas aux scénarios métier d'Hyperchain. Cependant, après avoir adopté Apache APISIX, tous les problèmes mentionnés ci-dessus ont été résolus, donnant à la plateforme blockchain Hyperchain une vitalité sans fin.
À propos de la plateforme blockchain Hyperchain
La plateforme blockchain Hyperchain consiste à intégrer le framework blockchain dans une plateforme de cloud computing, en tirant parti des avantages de déploiement et de gestion de l'infrastructure de services cloud. Il s'agit d'une plateforme blockchain ouverte qui peut fournir aux développeurs un écosystème blockchain pratique et performant ainsi que des services de support associés, tout en soutenant l'expansion et l'exploitation des activités des développeurs dans le web3.
La plateforme blockchain Hyperchain permet de construire rapidement et de manière flexible un réseau blockchain. Grâce à cette plateforme, les entreprises peuvent gérer leurs activités blockchain de manière unifiée. Par exemple, via la plateforme, il est possible de signer des contrats dans l'environnement de développement intégré, puis de déployer ces contrats sur le réseau blockchain créé. Le module de service supérieur peut appeler les contrats liés à la blockchain pour poursuivre le processus métier.
Comme il existe de nombreux nœuds dans la chaîne, allant de quelques dizaines à plusieurs milliers, il devient difficile de surveiller et de maintenir le fonctionnement de la chaîne sans le support de la plateforme. En utilisant la plateforme blockchain Hyperchain, les utilisateurs peuvent non seulement réduire les coûts, mais aussi gérer la blockchain plus facilement et renforcer la sécurité de l'ensemble du système.
Prenons l'exemple d'Hyperchain pour comprendre comment et pourquoi les entreprises blockchain devraient choisir Apache APISIX parmi les nombreuses passerelles API. Nous analyserons ci-dessous l'application d'APISIX dans la plateforme blockchain Hyperchain et dans les nœuds blockchain.
Application d'APISIX dans la plateforme blockchain Hyperchain
Voici un diagramme d'interaction d'application d'APISIX dans la plateforme blockchain Hyperchain. Le service backend enregistre les informations de service avec etcd en fonction de ses caractéristiques métier, puis enregistre le service avec APISIX via le module d'enregistrement de route.
APISIX agit comme l'entrée unifiée des microservices internes du système. Les requêtes externes sont d'abord envoyées à APISIX ; elles accèdent ensuite à la couche d'accès via l'API après avoir passé l'authentification, puis accèdent aux services principaux via RPC (appel de procédure à distance).
Routage des requêtes
Parfois, il est souhaitable d'exposer les API sous le même nom de domaine. Dans ce cas, nous pouvons ajouter des préfixes au chemin de l'API du même service, tels que /baas-core
ou /baas-other
. Lorsque le client demande ces API, la passerelle API doit supprimer ces préfixes ajoutés, puis transférer la requête au service backend. Le plugin proxy-rewrite d'APISIX peut nous aider à gérer facilement de tels cas.
Par exemple :
Lors de la visite : http://apisix:8080/baas-{service}/api/v1/…
La requête peut être transférée à http://{service}/api/v1/…
en écrivant une expression régulière : ^/baas-core/(.*)$,/$1
Gestion de la limitation du trafic
Les utilisateurs peuvent choisir des blockchains de consortium selon leurs besoins, non seulement celle d'Hyperchain mais aussi IBM Data Fabric, Baidu XuperChain, etc. Par conséquent, Hyperchain doit gérer le cycle de vie de toutes les blockchains de consortium dans le système.
Lors de la création d'une chaîne de consortium, Hyperchain n'a qu'à écrire le code sur la plateforme blockchain et télécharger les composants de pilote enfichables sur la plateforme blockchain pour les appeler afin de créer la chaîne de consortium. Dans certains cas de déploiement privé, les composants de pilote enfichables peuvent être supportés rapidement.
Chaque appel aux composants de pilote est un processus qui doit être limité, surtout lorsque le nombre est élevé. Par conséquent, le plugin limit-req d'APISIX peut être bénéfique pour limiter l'entrée et la sortie du trafic de la plateforme afin de garantir sa stabilité.
Le plugin limit-req permet une configuration personnalisée concernant le taux et le burst.
Contrôle de sécurité et gestion des autorisations
Pour collaborer avec APISIX, Hyperchain a développé un plugin pour les circonstances de déploiement privé. La partie A préfère souvent utiliser ses services d'authentification ou son système de comptes de service. Lorsque le trafic frontal visite le site, il passe d'abord par le plugin Access-auth, et il ne peut accéder au backend BFF (Backend for Frontend) que s'il passe l'authentification.
Selon les trois facteurs clés de la spécification standard Restful (les informations d'authentification, le chemin Restful et les verbes HTTP comme GET, POST, PUT, DELETE, PATCH, etc.), une authentification compte-rôle-autorité est effectuée. Si l'authentification est réussie, les informations utilisateur sont renvoyées dans l'en-tête ; sinon, elle renvoie un code 403.
Rechargement à chaud
APISIX offre un rechargement à chaud des plugins développés en interne. Cela permet de gagner du temps pendant le développement et permet aux utilisateurs de modifier des parties de leur code sans redémarrer l'ensemble du plugin runner. De cette manière, les développeurs peuvent apporter des ajustements à l'interface dans le backend, qui prennent effet immédiatement, ce qui est pratique et convivial pour la mise en ligne.
Pourquoi pas Kong ?
Hyperchain avait utilisé Kong auparavant mais l'a finalement remplacé par Apache APISIX principalement parce que :
-
Coût élevé de déploiement et de maintenance
Le cluster Kong nécessite une collaboration avec la base de données Postgresql et nécessite un administrateur de base de données spécifique pour une haute disponibilité. Le déploiement en cluster de la base de données Postgresql est relativement difficile à mettre en œuvre et augmente le coût de l'exploitation et de la maintenance ultérieures.
-
Augmentation de la complexité du système et du taux de défaillance
La plateforme blockchain Hyperchain utilise la base de données MySQL, ce qui entraîne la présence de deux bases de données relationnelles dans le système si Kong est adopté, ce qui rend le système plus complexe. Cela augmente également le taux de défaillance en améliorant la compatibilité entre les deux ensembles de bases de données.
Application d'APISIX dans les nœuds blockchain
Réduction des coûts sur les adresses IP publiques
L'utilisateur achète des blockchains via la plateforme blockchain Hyperchain. Ensuite, les entreprises de niveau supérieur et les clients développeurs peuvent se connecter aux nœuds. Les services peuvent se connecter à un ou plusieurs nœuds, et les utilisateurs peuvent accéder à un ou plusieurs nœuds, ce qui pose un problème : presque tous les nœuds seront visités, ce qui augmente la pression de visite sur un seul nœud.
Cela est relativement facile à gérer dans certains environnements de déploiement privé. Cependant, trop de nœuds et d'adresses IP publiques sont nécessaires pour les systèmes ciblant les utilisateurs internet. Le prix de chaque adresse IP publique de 4 mégaoctets de trafic peut atteindre près de 200 CNY par mois. Il y a des milliers de nœuds sur la plateforme Hyperchains, ce qui entraîne des coûts élevés en adresses IP publiques.
APISIX gère toutes les demandes de visite et distribue le trafic aux nœuds blockchain correspondants. De cette manière, Hyperchain a réalisé des économies importantes.
Contrôle des permissions pratique
Il existe diverses blockchains sur la plateforme blockchain Hyperchain, et chaque chaîne a un contrôle des permissions RBAC complexe. Par conséquent, différents types de certificats doivent être ajoutés côté client, tels que les certificats TLS, ce qui pose également des problèmes aux utilisateurs.
Actuellement, le plugin key-auth d'APISIX peut être utilisé pour résoudre ce problème efficacement. Les utilisateurs autorisés peuvent accéder directement à la blockchain sans se soucier de la configuration des permissions, car APISIX unifie la couche sous-jacente de la chaîne.
Le clustering améliore la stabilité des nœuds
Comme mentionné précédemment, les nœuds sont fréquemment visités. Une haute concurrence existe chez la plupart des utilisateurs bancaires, car le TPS (Transactions Par Seconde) peut atteindre 40 000 à 50 000 fois.
Il s'avère qu'un seul nœud sur la blockchain est vulnérable car chaque transaction a un impact sur le nœud visité.
Hyperchain a déployé Apache APISIX sur K8s avec le Horizontal Pod Autoscaler. Comme APISIX utilise etcd avec une bonne extensibilité dynamique, il peut résoudre efficacement le problème de l'impact du trafic sur un seul point.
Support de plusieurs protocoles
Les protocoles des chaînes hétérogènes sur la plateforme blockchain Hyperchain sont divers, tels que le protocole HTTP, le protocole Websocket, le protocole gRPC, le protocole TCP, le protocole UDP, etc.
APISIX supporte plusieurs protocoles, s'adaptant de manière flexible aux couches sous-jacentes des différentes blockchains, réduisant ainsi les coûts de développement.
Pourquoi pas NGINX ?
Il semble qu'Hyperchain pourrait utiliser NGINX pour résoudre ses problèmes. Cependant, après l'essai, Hyperchain l'a abandonné car :
-
Inadapté à l'expansion dynamique
Hyperchain doit ajouter et supprimer fréquemment des nœuds dans la plateforme blockchain, ce qui ne prend effet qu'après un redémarrage, ce qui est peu pratique pour les développeurs. De plus, les développeurs doivent écrire un code de règles complexe pour les plugins dans le fichier conf de NGINX.
-
Difficulté de clustering
NGINX ne supporte pas le clustering, ce qui est relativement complexe et peu convivial pour les utilisateurs.
-
Pas de support direct pour TCP et UDP
NGINX ne peut proxier que le protocole de couche 7 plutôt que le protocole de couche 4 et ne peut pas directement supporter les protocoles TCP et UDP. De plus, le module n'est pas compilé par défaut, nécessitant un traitement supplémentaire.
-
Pas de tableau de bord
Il n'y a pas d'interface visuelle pour NGINX, ce qui rend difficile pour les développeurs et les opérateurs de gérer autant de nœuds.
Résumé
D'après ce qui précède, nous savons qu'Apache APISIX est une passerelle API dynamique qui peut être appliquée dans le domaine de la blockchain. De plus, Apache APISIX fournit des fonctionnalités riches de gestion du trafic comme l'équilibrage de charge, l'upstream dynamique, la publication canari, la rupture de circuit, l'authentification, l'observabilité, etc.
Nous espérons qu'APISIX pourra soutenir davantage d'entreprises blockchain pour entrer dans une nouvelle phase de développement. Bienvenue pour en savoir plus sur Apache APISIX. Vous pouvez nous contacter à https://api7.ai/contact.