Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Architecture de microservices pilotée par APIAPI-driven Microservice Architectu

Architecture de microservices pilotée par APIAPI-driven Microservice Architecture Une architecture de référence WSO2 Version Q1-2019 auteur  Dakshitha Ratnayake, Architecte d’entreprise - CTO Office dakshitha@wso2.com L’architecture de microservices (MSA) est une excellente approche de la création de systèmes décentralisés. Toutefois, les microservices sont trop granulaires lorsqu’il s’agit d’architecturer des systèmes et des projets plus importants dans les friches industrielles. La plupart des entreprises suivent une architecture en couches avec des principes d’architecture orientée services (SOA) et des concepts MSA en regroupant les services ou microservices en couches dans l’architecture d’entreprise globale. Cette approche fait de chaque couche d’architecture un ensemble logiquement centralisé de composants partagés. Ce document présentera les microservices et abordera principalement l’approche en couches pour un MSA piloté par API. Il introduira des moyens de passer progressivement d’une architecture monolithique à un MSA en couches via le modèle de passerelle API à l’aide de l’intergiciel WSO2 et des technologies recommandées. Cet article couvrira également brièvement d’autres architectures de référence telles que l’architecture segmentée, qui est un sous-modèle de l’architecture en couches, et l’architecture de référence alternative connue sous le nom d’architecture basée sur les cellules. Ce document couvrira uniquement le style de communication demande- réponse pour la communication client-microservice et un document distinct traitera du style de communication piloté par les événements. 1.0 Introduction À une époque où il est plus important que jamais d’offrir de superbes expériences numériques, le succès commercial réside dans l’offre de services numériques agiles avec une grande satisfaction de la clientèle. Il doit y avoir un alignement entre la stratégie globale de l’entreprise et les initiatives numériques poursuivies afin de transformer l’architecture opérationnelle de base en une architecture numérique. Une architecture numérique favorise l’intégration rapide des nouvelles technologies pour alimenter la transformation numérique. Pour élaborer, une architecture numérique est composée d’une pile de couches qui soutiennent la chaîne de valeur de l’entreprise. La couche technologique, qui englobe l’application, la gestion des API, la sécurité, l’analyse, l’intégration, les couches de services et de données et l’infrastructure de base, sous-tend tout cela. Figure 1 : architecture numérique typique Une architecture de microservices (MSA) est une méthode de développement d’applications logicielles en les créant sous forme de collections de services indépendants et modulaires. Les microservices peuvent être déployés pour créer une architecture numérique plus flexible. Les petites équipes peuvent travailler séparément sur ces microservices et les partager avec d’autres développeurs d’applications via des API pour les réutiliser. En fait, ces services individuels peuvent être publiés, mis à l’échelle et mis à jour sans impact sur le reste du système. Lorsqu’il est associé à un environnement conteneurisé, MSA est l’option idéale pour les entreprises qui doivent fournir et évoluer rapidement et permettre la prise en charge d’une gamme de plates-formes et d’appareils. Lors de l’adoption d’un MSA, ses microservices constitutifs peuvent être classés en plusieurs types et sous-types. Dans le même temps, la plupart des organisations ne sont pas tout à fait prêtes à adopter un MSA pur. Même si une approche MSA est suivie pour le développement plus récent, de nombreux systèmes conventionnels, tels que les systèmes SOA, Enterprise Service Bus (ESB), les applications PaaS/SaaS et tout autre déploiement vertical monolithique d’applications héritées, continueront de faire partie de la topologie globale d’une entreprise. Ces systèmes de friches industrielles ne peuvent pas être ignorés et devront être accessibles par les microservices (au moins pendant la période de transition). Ces systèmes et services devront être exposés via des API gérées pour un accès interne et externe transparent. En tenant compte des faits ci-dessus, la vue holistique d’une architecture numérique compatible MSA peut être divisée en trois zones comme indiqué ci-dessous :  Zone 1 : Architecture interne  Zone 2 : Architecture extérieure  Zone 3 : Architecture externe Architecture interne Microservices principaux : microservices qui contiennent uniquement des services de logique métier et de données. Architecture externe Microservices utilitaires : inclut les microservices d’intégration, les micro passerelles, les services d’émission de jeton de sécurité, les micro-courtiers ou tout autre micro-runtime. Architecture externe Applications des utilisateurs finaux, systèmes et données hérités, applications SaaS, systèmes partenaires, etc. Tableau 1 : zones d’architecture MSA Par conséquent, une architecture numérique compatible MSA ressemblera étroitement à l’architecture illustrée à la figure 2 ci- dessous. Figure 2 : architecture numérique compatible MSA À cette fin, ce document expliquera comment réaliser une architecture numérique compatible MSA. Il mettra également en évidence les meilleures pratiques d’adoption d’une architecture de microservices basée sur les API afin de créer une architecture numérique de manière itérative, qu’il s’agisse d’une nouvelle architecture ou d’une friches industrielles, et comment la pile de produits WSO2 et ses dérivés peuvent aider à atteindre ces objectifs MSA. 2.0 Architecture de microservices (MSA) 2.1 Principales caractéristiques MSA est un modèle d’architecture d’application dans lequel une application volumineuse est décomposée en de nombreux microservices faiblement couplés. L’objectif des microservices est de décomposer suffisamment l’application afin de faciliter le développement et le déploiement d’applications agiles. Contrairement à une application monolithique plus classique, dans laquelle tout est étroitement couplé et déployé comme un seul gros morceau, une architecture de microservice tente de découpler tous les modules, où chaque service a sa propre portée unique et bien définie et s’exécute dans son propre processus. Chaque microservice doit idéalement posséder une seule responsabilité. En permettant aux petites équipes autonomes de développer, déployer et mettre à l’échelle leurs services respectifs de manière indépendante, les microservices permettent un développement parallèle, accélérant ainsi considérablement le cycle de production. MSA est une évolution de l’architecture orientée services (SOA) et l’adoption d’une MSA est étroitement corrélée avec l’utilisation de DevOps et l’intégration continue et la livraison continue (CI / CD). Le SOA classique est souvent implémenté à l’intérieur de monolithes de déploiement et est davantage axé sur la plateforme, tandis que les microservices doivent être déployables indépendamment et offrent donc plus de flexibilité dans toutes les dimensions. Les microservices natifs du cloud (microservices qui exploitent les avantages du cloud computing, de l’empaquetage de conteneurs et de la gestion dynamique) amenent le concept SOA à un nouveau niveau où l’infrastructure cloud permet aux services d’être implémentés et gérés à grande échelle. Docker et Kubernetes fournissant des moyens efficaces de développer, déployer et gérer des microservices, les développeurs peuvent lancer d’innombrables services en même temps, surveiller les services et fournir à chaque service les ressources dont il a besoin. Chaque microservice peut être déployé, mis à niveau, mis à l’échelle et redémarré indépendamment de tous les services frères de l’application. Figure 3 : architecture monolithique et architecture de microservices 2.2 Architecture de microservices : avantages et inconvénients Avantages  Les services individuels sont beaucoup plus rapides à développer, tester et déployer, et beaucoup plus faciles à comprendre et à gérer. Ils sont réutilisables aussi.  Chaque service est développé indépendamment par une équipe qui se concentre sur ce service et qui est libre de choisir les technologies qui ont du sens. Les développeurs ont rarement besoin de coordonner le déploiement des modifications qui sont locales à leur service. Ces types de modifications peuvent être déployés dès qu’elles ont été testées.  MSA permet la livraison et le déploiement continus d’applications volumineuses et complexes.  MSA permet à chaque service d’être mis à l’échelle indépendamment. Les développeurs peuvent déployer uniquement le nombre d’instances de chaque service qui répondent à ses contraintes de capacité et de disponibilité. En outre, ils peuvent utiliser une infrastructure de déploiement optimisée qui correspond le mieux aux besoins en ressources d’un service.  MSA crée une isolation améliorée des pannes. Par exemple, s’il existe une fuite de mémoire dans un service, seul ce service sera affecté. Les autres services continueront à traiter les demandes. En comparaison, un composant qui se comporte mal d’une architecture monolithique peut faire tomber l’ensemble du système. Inconvénients Comme toutes les autres technologies, l’architecture de microservices présente des inconvénients et n’est pas une solution miracle. Voici une liste de quelques inconvénients.  La décomposition des données et leur traitement en microservices indépendants peuvent augmenter la complexité de la conception. o Une application cliente doit connaître plusieurs points de terminaison pour exécuter une fonction significative et chaque microservice doit connaître au moins un ou deux autres microservices, par exemple comment interagir, adresses IP, etc. o Les développeurs doivent faire la différence entre les microservices internes et externes et implémenter le mécanisme de communication interservices entre ces types. En outre, la découverte de services côté client et côté serveur est cruciale. o Les développeurs doivent également écrire du code pour gérer l’échec partiel, car la destination d’une demande peut être lente ou indisponible. Ils doivent également gérer les transactions distribuées pour implémenter des cas d’utilisation qui s’étendent sur plusieurs services.  Les applications clientes auront du mal à consommer les services en raison des variations dans les interfaces et les protocoles de sécurité dues aux différentes équipes implémentant les microservices.  Les microservices entraînent davantage d’appels réseau et, par conséquent, un monolithe étant donné que le même matériel fonctionne généralement mieux.  Les outils de développement/IDE sont orientés sur la création uploads/Ingenierie_Lourd/ architecture-de-microservices-pilotee-par-apiapi.pdf