Microservices

Introduction
L'architecture logicielle est la structure fondamentale d'un logiciel, qui définit

les exigences techniques et opérationnelles. Il est responsable de l'optimisation de
chaque attribut d'une application, comme l'efficacité, la gérabilité, l'évolutivité, la
fiabilité, la modifiabilité, la déployabilité et bien d'autres aspects. C'est pourquoi le
choix de l'architecture appropriée est si important dans la phase primaire du
développement logiciel. Il existe plusieurs types d'architectures logicielles,
cependant, les architectures monolithiques et microservices sont parmi les plus
populaires.
De nos jours, de nombreuses entreprises, telles que Netflix, Amazon et
eBay, ont migré leurs applications et leurs systèmes vers le cloud, car le modèle de
cloud computing permet à ces entreprises d'adapter leurs ressources informatiques
en fonction de leur utilisation. Martin Fowler a défini l'architecture des
microservices comme une approche de développement d'une suite de petits
services fonctionnant comme une seule application. Les services communiquent
via des mécanismes légers, tels qu'une API de ressource HTTP et chaque service
s'exécute indépendamment dans son propre processus.
D'autre part, l'architecture monolithique est une application avec une seule base de
code qui comprend plusieurs services. Ces services communiquent avec des
systèmes externes ou des consommateurs via différentes interfaces comme les
services Web, les pages HTML ou l'API REST.
Dans l'architecture monolithique, des applications peuvent être créées à
partir de dizaines ou de centaines de services différents étroitement couplés dans
une base de code monolithique. Cela peut créer de nombreuses difficultés pour les
équipes travaillant dans le même environnement. Par conséquent, de nombreuses
entreprises se tournent vers une architecture de microservices pour permettre à
leurs équipes de développement de se coordonner facilement.
Par conséquent, dans ce rapport, il y a une introduction de l’architecture
monolithique et ses inconvénients en termes de performance pour ensuite citer les
solutions proposées avant de présenter la solution actuellement utilisée, c’est
l’architecture des microservices.
L’architecture monolithique
Principe
En général, l'architecture monolithique utilise une technologie de
développement unique, limitant la disponibilité d'un outil adapté pour chaque tâche
que le système doit exécuter. Selon Nielsen, dans un seul exécutable logique, toute
modification effectuée dans une section de ce type de système implique la
construction et le déploiement d'une nouvelle version de l'ensemble du système.
Les aspects les plus impliqués ou les couches de présentation, de traitement et de
stockage constituent un composant unique du logiciel requis pour s'exécuter sur un
serveur.
Le logiciel monolithique est conçu pour être autonome, dans lequel les
composants ou les fonctions du programme sont étroitement couplés plutôt que
faiblement couplés , comme dans les programmes logiciels modulaires . Dans une
architecture monolithique, chaque composant et ses composants associés doivent
tous être présents pour que le code soit exécuté ou compilé et pour que le logiciel
s'exécute.
Les applications monolithiques sont à un niveau, ce qui signifie que plusieurs
composants sont combinés en une seule grande application. Par conséquent, ils ont
tendance à avoir de grandes bases de code , ce qui peut être lourd à gérer dans le
temps.
De plus, si un composant du programme doit être mis à jour, d'autres éléments
peuvent également nécessiter une réécriture, et l'ensemble de l'application doit être
recompilé et testé. Le processus peut prendre du temps et peut limiter l'agilité et la
rapidité des équipes de développement de logiciels. Malgré ces problèmes,
l'approche est toujours utilisée car elle offre certains avantages. De plus, de
nombreuses premières applications ont été développées en tant que logiciels
monolithiques, de sorte que l'approche ne peut pas être complètement ignorée
lorsque ces applications sont encore utilisées et nécessitent des mises à jour.
Exemple
Pour comprendre l'architecture monolithique, prenons un exemple d'application
bancaire. Le site Web de l'application bancaire autorise d'abord les clients, les
connecte à leur compte et leur permet d'effectuer des transferts d'argent en ligne
vers d'autres comptes. Plusieurs composants sont impliqués dans l'ensemble de ce
processus, y compris l' interface utilisateur orientée client , ainsi que des services
d'authentification de l'utilisateur , de téléchargement de relevés, de transferts
d'argent, etc.
Si l'application utilise une architecture monolithique, elle est construite et déployée

en tant qu'application unique, quelle que soit la façon dont un client l'utilise. Ainsi,
que les utilisateurs accèdent à l'application depuis leur bureau ou depuis un appareil
mobile , l'application reste étroitement couplée, et tous les différents composants et
modules sont directement connectés les uns aux autres. Il peut également utiliser
un système de gestion de base de données relationnelle comme source de données
unique. Enfin, si des modifications sont nécessaires pour un composant, des
modifications de code sont également requises pour tous les autres composants
concernés.
Figure 1 - Modèle de l’architecture monolithique
Les applications monolithiques sont généralement constituées de plusieurs

composants interconnectés pour former une seule grande application. Ces
composants sont structurés en plusieurs couches séparées dépendantes selon un
couplage faible à travers des interfaces qui expose les traitements de chaque
couche.
La couche DAO
La couche DAO dans l'architecture logicielle est chargée de fournir la prise en
charge de la manipulation des données aux consommateurs de données de couche
supérieure indépendamment de la couche de persistance des données sous-jacente.
L'idée est que si nous décidons de remplacer complètement la couche de
manipulation de données, les autres couches n'en seront même pas conscientes. Il
se compose d'un ensemble de classes gérant la communication avec la couche de
persistance, qu'il s'agisse d'une base de données (NO)SQL, d'un système de fichiers
ou d'un service REST externe. Il fournit également un ensemble cohérent
d'abstractions aux consommateurs de couche supérieure du DAO, rationalisant
leurs options d'accès et unifiant leur expérience d'accès à une approche plus
standardisée. De plus, fournir des informations sur les charges sur les composants
et sa nature aux décideurs et comment optimiser, où optimiser, pourquoi…
La couche Service
La couche service représente la couche qui implémente la logique métier
d’une application. Toutes les spécifications fonctionnelles du problème sont
implémentées dans cette couche. Cette couche est constituée d’interfaces et
d’implémentations. Les opérations de cette couche sont souvent transactionnelles.
Les transactions sont gérées facilement en utilisant «Spring Transactions» d’une
manière déclarative à travers l’annotation @Transactional. Cette couche est liée aux
interfaces de la couche DAO (Repositories) pour les opérations nécessitant l’accès
aux bases de données de l’application. Pour éviter de faire propager les entités JPA
qui sont lourdes du fait qu’elle soit surveillée par le Framework de persistance
comme Hibernate, vers les couches supérieures de l’application comme la couche
Web (UI), il est souvent recommandé de créer d’autres objet DTO (Data Transfer
Object) pour le transfert des données issues des entités JPA vers la couche UI Web.
De ce fait, dans les bonnes pratiques, les opérations de la couche services

reçoivent en entrée des paramètres de type RequestDTO et retourne des objets de
type ResponseDTO. Ce qui impose de faire, dans les méthodes de la couche
service, le mapping entre les objets des entités persistantes et les objets DTO.
La couche Web
La couche Web représente la couche qui expose les fonctionnalités de
l’application pour un client http. Pour le cas de Spring, la couche Web est basée sur
Spring MVC qui déploie un contrôleur Frontal DispatcherServlet par lequel toutes
les requêtes http passent avant d’être dispatchées vers les contrôleurs de cette
couche Web.
Pour chaque requête cliente, une opération du contrôleur est invoquée par
DispatcherSevlet en lui transmettant les données de la requête dans un objet de
type RequestDTO conçu sur mesure à chaque type requête UI. L’opération du
contrôleur fait souvent appel à la couche service pour appliquer la logique métier
en lui transmettant en Input l’objet RequestDTO, après quoi le contrôleur reçoit en
retour sous forme d’objet ResponseDTO. Il ne reste au contrôleur qu’à envoyer la
partie UI les résultats les résultats au rendu UI, soit au format HTML ou encore au
format JSON pour les modèles classiques ou au format binaire GRPC pour les
modèles plus récents basés sur la technologie GRPC qui exploite les atouts du
protocole Http2 apportant plus de performances au niveau de la communication
entre le Browser et serveur Web.
Nielsen, D. Enquêter sur la disponibilité et la maintenabilité dans une architecture

de microservice. doctorat Thèse, Université d'Aarhus, Aarhus, Danemark, 2015.
Inconvénients d'une architecture monolithique
Comme dans le cas de Netflix, les applications monolithiques peuvent être
assez efficaces jusqu'à ce qu'elles deviennent trop volumineuses et que la mise à
l'échelle devienne un défi. Apporter une petite modification à une seule fonction
nécessite de compiler et de tester l'ensemble de la plate-forme, ce qui va à
l'encontre de l'approche agile privilégiée par les développeurs d'aujourd'hui.
Les inconvénients d'un monolithe comprennent:
➔ Vitesse de développement plus lente – Une grande application

monolithique rend le développement plus complexe et plus lent.
➔ Évolutivité – Vous ne pouvez pas mettre à l'échelle des composants
individuels.
➔ Fiabilité - S'il y a une erreur dans un module, cela pourrait affecter la
disponibilité de l'ensemble de l'application.
➔ Obstacle à l'adoption de la technologie - Toute modification du cadre ou
du langage affecte l'ensemble de l'application, ce qui rend les modifications
souvent coûteuses et chronophages.
➔ Manque de flexibilité - Un monolithe est limité par les technologies déjà
utilisées dans le monolithe.
➔ Déploiement - Une petite modification d'une application monolithique
nécessite le redéploiement de l'ensemble du monolithe.

Microservices

Transféré par

Droits d'auteur :

Formats disponibles

Microservices

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Microservices

Transféré par

Droits d'auteur :

Formats disponibles

Introduction

L'architecture logicielle est la structure fondamentale d'un logiciel, qui définit

Si l'application utilise une architecture monolithique, elle est construite et déployée

Les applications monolithiques sont généralement constituées de plusieurs

De ce fait, dans les bonnes pratiques, les opérations de la couche services

Nielsen, D. Enquêter sur la disponibilité et la maintenabilité dans une architecture

➔ Vitesse de développement plus lente – Une grande application

Vous aimerez peut-être aussi