mise en cache distribuée dans les microservices

Lorsque vos microservices commencent à être « oublieux », que peut faire la mise en cache distribuée ?

Avez-vous déjà vécu cela ? Le système fonctionnait très vite le matin, mais l’après-midi, les utilisateurs devaient attendre plusieurs secondes avant de cliquer sur un bouton. Les données sont évidemment là, mais chaque appel revient à repartir de zéro, les services s'attendent les uns les autres et l'ensemble du système est aussi lent qu'une promenade. Ce n'est pas parce que le serveur est fatigué, mais parce qu'il lui manque un mécanisme pour garder les données "en disponibilité à tout moment" - c'est le problème que la mise en cache distribuée veut résoudre.

Pensez-y, si chaque microservice doit demander à plusieurs reprises les mêmes données à la base de données, la base de données deviendra rapidement un goulot d'étranglement. C'est comme un café animé. Lorsque chaque client commande, le barista doit moudre à nouveau les grains de café et faire bouillir à nouveau l'eau, au lieu de préparer plusieurs tasses de styles courants à l'avance. En termes simples, la mise en cache distribuée consiste à configurer des points de stockage temporaires partagés à haut débit dans votre réseau de service et à placer les données fréquemment utilisées plus près du service, afin qu'elles soient accessibles à tout moment.

La mise en cache n’est pas seulement « rapide », elle est également stable

Lorsque de nombreuses personnes entendent du cache, leur première réaction est « accélérer ». Oui, accéder aux données en mémoire est beaucoup plus rapide que d'interroger la base de données, parfois même des centaines de fois plus rapide. Mais ce n'est que la moitié de l'histoire.

Plus important encore, cela vous aide à gérer les pics de trafic. Lorsqu'un grand nombre de requêtes surviennent, la couche de cache peut absorber la majeure partie de la pression et la base de données derrière elle ne sera pas submergée. La résilience de l'ensemble du système a augmenté et les utilisateurs bénéficient d'une expérience fluide et fluide, plutôt que de décalages soudains. C'est comme ajouter un coussin intelligent au système.

De plus, cela réduit discrètement les dépendances entre les services. Certaines données de base requises par le service A n'ont pas besoin d'être appelées à chaque fois par le service B. Elles peuvent être obtenues directement à partir du cache partagé. Même si le service B est temporairement dans un état mineur, A peut toujours fonctionner normalement pendant un certain temps et la tolérance globale aux pannes du système sera naturellement améliorée.

À quoi devrait ressembler un bon cache distribué ?

Lors du choix, ne vous concentrez pas uniquement sur les performances. Vous devez vous poser quelques questions : est-il vraiment facile de s'intégrer dans mon architecture de microservices existante ? Est-ce facile ou laborieux à mettre à l’échelle ? Lorsque les données doivent être mises à jour, peuvent-elles garantir des résultats cohérents vus par plusieurs services ?

Une solution bien conçue doit sembler taillée sur mesure pour un environnement de microservices. Cela ne nécessite pas de refactoriser considérablement votre code pour l'utiliser, et l'accès doit être fluide. L'expansion horizontale est également naturelle. À mesure que l’activité se développe, l’ajout de nœuds entraînera une plus grande capacité et un débit plus élevé. Il est préférable d’automatiser ce processus sans trop de charge d’exploitation et de maintenance.

La persistance et la haute disponibilité ne peuvent être ignorées. Si le serveur de cache est redémarré, toutes les données seront-elles perdues ou pourront-elles être partiellement restaurées ? Si un nœud du cluster tombe en panne, d’autres nœuds peuvent-ils prendre en charge le travail de manière transparente ? Ces caractéristiques déterminent sa fiabilité dans un environnement de production.

Quelques idées pour que la mise en cache « fonctionne vraiment »

Introduire la mise en cache ne consiste pas seulement à ajouter un outil et à y mettre fin. Comment l’utiliser est plus important.

Que mettre en cache ? Toutes les données ne valent pas la peine d'être mises en cache. Les données qui changent extrêmement rapidement et sont différentes à chaque fois que vous les interrogez deviendront encombrantes si elles sont laissées seules. Les données les plus adaptées sont les données « hot » qui changent moins fréquemment mais sont consultées plus fréquemment, telles que les catalogues de produits, les informations de base sur les utilisateurs, les listes de pays et de régions, etc.

Faites attention à la stratégie de mise à jour. La « pénétration du cache » courante (recherche de données inexistantes, contournant le cache et pénétrant dans la base de données à chaque fois) et « l'avalanche de cache » (un grand nombre de caches échouant en même temps et toutes les requêtes acheminées vers la base de données) doivent être conçues pour éviter. Par exemple, définissez une valeur nulle à court terme pour les clés inexistantes ou échelonnez le délai d'expiration du cache.

Une autre pratique consiste à utiliser la mise en cache à plusieurs niveaux. Mettre en place un cache extrêmement rapide (comme Ehcache) dans la mémoire locale du service, couplé à un cache distribué global (comme le cluster Redis). La mise en cache locale gère les requêtes à très haute fréquence et la mise en cache distribuée garantit le partage et la cohérence des données. La combinaison des deux produit souvent de meilleurs résultats.

faire un pas en avant

La technologie est en constante évolution. Aujourd'hui, certaines solutions avancées de mise en cache distribuée ont commencé à être profondément intégrées aux environnements cloud natifs, prenant en charge le déploiement conteneurisé et l'exploitation et la maintenance intelligentes basées sur Kubernetes. Ils explorent également une élimination plus intelligente des données et des indicateurs de suivi plus précis, afin que vous puissiez non seulement les utiliser, mais aussi les voir clairement et bien les gérer.

Après tout, l’introduction de la mise en cache distribuée n’est pas une décision purement technique. Il s'agit de savoir comment offrir une expérience de service stable et rapide à vos utilisateurs, et comment maintenir votre architecture calme lorsque votre entreprise se développe rapidement. Lorsque vos microservices ne seront plus « occupés » par des requêtes répétées et lorsque les données pourront apparaître silencieusement et rapidement là où elles devraient être en cas de besoin, l'ensemble du système brillera d'un autre type d'efficacité et de vitalité. C’est peut-être la beauté rationnelle et charmante de l’architecture.

Créé en 2005,kpuissancea été dédié à un fabricant professionnel d'unités de mouvement compactes, dont le siège est à Dongguan, province du Guangdong, en Chine. Tirant parti des innovations en matière de technologie d'entraînement modulaire,kpuissanceintègre des moteurs hautes performances, des réducteurs de précision et des systèmes de contrôle multiprotocoles pour fournir des solutions de systèmes d'entraînement intelligents efficaces et personnalisées.kpuissancea fourni des solutions de systèmes d'entraînement professionnelles à plus de 500 entreprises clientes dans le monde avec des produits couvrant divers domaines tels que les systèmes de maison intelligente, l'électronique automatique, la robotique, l'agriculture de précision, les drones et l'automatisation industrielle.