Comment APISIX facilite le déploiement localisé de Beeto au Moyen-Orient

Aperçu

Défis

• L'architecture de service monolithique entraîne des coûts élevés en maintenance et exploitation
• Déploiement d'architecture complexe et appels de services, ainsi que plusieurs piles technologiques

Résultats

• Unification du trafic nord-sud et est-ouest, économisant des ressources et des coûts de main-d'œuvre, et permettant une gestion dynamique et unifiée
• Simplification de l'architecture de déploiement, réduisant ainsi l'interaction entre la passerelle et les utilisateurs
• Les multiples plugins d'extension d'APISIX ont aidé Beeto à gérer efficacement la vérification des permissions, la distribution des routes et les fonctions de vérification de santé des services
• APISIX permet à Beeto de lancer et migrer dynamiquement des services, ce qui est convivial pour les développeurs

Introduction à Beeto

Pour le marché du Moyen-Orient, Beeto est une plateforme de médias sociaux en arabe, avec une conception de produit et une architecture technique localisées. Elle a été classée 4e sur la liste des meilleures applications de l'App Store iOS en Arabie Saoudite, dépassant le géant des plateformes sociales Facebook.

Le développement d'Internet au Moyen-Orient est mature, avec une très forte pénétration d'utilisateurs actifs sur les réseaux sociaux. En particulier en Arabie Saoudite, où 90 % des personnes utilisaient Internet en 2019. Le taux de pénétration des utilisateurs actifs en Arabie Saoudite était classé 9e en 2020.

La maturité du marché internet a entraîné la popularité de logiciels sociaux internationaux comme WhatsApp, YouTube et Instagram. Néanmoins, il n'existe pas de logiciel social localisé similaire à Twitter. Par conséquent, visant le "marché internet mature mais peu localisé" du Moyen-Orient, Beeto a lancé un développement de produit localisé là-bas.

La localisation est importante pour Beeto

Comparé à des applications de flux comme Twitter et Facebook, Beeto a planifié un cadre relativement complet pour déployer son architecture commerciale au Moyen-Orient. Par exemple, il s'est engagé à satisfaire l'interaction relationnelle des attributs sociaux, la consommation de contenu (texte, diffusion en direct vidéo, publicité locale, etc.), ainsi que diverses activités telles que les récompenses, les retraits, les votes et les tirages au sort des catégories financières et de services, et même les exigences de supervision de la plateforme et de révision de la sécurité du contenu.

Comme indiqué précédemment, la maturité d'Internet sur le marché du Moyen-Orient exige inévitablement des produits de haute qualité. Par conséquent, la première version de l'architecture commerciale de Beeto était un produit complet intégrant toutes les fonctionnalités que les logiciels sociaux grand public devraient avoir. Par ailleurs, l'objectif de Beeto est de devenir la plus grande plateforme sociale en arabe et la meilleure communauté arabe au Moyen-Orient avec des "fonctionnalités de localisation". Pour réaliser cet objectif, Beeto a analysé les exigences de localisation comme suit.

Points douloureux dans la conception de l'architecture de Beeto

La localisation inclut les besoins sociaux locaux existants au niveau commercial, et les opérations de localisation au niveau technique, comme le déploiement des services et le stockage des données. Ceux qui connaissent Weibo ou Twitter savent qu'il faut des dizaines ou des centaines de systèmes architecturaux pour collaborer derrière un tel produit de flux d'informations. Les points douloureux dans l'architecture de Beeto sont les suivants.

L'architecture de service monolithique entraîne des coûts élevés

Les services de Beeto peuvent être divisés en huit parties, comme ci-dessous.

La mise en œuvre de ces activités nécessite un déploiement localisé au Moyen-Orient. Chaque service est une architecture monolithique séparée si chaque activité est divisée par service.

Le diagramme d'architecture monolithique ci-dessus montre une architecture de déploiement commune. Prenons l'exemple du service de flux de Beeto. Si nous voulons répondre à la demande de l'utilisateur pour parcourir le flux, nous devons supporter l'accès au réseau public, c'est-à-dire l'accès au trafic nord-sud ; en même temps, le service de flux fournit également des appels internes sous forme d'activité thématique, à savoir des appels de trafic est-ouest.

Par conséquent, le service global supporte les modes d'appel externes et internes. Après l'équilibrage de charge de la couche 7, le trafic utilisateur est distribué à différents serveurs, puis différentes ressources de stockage sont appelées. Le trafic est-ouest est également similaire. Le cluster de la couche 7 gère le trafic nord-sud et est-ouest, l'équilibrage de charge, l'authentification, et la surveillance des nœuds.

Lorsque les services de plusieurs activités sont combinés, l'architecture globale peut être :

Comme vous pouvez le voir, les services existent dans les couches d'adaptation, d'activité et de service de base. L'architecture de déploiement pour chacun de ces services a les détails architecturaux monolithiques mentionnés ci-dessus, donc il y a plusieurs clusters de couche 7 entre eux, ce qui est une architecture système très large et complexe.

Cependant, puisque le produit Beeto est en phase de démarrage et que le produit est lancé au Moyen-Orient, mais que son équipe de R&D est en Chine, des coûts de serveur et de maintenance importants sont nécessaires. De plus, à mesure que l'activité augmente, le nombre de services monolithiques augmentera inévitablement, rendant plus difficile le contrôle des coûts et des opérations de maintenance.

Difficulté à lancer plusieurs services

En plus de la complexité du déploiement de l'architecture, les appels entre les services au sein du cluster sont également très complexes.

Le trafic nord-sud est distribué à divers pools de services, et le trafic est-ouest est également entrelacé entre divers services, avec les relations d'appel entre ces services enchevêtrées.

De plus, ces relations d'appel doivent être maintenues par les services, ce qui entraîne une traçabilité des appels peu claire et une mauvaise gestion.

En plus des relations d'appel complexes, il y a aussi des différences dans les piles technologiques entre chaque service. Par exemple, sur le protocole d'appel, certains services fournissent HTTP, tandis que d'autres fournissent RPC ; En termes de développement de langages de programmation, il y a un mélange de Java, Go, et d'autres langages de programmation.

Un tel système d'architecture multi-services exposera évidemment le problème de coûts de déploiement et de maintenance élevés lorsqu'il est mis en œuvre localement. De plus, Beeto doit investir dans les coûts de serveur sur chaque ensemble de services de couche 7, tandis que la différence de trafic de chaque service entraîne un déséquilibre de trafic, résultant en un faible taux d'utilisation des ressources telles que les serveurs et un gaspillage de ressources.

Puisque Beeto se concentre davantage sur les mises à niveau et les itérations de l'activité, l'architecture est conçue pour faciliter la maintenance et la gestion unifiée, alors comment atteindre cet objectif ?

La passerelle APISIX alimente l'architecture de Beeto

Pour résoudre les problèmes de gestion de service peu pratique et de coûts élevés et pour bénéficier des performances dynamiques d'APISIX avec etcd, qui correspond davantage aux exigences du produit Beeto, APISIX a été introduit comme passerelle API dans le déploiement de l'architecture, et un cluster de passerelle a été construit, comme le montre la figure ci-dessous.

Le cluster de passerelle APISIX fournit des outils d'extension tels qu'un centre de registre, un contrôle de service, une surveillance de service, un transfert de protocole et des plugins pour tous les services. Les clusters de services peuvent tous être enregistrés auprès de la passerelle, et de nouveaux services peuvent être ajoutés et supprimés directement via la passerelle.

Après l'introduction de la passerelle, la traçabilité des appels de l'ensemble du cluster est devenue plus claire. Le trafic nord-sud est acheminé et transféré par la passerelle, et le trafic est-ouest est géré par la passerelle pour les services sur l'intranet. Au niveau fonctionnel, APISIX est responsable de la maintenance de l'authentification appelée par ce trafic afin que la couche de passerelle puisse comprendre clairement les différences de performance et de trafic entre les services.

Bien sûr, puisque la passerelle supporte tout le trafic dans cette architecture, le nombre de services augmentera plus tard à mesure que le service s'étend, le coût de maintenance de la passerelle augmentera, et de nouvelles solutions devront être envisagées. Cependant, dans le contexte actuel, la solution reste le meilleur choix.

Pratiques après l'application d'APISIX

Apache APISIX, en tant que passerelle API, peut gérer une variété de politiques au niveau de la passerelle, telles que l'authentification, le transfert de service et les vérifications de santé. Par conséquent, Beeto a fait de nombreuses tentatives au niveau de la pratique commerciale après l'introduction d'APISIX.

Sécurité : Plugin d'authentification

Trafic Nord-Sud : Cookie

Comme mentionné précédemment, le trafic d'accès des utilisateurs du réseau public passe par la passerelle. L'authentification des utilisateurs du réseau public est une demande d'utilisateur basée sur l'authentification par cookie. Lorsqu'un utilisateur demande à apporter un cookie à la passerelle, il est vérifié par le plugin d'authentification.

Comme le montre le diagramme de flux ci-dessus, le plugin effectuera d'abord une validation de localisation, puis une vérification d'authentification du service distant selon la politique. Une fois la demande vérifiée par cookie, elle sera transférée au service spécifié.

Les avantages de cette approche sont doubles :

1. La sécurité des cookies des utilisateurs est assurée. Seule la couche de passerelle peut recevoir et traiter les cookies pendant l'exécution, car les cookies sont des données sensibles. Cela empêche les problèmes de sécurité causés par des règles de traitement commercial incohérentes et évite efficacement les fuites de cookies causées par des facteurs humains et des irrégularités.

2. Réduction de la complexité de l'authentification par cookie pour les services. Les cookies doivent être vérifiés localement ou à distance et nécessitent une mise à niveau simultanée des services lorsque les cookies sont mis à niveau. APISIX gère et vérifie de manière unifiée, économisant le coût de vérification des services commerciaux et indiquant les résultats, qui peuvent être utilisés pour le traitement des règles commerciales, assurant ainsi que chaque traitement commercial se concentre davantage sur l'activité elle-même.

Trafic Est-Ouest : Token

Dans le diagramme ci-dessous, le Service A appelle le Service B. Généralement, une API suffit pour s'appeler mutuellement. Cependant, dans le processus interne, il est nécessaire de comprendre "qui a appelé l'API, comment elle a été appelée, s'il est nécessaire de vérifier l'autorisation, et s'il est nécessaire de contrôler le chercheur", et ainsi de suite, qui doivent être gérés en interne.

Avec la passerelle APISIX, le processus devient beaucoup plus simple. L'appel mutuel de tous les services internes doit simplement être enregistré sur le service d'authentification Auth, et une clé d'application est émise pour chaque service pour indiquer l'ID d'identité du service. En même temps, l'appel mutuel des services internes passera également par la passerelle. Après avoir transporté le token via la passerelle, la passerelle authentifiera le token via les plugins de token. Une fois l'authentification passée, l'identifiant d'authentification sera transmis au service appelé. Pendant tout le processus, le système de service effectuera l'enregistrement d'authentification et complétera un appel mutuel.

Grâce à la règle de token de la clé d'application, l'opération ci-dessus peut être facilement retracée à la source de l'appel, ce qui peut être utilisé pour le dépannage et le contrôle des permissions, et fournir également un contrôle efficace sur les appels illégaux. Par conséquent, l'avantage de l'authentification unifiée est que, que ce soit pour le trafic nord-sud ou est-ouest, elle assure la sécurité et l'uniformité du cluster, ce qui aide grandement dans le traçage des problèmes et le contrôle des appels.

Évolutivité : Expansion et migration de services sans état

L'architecture de déploiement globale du cluster de Beeto de haut en bas est composée de : clusters de passerelle APISIX - clusters de services commerciaux de services sans état - clusters de centre de données de services avec état. Lorsqu'ils sont déployés localement au Moyen-Orient, ils sont tous déployés sur les principaux clusters cloud. Selon l'échelle de couverture cloud au Moyen-Orient et les fabricants de cloud dans différentes régions, il est nécessaire de considérer l'expansion et la migration des services cloud lors du déploiement des services.

Dans le processus de migration, Beeto s'est concentré sur la migration des services sans état. Il est inapproprié pour un ajustement dynamique en raison du coût limité de migration du centre de données ; la plupart des demandes sont supportées par le service sans état, il est donc très important de s'assurer que le service sans état a une bonne évolutivité.

Dans l'architecture de Beeto, l'évolutivité des services se reflète principalement dans deux aspects : l'évolutivité des services monolithiques et l'évolutivité globale du cluster. Par exemple, si un service monolithique manque de ressources et doit être étendu, les passerelles APISIX peuvent ajouter dynamiquement des nœuds pour l'extension. De même, dans des situations de clusters ou de clouds croisés, l'évolutivité du cluster peut être réalisée en déployant plusieurs passerelles APISIX et en migrant différents services vers différents nœuds de passerelle.

Pour les services commerciaux, l'architecture globale reste inchangée afin que l'expansion et la contraction dynamiques de divers services et la migration des services puissent être réalisées au niveau de la passerelle. Le processus entier a un plan et un objectif clairs, et une fois que des changements sont impliqués, l'architecture globale ne sera pas instable.

Extensibilité fonctionnelle : Transfert dynamique des services

En plus de ces scénarios généraux familiers de passerelle mentionnés ci-dessus, Apache APISIX fournit également une assistance significative à Beeto en termes de transfert dynamique de services.

Ceux qui connaissent l'interface utilisateur et le backend des applications savent que différentes pages de produits sont fournies par différents services. Une page est composée de différents modules, dont le contenu est entièrement envoyé par l'API. Quelles que soient les données que l'API envoie au module, elles sont rendues sur les terminaux. Il s'agit d'une spécification de rendu côté client commune pour rendre le processus de rendu côté client plus générique et le traitement commercial plus flexible.

Dans la mise en œuvre de la PageA dans la figure ci-dessus, par exemple, le client appelle l'API du Service A, envoie les données du module correspondant et complète le rendu de la PageA. Cette opération entraînera des problèmes que le client doit maintenir chaque page et API pour chaque service. Si le contenu change, il est nécessaire de le résoudre par publication, ce qui est très peu convivial en termes d'opérabilité et d'efficacité.

La solution au problème ci-dessus est de mettre en œuvre une distribution unifiée des services dans l'architecture globale. Le client demande d'abord l'adresse API, transfère toutes les demandes de ce type à une API, traite les paramètres de demande et les règles d'URL pour l'adresse URL au niveau de la passerelle, puis introduit le plugin de distribution. Enfin, les demandes analysées sont transférées directement au service spécifié au niveau de la passerelle selon les règles de configuration.

Le client n'a besoin de déterminer que la spécification de rendu tout au long du processus, pas la source des données. La couche de passerelle assume la responsabilité de la distribution des services et transfère directement le trafic. Le fichier de configuration du plugin dans APISIX peut être mis à jour dynamiquement en temps réel, et les règles de transfert peuvent être ajustées dynamiquement, ce qui est très flexible. En fait, pour des applications comme l'architecture BFF (Backend for Frontend), de telles exigences peuvent être résolues au niveau de la passerelle.

Conclusion

Cet article présente les pratiques d'application de l'introduction de Apache APISIX par Beeto du point de vue de la conception et des activités.

APISIX a soutenu Beeto dans le contrôle des coûts de ressources et des multiples lignes de produits commerciaux, et a aidé Beeto à réaliser un déploiement localisé, une gestion unifiée et des scénarios conviviaux pour la maintenance au Moyen-Orient.