Développeur Java Full Stack
Nom: KAHE FABIEN
Sexe: Masculin
Formation :– BTS en informatique de gestion Agitel
– Développeur Web et Mobile Java Objis
Expériences professionnelles :
– Développeur Java Full Stack chez Ebenyx Technologies depuis 2020, où je travaille sur des solutions innovantes et efficaces liés au domaine Portuaire.
– Création d’une application Web pour ONG locale à l’aide de Spring, Hibernate et Angular. L’application permettait de cartographier les points d’enrôlement pour les élections en côte d’ivoire.
Langages de programmation et méthodologies : – Compréhension des concepts et des principes de programmation Java
– Expérience avec les frameworks: Spring,Hibernate,EclipseLink,Jsf
– Connaissance des technologies front-end telles que HTML, CSS et JavaScript, Angular , React – Connaissance des bases de données SQL et NoSQL (MySQL, Postgres,MongoDB)
– Connaissance de Git et les outils d’intégration continue
– Connaissance des méthodologies de développement Agile
– Compétences en résolution de problèmes et en analyse
13 raisons ou avantages de développer une application en plusieurs micro-services
Cet article a pour objectif de faire une introduction de la notion d’architecture micro-services (architecture d’application) et de présenter ces avantages de cette architecture.
Avant l’arrivée du concept des Micro-services on développait les applications de façon Monolithique. Une application monolithique est souvent une grande application développée en un seul Bloc. C’est-à-dire que l’application est développée pour un problème donné aussi grand qu’il soit. Une application monolithique utilise souvent une seule grande base de données qui englobe toutes les données de l’application.
L’architecture micro-services consiste à découper le périmètre fonctionnel d’un grand projet d’application en plusieurs petites parties élémentaires. Pour chaque partie élémentaire, on développe une petite application indépendante dite micro-service.
Le diagramme ci-dessous est un modèle de référence simple pour une architecture de micro-services. Il illustre un système informatique(application) composé de plusieurs micro-services qui communiquent soit de manière synchrone – via des appels d’API internes que chaque micro-service expose, soit de manière asynchrone – à travers un bus d’événements basé sur des Brokers comme RabbitMQ, KAFKA et ActiveMQ.
Les systèmes externes (utilisateurs, applications, partenaires B2B, etc.) ne peuvent interagir avec les microservices que via un ensemble d’API orientées vers l’extérieur, communément appelées passerelle API. Les services à l’intérieur de la frontière peuvent librement consommer des services externes si nécessaire.
Un micro-service gère généralement une petite poignée de responsabilités connexes; par exemple, traiter les commandes.
Un autre micro-service pourrait être responsable de l’expédition. Un autre pourrait s’occuper du paiement. Ensemble de ces micro-services pourraient fonctionner comme une application de e-commerce. Un exemple de ceci est illustré ci-dessous.
Prenons l’exemple d’une panne d’une plate-forme de ecommerce .
Chaque micro-service dans l’image ci-dessus joue un rôle spécifique, prenant entièrement soin d’un domaine isolé – tel que le panier d’achat, l’inventaire, le placement de commande, les paiements, l’expédition, les rapports et les commandes en souffrance des fournisseurs. Le service de panier d’achat agit comme une sorte de passerelle API pour isoler l’application cliente de la logique métier nécessaire pour exécuter les commandes.
Les micro-services communiquent de manière synchrone uniquement lorsque cela est absolument nécessaire ; par exemple, le service de passation de commandes vérifiera l’inventaire et les paiements avant d’enregistrer la commande de manière asynchrone en publiant un événement sur un topic Kafka. Dans le cas de notre exemple le service inventaire et le service contrôle du paiement sont synchrones (communication synchrone), car l’échec de l’un ou l’autre des contrôles doit empêcher la progression de la commande. Une fois qu’une commande est enregistrée, le reste de l’exécution peut être entièrement asynchrone. Peu importe le moment où la commande est expédiée ou si la commande en attente est déclenchée – aucune de ces actions n’a d’impact sur le parcours de paiement du client. Par conséquent, si le service de réapprovisionnement du fournisseur est momentanément interrompu ou si le service expédition est en attente pour quelque raison que ce soit, le reste du système peut fonctionner normalement, bien que les commandes en attente ne soient pas passées auprès de nos fournisseurs tant que la panne n’est pas corrigée.
Remarque : Sur le point de communication synchrone vs asynchrone : l’asynchrone est préféré car il réduit le couplage, mais la communication synchrone est parfois nécessaire. Ce serait une mauvaise expérience client si nous laissions la commande se poursuivre sans même vérifier si nous avions un stock suffisant. Mais la communication synchrone ne garantit pas la cohérence : il est possible qu’un contrôle d’inventaire réussisse, pour échouer plus tard lorsque la commande est exécutée en arrière-plan. (Les commandes simultanées peuvent vérifier individuellement la présence de stock, ce qui peut ne pas être suffisant pour couvrir toutes les commandes au point d’exécution.)
Les raisons d’adopter une architecture micro-services
Considérons les problèmes inhérents aux applications monolithiques :
- Pour chaque modification, l’intégralité de l’application doit être reconstruite et redéployée, quelle que soit l’ampleur de la modification. Des temps de construction de 15 à 30 minutes ne sont pas rares pour les grandes applications.
- Un petit changement dans une partie d’une application a le potentiel de casser tout le système.
- Au fur et à mesure que l’application grandit, ses parties ont tendance à s’entremêler et la base de code devient difficile à comprendre et à maintenir.
- Les applications volumineuses ont une empreinte de ressources proportionnellement importante – elles consomment généralement plus de mémoire et nécessitent plus de puissance de calcul. Par conséquent, ils doivent être hébergés sur de gros serveurs avec une capacité de ressources suffisante. Cela limite également leur capacité à évoluer.
- Ils ont également tendance à avoir un temps de démarrage lent, ce qui n’est pas idéal, étant donné que même les changements les plus infimes ont tendance à nécessiter un redéploiement complet. Ils sont moins adaptés au Cloud et ne peuvent pas facilement tirer parti de l’informatique éphémère, comme les instances ponctuelles.
- Une technologie unique est utilisée pour mettre en œuvre l’ensemble de l’application, souvent un compromis entre la généralité et les besoins de domaines spécifiques de l’application. Java et .Net sont probablement des candidats pour les monolithes parce qu’ils font partie des meilleurs langages « polyvalents », et non parce qu’ils sont étonnamment bons pour une tâche particulière.
- L’évolutivité de l’équipe est naturellement limitée par une grande base de code. Plus l’application est complexe (en termes de dépendances internes), plus il est difficile d’accueillir confortablement de grandes équipes de développeurs, sans que les gens se marchent sur les pieds.
Avantages de l’architecture micro-services
- Évolutivité. Les processus individuels d’une architecture de micro-services peuvent évoluer pour répondre à leurs demandes. Les applications plus petites peuvent évoluer à la fois horizontalement (en ajoutant plus d’instances) et verticalement (en augmentant les ressources disponibles pour chaque instance).
- Modularité. Un avantage évident d’avoir des applications plus petites et autonomes est que la séparation physique entre les processus vous oblige à aborder le couplage au premier plan de votre conception. Chaque application devient responsable de remplir moins de responsabilités, ce qui se traduit par un code plus compact et plus cohérent.
- Diversité technologique. Les applications de micro-services sont des unités autonomes qui communiquent sur des standards ouverts. Cela signifie que les choix technologiques derrière les implémentations de micro-services sont beaucoup moins importants par rapport à un monolithe ; c’est-à-dire que les choix comptent pour le micro-service en question, mais ne concernent pas le reste du système. Il n’est pas rare de voir une seule architecture de micro-services mise en œuvre avec un mélange de technologies – Java et Go pour la logique métier, Node.js pour les passerelles API et les problèmes de présentation, et Python pour le reporting et l’analyse.
- Possibilités d’expérimentation. Dans le prolongement du point précédent, un micro-service est autonome et peut être conçu et développé séparément de ses amis. Il aura sa propre base de données, distincte des autres. Il peut être construit dans un langage qui convient le mieux à son objectif. Cette autonomie permet à l’équipe d’expérimenter en toute sécurité de nouvelles technologies, approches et processus, et de se limiter à un seul service.
- Facilite la migration. Les bases de code plus petites sont plus faciles à refactoriser et même les micro-services individuels mal écrits ne retardent pas le reste du système.
- Résilience et disponibilité. Quand un monolithe s’effondre, l’entreprise s’arrête. Bien sûr, la même chose pourrait être dite pour les micro-services mal conçus, fortement couplés avec des interdépendances complexes. Cependant, une bonne architecture de micro-services met l’accent sur le couplage faible, où les services sont autonomes, possèdent entièrement leurs dépendances et minimisent la communication synchrone (bloquante). Lorsqu’un micro-service tombe en panne, il aura invariablement un impact sur une partie du système et affectera certains utilisateurs, mais il permettra généralement à d’autres parties du système de fonctionner.