Architecture Micro-Service

Micro service  (µ-service) s’agit d’une unité fonctionnelle inter-opérant avec d’autres µservices.  Un micro service se distingue par une seule responsabilité (fonctionnelle) qu’il assure. Il se caractérise par son autonomie (d’un point de vue fonctionnelle). Autrement dit, il s’agit d’une approche de développer une application comme étant une suite de petits services où chacun d’entre eux opère d’une façon autonome et communiquent avec les autres µservices.

L’architecture orientée micro-services a été présentée comme étant le remède miracle des architectures monolithiques des systèmes d’informations. Ceci est attesté par le fait qu’elle permet de contourner les limites du monolithiques.

Apport de l’architecture :

  1. De la souplesse, et de l’agilité sont les promesses de l’architectures micro-services. En effet le découpage du système en sous-systèmes permet de cohabiter diverses équipes de développent autour de grand projets sans créer de situation de blocage ou encore de dépendance. Idéalement un microservice s’étend sur un sprint de deux semaines en termes de temps de développements et requière une pizza team (équipe de 6 à 7 personnes).
  2. de l’innovation : à travers la décompositions impliquant le minimum de dépendance possible, il est possible d’explorer de nouvelles pistes technologiques sans mettre en cause l’existant.
  3. Maintien : l’architecture microservice est une réponse au principe de Descartes consistant à décomposer un grand problème en plusieurs petits sous problèmes. En effet ; le maintient en termes d’évolution et de correctif est plus faciles grâce à l’isolation des différentes briques fonctionnelles.
  4. Davantage de déploiements : en minimisant l’impact d’un déploiement en focalisant le déploiement sur les microservices concernés – le système est exposé ainsi à moins d’impact. L’arrêt ne concernerait que quelques fonctionnalités alors la globalité du système continue de tourner.
  5. Plus de souplesse pour la répartition de charge et encore pour l’augmentation de performance (basculement d’un microservice vers un service dédié, la répartition de tâches entre diverses instances de microservices).

Inconvénients : 

  1. Les microservices sont à consommer avec modération. En effet, ça peut vite dériver vers une multitude de microservice via un découpage assez fin coté fonctionnelles diluant par la suite la maîtrise du systèmes.
  2. La conception tâche fastidieuses : bien qu’ils existent diverse approches (le TDD, le découpage faible, etc.). le découpage de gros systèmes d’information reste toutes fois une tâche délicates ou la dérive en macro-service et en nano-services peuvent arriver.
  3. Un surtraffic : partant du principe qu’un microservice dispose de sa propose base de données ; je vous laisse le soin d’imaginer dans le cas d’un système à une trentaine de microservice (et par la suite 30 bases de données) le traffic de données entre ses bases en termes de syncronisation …
  4. Gestion des versions : vu la facilité et de l’impact réduit des déploiement les microservices peuvent dériver rapidement dans les sytèmes complexes en un enfer de gestion de versions ou la compatibilité avec les versions antérieures est un impératif pour assurer l’indépendance et le bon fonctionnement des autres microservices.

Règles d’or :

  • de l’autonomie plus que l’autorité : l’architecture micro-service favorise la copie de données d’une microsevice que se centraliser les données dans une seule porte d’entrée
  • D’un point organisationnel, un impact serait observé au niveau de la gestion de l’équipe. En effet, elle doit s’orienter vers un aspect multidisciplinaire.
  • Contrainte de performance : en adoptant un schéma de découplage marqué par une cohésion forte risque de saturer le réseau vu la forte fréquence d’échange et la suite de dégrader les performances d’échanges (ce qui dégrade les performances générales du système ou de l’application.).
  • Vu la diversité des techniques et outils pouvant être déployés en vue de mettre en place des services, les performances et la fiabilité du service doit faire objet d’un processus rigoureux de tests (tests automatisés, tests d’intégration, analyse du code, etc.).
  • Comme les logs doivent être centralisé sous forme d’un seul µ service, ces derniers doivent être bien organisés et structurés afin d’éviter que la tâche de recherche de log soit une tâche fastidieuse. Certains outils d’analyse et de visualisation existent sur le marché : https://www.elastic.co/fr/ et pour le transfert de logs : http://flume.apache.org/
  • Il est fortement de déconseillé de partager le code entre µservices afin de garantir une isolation et une évolutivité optimale des µservices.

Mots-clefs :,

Propagation des épidémies |
Robotisation medicale |
Blog mini-serre automatisée. |
Unblog.fr | Annuaire | Signaler un abus | Enviedapprendre75
| Techniqueleyna
| Mattech