Apache APISIX unifie la gestion complète du trafic avec Service Mesh

Avec la croissance rapide du Cloud Native, le Service Mesh commence également à gagner en popularité. Actuellement, il existe de nombreuses solutions de Service Mesh bien connues, et chaque produit a ses propres avantages. Par conséquent, les décisions concernant les solutions de Service Mesh varient d'une personne à l'autre en fonction des différents secteurs ou contextes métier.

Situation actuelle et points de douleur du Service Mesh

L'émergence du Service Mesh est étroitement liée à l'évolution actuelle de l'architecture métier. Avec la tendance croissante du Cloud Native, la plupart des entreprises ont commencé à se transformer en microservices, où nous avons constaté que les applications devenaient de plus en plus petites, et chaque application contenait des éléments communs. Nous avons donc commencé à nous demander : "Existe-t-il une technologie capable de résoudre ce scénario commun ?" C'est ainsi que le Sidecar est apparu.

Avec le Sidecar, certaines fonctions telles que l'enregistrement et la découverte de services, la gestion du trafic, l'observabilité et la sécurité peuvent être déléguées à celui-ci, permettant ainsi aux services métier de se concentrer sur le développement de la logique métier.

Cependant, l'émergence du Sidecar a fait prendre conscience de certains points de douleur dans la pratique, tels que :

Il existe tellement de solutions qu'il est difficile de migrer une fois choisie. Aujourd'hui, il existe de nombreuses solutions de Service Mesh, et les caractéristiques et capacités varient d'une solution à l'autre. Une fois qu'une de ces solutions est choisie, elle est utilisée sans possibilité de remplacement. Cependant, si nous constatons que la solution ne répond pas aux nouveaux besoins lorsque l'activité se développe, les coûts de migration sont énormes.
Coût élevé d'intégration avec l'infrastructure. Le Service Mesh mis en œuvre dans la pratique nécessite souvent une intégration avec les infrastructures, comme les architectures microservices précédentes, les composants MQ ou les infrastructures de base de données. Certains problèmes hérités ou dettes techniques historiques peuvent également créer des résistances au processus d'intégration.
Perte de performance et consommation supplémentaire de ressources. Actuellement, quelle que soit la solution de Service Mesh choisie, elle entraînera une certaine perte de performance. De plus, en raison du Sidecar, des ressources supplémentaires doivent être allouées lors de la configuration de l'activité.
Difficulté importante de mise à l'échelle. Certaines solutions de Service Mesh ne sont pas extensibles en termes de protocoles ou de fonctionnalités avec les méthodes de configuration existantes, et elles ne sont pas personnalisables par branchement et débranchement.

Par conséquent, face à la situation métier et aux points de douleur, nous avons commencé à réfléchir à la possibilité d'une solution de Service Mesh idéale qui pourrait résoudre ces problèmes.

À quoi ressemble un Service Mesh idéal ?

Dans les scénarios métier, nos exigences pour le Service Mesh sont, comme indiqué ci-dessus, c'est-à-dire qu'il existe plusieurs dimensions d'exigences dans les directions des ressources, de la performance, de la gestion du trafic et de la mise à l'échelle. Bien sûr, en plus de cela, il y aura également des exigences plus détaillées dans d'autres dimensions. Par exemple :

Tout d'abord, au niveau de l'expérience d'utilisation, il est nécessaire d'atteindre un coût d'entrée plus faible, car il peut y avoir plus d'opérations d'exploitation et de maintenance pour appliquer le Service Mesh que pour les développeurs. Par conséquent, le coût d'entrée est l'un des facteurs qui influencent le choix d'une solution.
Deuxièmement, au niveau technique, la configuration du plan de contrôle doit être facile à démarrer. En même temps, les permissions pertinentes doivent être strictement et sûrement contrôlées, et la configuration doit être plus proche du niveau public.
Du côté des données, il est préférable de prendre en charge nativement plusieurs protocoles, voire des protocoles personnalisés, car vous devez prendre en compte les problèmes causés par la migration de certains systèmes historiques. En raison de la présence du Sidecar, il faut également considérer que son empreinte sur les ressources est gérable afin de contrôler efficacement les coûts. L'extensibilité est également nécessaire pour la personnalisation.
Enfin, dans l'ensemble de l'écosystème du produit, tant la communauté que la réparation du produit doivent correspondre à la vitesse de "réponse rapide".

Puisque nous avons des exigences et des objectifs aussi clairs, l'étape suivante consiste à mettre en œuvre et à construire une solution aussi proche de l'idéal.

Solution de Service Mesh basée sur APISIX

Apache APISIX est une passerelle API cloud-native dynamique, en temps réel et haute performance, qui fournit des fonctionnalités riches de gestion du trafic telles que l'équilibrage de charge, l'amont dynamique, la publication canari, le disjoncteur, l'authentification, l'observabilité, et plus encore.

Des centaines d'entreprises dans le monde utilisent déjà Apache APISIX pour gérer le trafic critique de leur activité, couvrant des secteurs tels que la finance, l'Internet, la fabrication, la vente au détail, les opérateurs, etc., comme la NASA, la Plateforme d'usine européenne, China Airlines, China Mobile, Tencent, Huawei, Weibo, Netease, Ke Holdings Inc., 360, Taikang, Nayuki Holdings Limited, etc. Par conséquent, la solution de Service Mesh basée sur APISIX sera fortement demandée, non seulement en termes de niveau d'utilisation, mais aussi face à différents secteurs industriels.

L'architecture de la solution actuelle de Service Mesh est basée sur Istio comme plan de contrôle et APISIX comme plan de données.

Tout d'abord, nous avons choisi Istio comme plan de contrôle, car Istio est la solution de Service Mesh la plus populaire aujourd'hui, et elle dispose d'une communauté active, ce qui fait que presque tous les fournisseurs de cloud grand public prennent en charge Istio, et cela représente également dans une certaine mesure la demande et la direction actuelles du marché. Donc, en ce qui concerne le choix du plan de contrôle, il n'y a pas eu de module développé en interne. Au lieu de cela, nous avons choisi d'adopter Istio, qui est plus adapté et a un taux d'acceptation plus élevé.

Le plan de données est là où Apache APISIX peut tirer son avantage. En tant que passerelle API cloud-native, quelles actions APISIX a-t-elle prises en tant que plan de données d'Istio dans cette solution de Service Mesh ?

Les personnes familières avec APISIX savent que APISIX utilise etcd pour le stockage des données. Mais si nous utilisons APISIX comme Sidecar, d'où vient sa configuration ? C'est la question à considérer. Si nous intégrons également le composant etcd dans le Sidecar, nous constaterons que la consommation globale des ressources est très élevée et pas assez flexible.

Par conséquent, dans ce processus, nous avons d'abord ajouté un centre de configuration appelé xDS à APISIX pour éliminer le besoin d'etcd, puis introduit Amesh, comme indiqué ci-dessus, un programme Go compilé en une bibliothèque de liens dynamiques qui est chargée au démarrage d'APISIX. Il utilise le protocole xDS pour interagir avec Istio. Ensuite, il écrit la configuration obtenue dans le centre de configuration xDS d'APISIX, qui génère des règles de routage spécifiques et utilise finalement APISIX pour router les requêtes correspondantes.

Après la configuration de l'architecture ci-dessus, les résultats suivants peuvent être obtenus :

Amesh et APISIX maintiennent le même cycle de vie et peuvent être activés et désactivés ensemble.
Grâce au support natif d'APISIX pour xDS Discovery, les données sont converties entre elles via le protocole xDS, ce qui permet de contrôler le niveau de consommation des ressources.
CRD peut être utilisé pour étendre rapidement et facilement l'ensemble de la solution, en particulier pour les fonctionnalités non encore prises en charge par Istio. Par exemple, la configuration de plugin la plus riche d'APISIX est configurée par CRD ; en utilisant le contrôleur avec Istio, l'extensibilité de la solution de Service Mesh Istio et APISIX est maximisée.

Performances spécifiques de la solution

Amélioration significative des performances

Les données sont toujours le moyen le plus intuitif et le plus efficace de présenter un produit technologique. Nous utilisons APISIX et Envoy comme plan de données dans la solution de Service Mesh, utilisons un volume allant jusqu'à 5 000 routes pour effectuer des tests de stress dans divers scénarios, et présentons finalement les données comparatives suivantes.

Le scénario de test est "Correspondance de la 3000ème route sur 5000 routes". En raison du grand nombre de scénarios de test, seules les routes correspondant à la partie médiane sont décrites ci-dessous, et il y a également des scénarios correspondant aux routes de tête et de queue. (Il y a trop de données à montrer, donc les données suivantes sont le résultat du test avec un volume de 3000 routes).

Comme vous pouvez le voir à partir des données ci-dessus, APISIX montre une amélioration de performance de 5x au niveau du QPS pour la même pression et la même configuration de machine. De plus, au niveau de la latence des requêtes, APISIX est inférieur à Envoy d'un ordre de grandeur, avec une latence d'APISIX en microsecondes et celle d'Envoy en millisecondes. Bien sûr, vous pouvez également voir que dans cette mesure, la consommation CPU d'APISIX n'est que de 50% lorsque celle d'Envoy est déjà à pleine capacité.

Réduction de l'utilisation des ressources

Lors de l'injection du Sidecar dans la solution de Service Mesh, des ressources supplémentaires sont généralement consommées. La solution basée sur API peut réduire la consommation de ressources de 60%. Pourquoi est-ce possible ?

Tout d'abord, la configuration est distribuée à la demande. Istio dispose de certaines politiques à la demande pour la gestion des ressources du Sidecar, comme la séparation par espace de noms, mais ce processus impose des charges mentales supplémentaires et des difficultés de gestion aux opérations des utilisateurs.

Deuxièmement, la configuration est-elle facile à comprendre ? Lorsque vous configurez une route dans Envoy, les informations de routage vérifiées via Dump montrent qu'il y en a déjà des milliers dans Envoy alors qu'il n'y en a pas autant en réalité, ce qui a de nombreuses implications, comme affecter la vitesse de démarrage et rendre certaines configurations volumineuses, augmentant ainsi l'utilisation des ressources.

Avec APISIX, vous pouvez éviter tous ces problèmes. La configuration d'APISIX est simple et claire, réduisant les données stockées en mémoire et, combinée à ses hautes performances, réduisant la consommation des ressources CPU. La consommation de ressources de l'ensemble de la solution est réduite d'environ 60%.

Faible coût d'apprentissage et grande capacité de personnalisation

Tout d'abord, en tant que projet open source actif de la Fondation Apache Software, APISIX fournit une documentation riche et des ressources d'apprentissage dans la communauté, ce qui réduit le coût d'apprentissage pour ceux qui souhaitent démarrer avec APISIX.

Deuxièmement, le code source d'APISIX est basé sur l'implémentation Lua, qui est relativement facile à lire et à comprendre, car il s'agit d'un langage de script léger, donc il est plus clair de consulter le code source d'APISIX.

Enfin, le développement secondaire basé sur APISIX est très facile. Lorsque vous souhaitez personnaliser des plugins pour votre activité, non seulement le langage Lua natif est pris en charge, mais vous pouvez également utiliser le Plugin Runner d'APISIX pour implémenter un développement secondaire dans des langages plus familiers comme Python, Java, Go, et même Wasm.

La puissance de l'écosystème d'APISIX est également due à la forte extensibilité du produit.

APISIX lui-même offre une large gamme de plugins pour la sécurité, la journalisation, l'observabilité, et plus encore. Ces plugins peuvent être utilisés au maximum lorsque APISIX est utilisé comme composant de passerelle traditionnelle. Cependant, lorsque APISIX est utilisé en conjonction avec Istio sur le plan de contrôle pour créer un service mesh, de nombreuses ressources ne sont pas définies sur le plan de contrôle d'Istio. Alors, que peut-on faire dans ce cas ?

C'est là qu'interviennent les CRD personnalisés. Par exemple, si nous voulons créer un plugin d'injection de faute, ce plugin est déjà disponible dans APISIX, donc nous n'avons besoin de configurer que quelques paramètres supplémentaires ici. Bien sûr, ce n'est qu'un exemple du plugin d'injection de faute. Il existe également des plugins d'authentification sécurisée, de limitation de débit, et d'autres plugins courants dans APISIX qui peuvent être accessibles de cette manière pour un contrôle fin.

L'avantage immédiat de l'utilisation des CRD de cette manière est qu'elle rend l'extension plus native, en utilisant une configuration déclarative pour la rendre plus facilement acceptée par les utilisateurs tout en ne perturbant pas la configuration originale d'Istio pour une compatibilité parfaite. Un autre avantage est que les coûts de migration sont plus faibles pour les utilisateurs qui utilisent déjà des solutions Istio.

En résumé, la solution de Service Mesh basée sur APISIX est plus facile à utiliser et extensible pour les développeurs ou les utilisateurs, et offre d'excellentes performances et un riche support écosystémique. Grâce aux capacités du produit APISIX, elle dispose également d'un bon support au niveau des plugins et des multi-protocoles. Nous prévoyons de vous apporter la prochaine version du Service Mesh basé sur APISIX à la fin de l'année. Restez à l'écoute !

Perspectives futures pour la solution de Service Mesh basée sur APISIX

En rétrospective, la solution de Service Mesh basée sur APISIX travaille déjà vers les points de douleur mentionnés dans l'article précédent, et s'oriente vers la solution de Service Mesh idéale.

Avec la solution de Service Mesh basée sur APISIX, vous pouvez voir que le trafic entre de l'extérieur via APISIX Ingress et est traité par APISIX au milieu. Dans ce processus, APISIX Ingress gère le trafic nord-sud, et Amesh + Istio gère le trafic est-ouest.

Une architecture de déploiement comme celle-ci peut apporter une certaine valeur au niveau métier, comme des économies de coûts et une pile technologique unifiée, où vous pouvez rapidement répliquer les capacités communes utilisées dans les passerelles traditionnelles dans le Service Mesh. Cela permet une gestion unifiée au niveau métier, contrôlant ainsi les coûts et réutilisant fortement l'expérience dans la passerelle, Ingress et Service Mesh.

Dans les itérations suivantes, la solution de Service Mesh basée sur APISIX continuera à être approfondie, accomplissant des directions planifiées telles que :

Construire des implémentations de capacités xRPC en conjonction avec les fonctionnalités d'APISIX.
Effectuer un support natif de multi-protocoles hétérogènes.
Couvrir tous les types de scénarios et configurations, y compris Istio, pour réduire considérablement les coûts de migration des utilisateurs.

En conclusion, parmi les tendances technologiques actuelles, le Service Mesh est voué à être une tendance populaire à l'avenir. Bien que diverses solutions ne soient pas encore parfaites, la situation globale est en spirale ascendante. Bien sûr, le Service Mesh basé sur APISIX se dirige également vers la solution de Service Mesh idéale que tout le monde a en tête.