Plan du site  
pixel
pixel

Articles - Étudiants SUPINFO

Qu’est-ce que l'architecture Microservices ?

Par Arnaud PHILIPPS Publié le 26/09/2017 à 21:22:20 Noter cet article:
(0 votes)
Avis favorable du comité de lecture

Introduction

L'architecture des microservices, ou simplement les microservices, est une méthode distinctive de développement de systèmes logiciels qui a connu une popularité ces dernières années. En fait, bien qu'il n'y ait pas de de documentation « officiel » sur la manière de procéder, pour de nombreux développeurs, cette méthode est devenue incontournable pour la création d’une application d'entreprise. Grâce à son évolutivité, cette méthode architecturale est considérée comme particulièrement idéale lorsque vous devez gérer la compatibilité avec une gamme de plates-formes et de périphériques, couvrant le web, le mobile, l'IOT, ou tout simplement lorsque vous ne savez pas quel type de périphérique vous devrez soutenir dans un avenir de plus en plus nuageux.

Bien qu'il n'y ait pas de définition standard standard de microservices, il existe certaines caractéristiques qui nous aident à identifier le style. Essentiellement, l'architecture microservice est une méthode de développement d'applications logicielles en tant que suite de services modulables et indépendamment, dans lesquels chaque service exécute un processus unique et communique à travers un mécanisme léger et bien défini pour atteindre un objectif commercial.

Pour commencer à comprendre l'architecture des microservices, on va examiner son opposé: le style architectural monolithique. Contrairement aux microservices, une application monolithique est toujours construite comme une seule unité autonome. Dans un modèle client-serveur, l'application côté serveur est un monolithe qui gère les requêtes HTTP, exécute la logique et récupère / met à jour les données dans la base de données sous-jacente. Cependant, le problème avec une architecture monolithique est que tous les cycles de changement finissent généralement par être liés les uns aux autres. Une modification apportée à une petite partie d'une application peut nécessiter la construction et le déploiement d'une version entièrement nouvelle. Si vous devez mettre à l'échelle les fonctions spécifiques d'une application, vous devrez peut-être mettre à l'échelle toute l'application au lieu des composants souhaités. C'est là que les microservices arrivent à la rescousse.

Comprendre l’architecture microservices

Tout d'abord, les logiciels construits sous forme de microservices peuvent, par définition, être divisés en services à composants multiples. Pourquoi? Afin que chacun de ces services puisse être déployé, ajusté, puis redéployé indépendamment sans compromettre l'intégrité d'une application. En conséquence, vous devrez seulement changer un ou plusieurs services distincts au lieu d'avoir à redéployer des applications entières. Mais cette approche a ses inconvénients, y compris les appels distants coûteux (au lieu des appels en cours d'exécution), des API distantes plus grossières et une complexité accrue lors de la redistribution des responsabilités entre les composants. Deuxièmement, le style microservices est généralement organisé autour des capacités et des priorités de l'entreprise. Contrairement à une approche de développement monolithique traditionnel, où les différentes équipes ont chacune une attention particulière, par exemple, les IU, les bases de données, les couches technologiques ou l'architecture microservice logique côté serveur, utilise des équipes interfonctionnelles. Les responsabilités de chaque équipe sont de fabriquer des produits spécifiques basés sur un ou plusieurs services individuels communiquant via le bus de messages. Cela signifie que lorsque des changements sont requis, il n'y aura pas nécessairement de raison pour le projet, dans son ensemble, de prendre plus de temps ou de faire attendre l'approbation budgétaire avant que les services individuels ne puissent être améliorés. Troisièmement, les microservices sont conçus pour faire face à l'échec. Étant donné que plusieurs services uniques et diversifiés communiquent ensemble, il est tout à fait possible qu'un service puisse échouer, pour une raison ou une autre (par exemple, lorsque le fournisseur n'est pas disponible). Dans ces cas, le client devrait permettre à ses services voisins de fonctionner. Pour des raisons évidentes, cette exigence ajoute plus de complexité aux microservices par rapport à l'architecture des systèmes monolithiques. Pour résumer: l'architecture Microservice utilise des services pour composer et est généralement organisée autour des capacités commerciales; se concentre sur les produits au lieu des projets; a des points d'extrémité intelligents, mais des mécanismes de flux d'information simple; utilise une gouvernance décentralisée ainsi qu'une gestion décentralisée des données; est conçu pour tenir compte des interruptions du service; et, last but not least, est un modèle évolutif.

Avantages et inconvénients

Un problème commun consiste à partager la logique de schéma / validation entre les services. Ce que A requiert pour considérer certaines données valides ne s'applique pas toujours à B, si B a des besoins différents. La meilleure recommandation consiste à appliquer les versions et à distribuer un schéma dans les bibliothèques partagées. Les modifications apportées aux bibliothèques deviennent des discussions entre les équipes. En outre, avec un contrôle de version robuste, les dépendances, ce qui peut causer plus de frais généraux. La meilleure pratique pour résoudre ce problème consiste à prévoir une compatibilité ascendante et à accepter des tests de régression par des services / équipes externes. Cela vous invite à avoir une conversation avant de perturber le processus métier de quelqu'un d'autre, et non pas après. Comme pour toute autre chose, que l'architecture microservice soit ou non pour vous, dépend de vos besoins, car tous ont leurs avantages et leurs inconvénients. Voici un résumé rapide de certains des bons et des mauvais:

Les avantages

  • L'architecture Microservice offre aux développeurs la liberté de développer et de déployer de manière indépendante

  • Un microservice peut être développé par une équipe assez petite

  • Le code pour différents services peut être écrit dans différentes langues (bien que de nombreux praticiens le découragent)

  • Intégration facile et déploiement automatique (utilisation d'outils d'intégration continue open source tels que Jenkins, Hudson, etc.)

  • Facile à comprendre et à modifier pour les développeurs, peut donc aider un nouveau membre de l'équipe à devenir productif rapidement

  • Les développeurs peuvent utiliser les dernières technologies

  • Le code est organisé autour des capacités commerciales

  • Lorsqu'une modification est requise dans une certaine partie de l'application, seul le service connexe peut être modifié et redéployé: il n'est pas nécessaire de modifier et de redéployer l'application entière

  • Meilleure isolation des pannes: si un microservice échoue, l'autre continuera à fonctionner (même si une zone problématique d'une application monolithique peut compromettre l'ensemble du système)

  • Facile à dimensionner et à intégrer à des services tiers

  • Pas d'engagement à long terme envers la pile de technologie

Les inconvénients

  • En raison du déploiement distribué, les tests peuvent devenir compliqués et fastidieux

  • L'augmentation du nombre de services peut entraîner des barrières d'information

  • L'architecture apporte une complexité supplémentaire car les développeurs doivent atténuer la tolérance aux pannes, la latence du réseau et traiter différents formats de messages ainsi que l'équilibrage de charge

  • Étant un système distribué, cela peut entraîner des doubles emplois

  • Lorsque le nombre de services augmente, l'intégration et la gestion de produits entiers peuvent devenir compliquées

  • En plus de plusieurs complexités de l'architecture monolithique, les développeurs doivent faire face à la complexité supplémentaire d'un système distribué

  • Les développeurs doivent mettre des efforts supplémentaires dans la mise en œuvre du mécanisme de communication entre les services

  • La gestion des cas d'utilisation qui couvrent plus d'un service sans utiliser de transactions distribuées n'est pas seulement difficile, mais nécessite également une communication et une coopération entre différentes équipes

  • L'architecture entraîne généralement une consommation de mémoire accrue

  • Le fractionnement de l'application dans les microservices est tout un art

Exemple de microservices

PayPal, Netflix, Soundcloud, eBay, Amazon, Twitter, et bien d' autres sites Web à grande échelle et les applications ont tous évolué de l'architecture monolithique à microservices.

Netflix a une architecture étendue qui a évolué du monolithique à la SOA. Il reçoit plus d' un milliard d' appels par jour, depuis plus de 800 différents types d'appareils, jusqu'à son API streaming-vidéo. Chaque appel d'API affiche environ cinq appels supplémentaires dans le service backend. Amazon a également migré vers des microservices. Ils reçoivent d'innombrables appels d'une variété d'applications, y compris des applications qui gèrent l'API du service Web ainsi que le site Web lui-même, ce qui aurait tout simplement été impossible à gérer leur ancienne architecture à deux niveaux. Le site d'enchères eBay est un autre exemple qui a traversé la même transition. Leur application de base comprend plusieurs applications autonomes, chacune exécute la logique métier pour différentes zones de fonctions.

Le future des microservices

Que l'architecture microservice soit ou non le style privilégié des développeurs à l'avenir, il s'agit clairement d'une idée puissante qui offre de sérieux avantages pour la conception et la mise en œuvre d'applications d'entreprise. Beaucoup de développeurs et d'organisations, sans avoir jamais utilisé le nom ou même l'étiquetage de leur pratique en tant que SOA, ont utilisé une approche visant à optimiser les API qui pourraient être classées en microservices.

A propos de SUPINFO | Contacts & adresses | Enseigner à SUPINFO | Presse | Conditions d'utilisation & Copyright | Respect de la vie privée | Investir
Logo de la société Cisco, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société IBM, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sun-Oracle, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Apple, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sybase, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Novell, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Intel, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Accenture, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société SAP, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Prometric, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Toeic, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo du IT Academy Program par Microsoft, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management

SUPINFO International University
Ecole d'Informatique - IT School
École Supérieure d'Informatique de Paris, leader en France
La Grande Ecole de l'informatique, du numérique et du management
Fondée en 1965, reconnue par l'État. Titre Bac+5 certifié au niveau I.
SUPINFO International University is globally operated by EDUCINVEST Belgium - Avenue Louise, 534 - 1050 Brussels