L'architecture Microservices - Introduction générale PDF

L’architecture Microservices Introduction générale  Architecture Monolithique vs. Microservice @[email protected] (Youssef SAADI) 2  Microservices? + Style d’architecture...

L’architecture Microservices Introduction générale  Architecture Monolithique vs. Microservice @[email protected] (Youssef SAADI) 2  Microservices? + Style d’architecture Décomposition d’un système en un ensemble de petits services, chacun s’exécutant comme processus indépendant. Ces services interagissent via des protocoles ouverts comme HTTP. Ils peuvent être écrits dans différents langages, maintenus, déployés, et mis en échelle séparément. + Exemple d’usage : Twitter : Ruby/Rails monolith Facebook: PHP monolith Microservices Netflix : Java monolith @[email protected] (Youssef SAADI) 3  Des unités fonctionnelles + Chaque microservice est conçu selon une fonction métier exclusive et pouvant interagir avec d’autres fonctions. Microservice @[email protected] (Youssef SAADI) 4  Exemple de Microservices? + Application d’achat en ligne : Fonctions : + Recherche de produits Approche monolithique + Catalogue de produits + Gestion d’inventaire + Panier d’achat + Gestion des commandes … @[email protected] (Youssef SAADI) 5  Application monolithique? + Application exécutable et écrite dans un seul langage Controller Services DAO + Application large : difficile à faire évoluer; mettre à jour & maintenir. @[email protected] (Youssef SAADI) 6  Les défis des applications monolithiques? + Nouveaux types de clients qui émergent + Différents types de moyens de stockage qui sont plus spécifiques. Elastic Search @[email protected] (Youssef SAADI) 7  Avantages & Inconvénients des applications monolithiques? + Avantages : Facile à comprendre, à déployer et à tester comme une simple unité. Facile à gérer si la taille le permet. + Inconvénients : Toute l’application est écrite dans un seul langage Une application avec un large code est difficile à comprendre par un seul développeur. Une seule équipe ne peut pas gérer une application large. On ne peut pas déployer le changement d’un seul composant de façon séparée de l’application en entier. @[email protected] (Youssef SAADI) 8  L’architecture Microservices @[email protected] (Youssef SAADI) 9  Avantages des Microservices On ne dépend pas d’un seul langage On utilise des protocoles légers et ouverts pour l’interaction Faciles à comprendre, gérer, tester, déployer, et à mettre en échelle. Les changement sont découplés On n’expose aux clients seulement ce qui est nécessaire. @[email protected] (Youssef SAADI) 10  Défis des Microservices + Défis du calcul (systèmes) distribué(s) Erreurs de non considération dont il faut se méfier: Le réseau est efficace La latence est zéro La bande passante est infinie Le réseau est sécurisé La topologie ne change pas Il y a un seul administrateur Le coût du transport est zéro Le réseau est homogènes + Services peuvent être indisponibles + Les appels distants sont plus chers que les appels en interne. + Problèmes de cohérence des données. @[email protected] (Youssef SAADI) 11  Conception des Microservices @[email protected] (Youssef SAADI) 12  Conception des microservices ? + La considération primordiale est de se baser sur la logique métier. Single Responsibility Principle: chaque microservice doit avoir une responsabilité unique: Couplage faible : chaque microservice s’approprie ses propres données et communique avec les autres avec une API bien définie (pas de dépendances directe). Une mise à jour dans un service n’influence pas le système en entier. Autonomie : chaque microservice a un contrôle total sur ses données et se déploie de façon isolée des autres. + Éviter d’avoir un niveau de granularité très fin pour les services  augmenter la complexité @[email protected] (Youssef SAADI) 13  Meilleures pratiques + Opter pour « Domain Driven Design » pour identifier « Bounded Context » + Assurer la cohérence des données à travers la Cohérence Eventuelle et les architectures basés sur les événements. + Conception avec prévision des pannes + Utilisation des passerelles API. + Versioning des API @[email protected] (Youssef SAADI) 14  Conception d’API pour les Microservices? + Définir et documenter les APIs avant de les coder La conception des APIs est un processus itératif + Conception basé sur le domaine pour identifier les contexte délimités. Permet de définir une responsabilité claire pour chaque microservice et aussi éviter le couplage inutile. @[email protected] (Youssef SAADI) 15  Préoccupations transversales + Au lieu d’implémenter la sécurité d’authentification par exemple au niveau de chaque microservice, on pourra centraliser ceci au niveau de la passerelle et découpler les services de cette préoccupation. @[email protected] (Youssef SAADI) 16  Cohérence des données + Quand un serveur met à jour ses données il pourra publier un évènement que les autres services pourront écouter et y réagir. @[email protected] (Youssef SAADI) 17  Conception avec prévision des pannes? + Les pannes sont inévitables + Mécanismes de réessaie Plusieurs réessaies + Stratégie de Fallback: Permet à votre service d’être plus résilient et gérer les situations imprévisible de façon fiable @[email protected] (Youssef SAADI) 18  Versioning des APIs @[email protected] (Youssef SAADI) 19  Granularité + Fine-grained APIs: Avantages : Réaliser des opérations spécifiques  on dispose d’un contrôle élevé. Inconvénients : Des appels réseau de plus; transfert de données élevé; complexité dans la gestion des interactions. + Coarse-grained APIs: Avantages : Réduit la surcharge réseau; simplifie l’interaction entre services. Inconvénients : Peut mener à un couplage étroit entre les services; une flexibilité réduite de comment les clients peuvent interagir. + Faut chercher le bon équilibre  concept de « Bounded Context » @[email protected] (Youssef SAADI) 20  Bounded Context + Définit les limites d’un domaine spécifique + Un Bounded Context peut consister en un seul ou plusieurs microservices. + Chaque Bounded Context dispose de sa propre API. + Fine grained vs. Coarse grained API @[email protected] (Youssef SAADI) 21  Communication synchrone vs. asynchrone + Communication synchrone : feedback immédiat Inconvénients: bloquante; couplage étroit entre services + Communication asynchrone : couplage faible; service plus résilient. Inconvénient : Suivi de la totalité du flux des messages et la gestion des échecs peuvent être complexes et difficiles. Pas de feedback immédiat si quelques choses ne va pas. @[email protected] (Youssef SAADI) 22  Modèles de communication + Requête / Réponse + Publication/abonnement (publish/subscribe) + Event sourcing + Command Query Responsibility Segregation (CQRS) @[email protected] (Youssef SAADI) 23  Exemple : + Dans une application de gestion des activité de gym (fitness) + Un client peut envoyer une commande de complétion de son activité (workout) selon les modèles de communication citées précédemment. + La commande sera envoyée au service de gestion du progrès de l’utilisateur qui enregistre ce statut au niveau de la BD. @[email protected] (Youssef SAADI) 24  Exemple : @[email protected] (Youssef SAADI) 25  Protocoles typiques + HTTP/HTTPS + WebSocket + Advanced Message Queuing Protocol (AMQP) + gRPC @[email protected] (Youssef SAADI) 26  API gateway + Point d’entrée unique pour les clients + Améliore l’efficacité réseau : Load Balancing + Fournit une sécurité amélioré : centralisée Peut être sujet d’un goulot d’étranglement qu’on peut remédier par une conception en prévision des pannes et pour une disponibilité élevée: des instances multiples; surveillance. @[email protected] (Youssef SAADI) 27  Caractéristiques d’une API Gateway + Translation de protocole + Composition d’API + Gestion du trafic + Mise en cache + Découverte des services @[email protected] (Youssef SAADI) 28  Les modèles (Patterns) API Gateway? + Le modèle BFF: Backend for Frontend Pattern @[email protected] (Youssef SAADI) 29  Les modèles (Patterns) API Gateway? + API Versioning @[email protected] (Youssef SAADI) 30  Les modèles (Patterns) API Gateway? + Circuit Breaker Pattern @[email protected] (Youssef SAADI) 31  Exemple : Fitness App @[email protected] (Youssef SAADI) 32  Service Discovery @[email protected] (Youssef SAADI) 33  Le modèle Service Discovery + Ce pattern peut être divisé en deux catégories principales: + Découverte coté client Le client sollicite le registre du service Une fois il obtient la localisation du service demandé; il lui envoie ses requêtes. Pas d’intermédiaire (latence réduite) Augmentation de la complexité du code client: + Découverte coté serveur: Le client envoie les requêtes vers un load balancer ou une API Gateway qui se charge de trouver la localisation du service demandé et lui redirigé les requêtes du client. Simplifie le code client mais augmente la latence @[email protected] (Youssef SAADI) 34  Gestion des données @[email protected] (Youssef SAADI) 35  Gestion des données décentralisée + Bénéfices : Couplage faible entre les microservices Chaque équipe de développement d’un microservice à l’autonomie de choisir le type de support persistance adéquat. Améliore la scalabilité et la performance + Défis : Duplication des données Synchronisation et intégrité (cohérence) des données single source of truth @[email protected] (Youssef SAADI) 36  Data Consistency + S’assurer que les données sont actualisées au niveau de tous les microservices. Concept de « Eventual Consistency »: on accepte qu’il y a une incohérence (data inconsistency) temporaire des données entre les microservices, cependant on assume qu’après une tranche de temps (offtime) les services vont converger vers un même état de cohérence. @[email protected] (Youssef SAADI) 37  Data Consistency : Exemple + Une approche : Event Driven Architecture Même s’il y a un délai, les microservices vont éventuellement converger vers un état de cohérence. Supposant une mise à jour du profil implique une série d’étapes dans d’autres services tels qu’une mise à jour d’un émail implique une mise à jour du username coté Leaderboard et une mise à jour du statut coté Social; ceci devient un défis si un des service échoue  données incohérentes @[email protected] (Youssef SAADI) 38  Assurer la cohérence : Modèles & stratégies + Modèle Saga: Gère les transactions multiservices de longue durée Décompose les transactions complexes en transactions locales. Services effectuent des transactions et publient des événements Les événements déclenchent le prochain service de la séquence Ça continue jusqu'à ce que toutes les transactions soient terminées Compensation des transactions annule les étapes en cas d'échec. @[email protected] (Youssef SAADI) 39  Exemple : Saga @[email protected] (Youssef SAADI) 40  Exemple : Saga @[email protected] (Youssef SAADI) 41  Exemple : Saga + Si Goals échoue: Saga va devoir compenser les transactions en publiant un évènement : workoutRemoved pour annuler les transactions effectuées au niveau de chaque microservice. @[email protected] (Youssef SAADI) 42  Assurer la cohérence : Modèles & stratégies + Modèle Event Sourcing: Stocke une séquence d'événements de changement d'état L'état actuel est reconstruit en rejouant les événements Fournit une piste d'audit complète Permet des ajustements rétroactifs aux événements passés Permet de corriger l'état actuel Reconstruction @[email protected] (Youssef SAADI) 43  Assurer la cohérence : Modèles & stratégies + Modèle commit à deux phases (2PC): Coordonne les transactions distribuées entre les services Utilise un gestionnaire de transactions pour assurer l'atomicité Deux phases: - Préparer (tous peuvent-ils s'engager? (commit)) - Valider (commit) Si un participant ne peut pas valider, la transaction est annulée Fournit une forte cohérence mais peut avoir un impact sur la disponibilité @[email protected] (Youssef SAADI) 44  Assurer la cohérence : Modèles & stratégies + Modèle 2PC : Exemple @[email protected] (Youssef SAADI) 45  Assurer la cohérence : Modèles & stratégies + Modèle 2PC : Exemple @[email protected] (Youssef SAADI) 46  Assurer la cohérence : Choix du Modèle + Cela dépend des besoins spécifiques du système + Motif Saga: Bon pour les longs « business flux » Tolère certaines incohérences + Event Sourcing : Grande flexibilité et auditabilité Plus de complexité + Validation en deux phases (2PC): Fournit la consistance la plus forte Peut avoir un impact sur la disponibilité Il est moins adopté de nos jours @[email protected] (Youssef SAADI) 47  Conception des points de termination des APIs. @[email protected] (Youssef SAADI) 48  Principes de conception d’une API RESTful + Méthodes HTTP standards : GET/POST/DELETE/PUT + Conventions de nommage des endpoints + Codes d’état HTTP: 200/201… + Alternatives to REST GraphQL: qui est flexible et efficace pour les requêtes complexes. gRPC : idéale pour une performance élevée et une communication à basse latence. @[email protected] (Youssef SAADI) 49  Conception CRUD d’une API + Identifier les actions qui doivent être effectuées Création, lecture, mise à jour et suppression + Mappez les actions aux méthodes HTTP et définissez les chemins des points de terminaison (endpoints) POST /workouts GET /workouts/{id} PUT ou PATCH /workouts/{id} DELETE / workouts /{id} + Prendre en compte les charges utiles (payloads) de demande et de réponse Déterminer les données nécessaires Définir la structure du corps de la requête Utilisez des formats de données standard comme JSON @[email protected] (Youssef SAADI) 50  Conception CRUD d’une API + Implémentez la gestion des erreurs Réponses d'erreur claires et codes de statut Soyez cohérent + Documentez l'API Explications claires et concises sur l'objectif d'un point de terminaison Formats des requêtes/réponses Exigences ou contraintes spécifiques Une bonne documentation est essentielle pour l'adoption et la maintenabilité @[email protected] (Youssef SAADI) 51  Conception des endpoints pour une efficacité d’interrogation des données + Les données sont dispersée à travers plusieurs services : interrogation transversale délicate + Création d’endpoints spécifiques aux requêtes au besoin du client. Exemple, on veut afficher le profil utilisateur avec les statistiques de son d’entrainement. @[email protected] (Youssef SAADI) 52  Les paramètres de requêtes + Utiliser les paramètre de requête pour permettre au client de chercher seulement les données dont il a besoin. On veut afficher le classement d’un utilisateur avec ses statistiques d’entrainement en comparaison avec ses amis. Cela nécessite l’interaction entre trois microservice : friends; user et leaderboard. @[email protected] (Youssef SAADI) 53  Validation des données & vérification d’intégrité + Validation du type (integer, float) + Validation des contraintes et des intervalles (< > …) + Validation des format et des motifs des données. (exemple: émail) + Gestion des données invalides: Réponses claires et informatives aux erreurs Dites au client exactement ce qui n'a pas fonctionné Quel domaine avait le problème Quel était le problème N'exposez pas trop d'informations dans vos messages d'erreur Fournir suffisamment de détails pour comprendre et corriger le problème @[email protected] (Youssef SAADI) 54  Gestion des erreurs des bases de données + Si une erreur survient au niveau de la base de données: + Ne pas afficher le message d'erreur de la base de données au client À la place, utilisez des messages clairs et concis Incluez des codes d'erreur, des horodatages, et des étapes concrètes pour la résolution + Implémentez la gestion des exceptions dans votre code Attrapez les erreurs de manière élégante + Consignez et surveillez les erreurs de la base de données Cela vous mène à la cause racine du problème Détectez et résolvez les problèmes de manière proactive + Envisagez des techniques de journalisation asynchrones Pour éviter que la journalisation ne devienne un goulot d'étranglement + Implémentez un mécanisme de secours @[email protected] (Youssef SAADI) 55  Sécurité et optimization d’accès aux données @[email protected] (Youssef SAADI) 56  Sécurisation de l'accès aux de données via des APIs + Première mesure de sécurité : authentification et autorisation des clients qui accèdent à l’API + Protection des données en transit : @[email protected] (Youssef SAADI) 57  Sécurisation de l'accès aux de données via des APIs + Sécurisation des données au repos : cryptage et hachage des données sensibles + Cryptage : AES (Advanced Encryption Standard) : trois tailles de clés: 128; 192; 256 bits. @[email protected] (Youssef SAADI) 58  Meilleures pratiques de gestion des clés + Utilisez des clés de cryptage solides et protégez-les comme des mots de passe + Opter pour une rotation régulière des clés + Stockez les clés séparément des données cryptées + Utilisez un système de gestion des clés sécurisé (KMS) + Limiter l'accès aux clés @[email protected] (Youssef SAADI) 59  Hachage + Pour les données qui n'ont pas besoin d'être réversibles Comme les mots de passe Stockez le hachage et comparez-le + Les hackers peuvent utiliser des tables arc-en-ciel Un « salt » est une valeur aléatoire ajoutée au mot de passe avant le hachage Utilisez toujours un hachage avec salt avec une fonction de hachage lente comme : bcrypt, PBKDF2, ou scrypt @[email protected] (Youssef SAADI) 60  Optimisation de l’accès aux bases de données + Indexing @[email protected] (Youssef SAADI) 61  Optimisation de l’accès aux bases de données + Caching @[email protected] (Youssef SAADI) 62  Optimisation de l’accès aux bases de données + Load Balancing @[email protected] (Youssef SAADI) 63  Optimisation de l’accès aux bases de données + Replica Sets @[email protected] (Youssef SAADI) 64  Optimisation de l’accès aux bases de données + Sharding @[email protected] (Youssef SAADI) 65  Optimisation de l’accès aux bases de données + Pool de connexions @[email protected] (Youssef SAADI) 66  Optimisation de l’accès aux bases de données + Surveillance et profilage en continue @[email protected] (Youssef SAADI) 67  Questions ?? + Références : Esteban Herrera; Designing APIs for Microservices [Online course] @[email protected] (Youssef SAADI) 68