Les microservices pour une architecture orientée web n°2

Les microservices pour une architecture orientée web n°2

Un changement de point de vue

Cet article s'insère dans la série “microservices” écrite par François Berthault dans le cadre de la participation de Talan Labs à Devoxx 2017, du 5 au 7 avril prochains au Palais des Congrès de Paris.

Dans la littérature, les microservices sont représentés la plupart du temps par de petits hexagones. C’est une référence à un modèle d’architecture appelé architecture hexagonale, introduit par Alistair Cockburn pendant les années 2000.

L’architecture hexagonale : clef de voûte des microservices

Alistair Cockburn définit ce modèle aujourd’hui appelé Ports & Adapters comme suit :

“[The Ports & Adapters pattern] a_llows an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases._”

Hexagonal Architecture and Microservices © Geeks With Blogs Hexagonal Architecture and Microservices © Geeks With Blogs

Attention cependant, il se pourrait que vous arriviez à une solution qui ressemble à ceci :

Attention à la complexité ! © Ploeh Blog Attention à la complexité ! © Ploeh Blog

Contre les pannes et défaillances, la résilience

Dans les architectures microservices, la tolérance aux pannes est un pré-requis et non une singularité. La conséquence directe d’utiliser des services comme composants est que l’application doit être pensée pour accepter les appels de service pouvant échouer.

Les problèmes sont classiques :

  • une requête vers un système distant trop longue ;
  • l’interaction avec un service occupé à 100 % de sa capacité ;
  • un client qui renvoie une exception.

Mais une erreur dans un service ne doit pas impacter l’expérience utilisateur. Les applications doivent automatiquement prendre des actions correctives quand une de leurs dépendances est défaillante. C’est ce que l’on appelle la résilience.

Échouer pour mieux repartir

Un service en échec ne doit en aucun cas dégrader les services le consommant. Compte tenu de ce besoin architectural, les solutions à utiliser sont des combinaisons de :

  • timeout réseaux et de retries ;
  • séparation des threads en pool ;
  • utilisation de sémaphores non bloquant (tryAcquire) ;
  • circuit breakers.

Le but ici est d’échouer rapidement afin de garantir la santé du reste de votre application. Une erreur n’est jamais plaisante en termes d’expérience utilisateur mais permettre à son système de se rétablir par lui-même rapidement est une option non négligeable.

Architecture microservices Hysterix defend your app

Netflix Hystrix est certainement la librairie la plus célèbre pour la gestion de latence et de tolérance aux pannes. Elle a été conçue par Netflix en 2011 pour isoler les points d'accès à un système distant, un service ou à une librairie tierce.

En conclusion, le modèle en microservices doit donc faire évoluer le point de vue des développeurs dans la création des applications. Au-delà, c’est aussi l’organisation des projets qui s’en trouve profondément modifiée. C’est le sujet abordé dans le volet numéro 3 de cette série [lien du billet n°3].

Vous avez aimé cet article ? Découvrez ou redécouvrez les autres épisodes de la série « Les microservices pour une architecture orientée web » :

Partie 1 Les microservices pour une architecture orientée web n°1 : Définitions et caractéristiques

Partie 3  Les microservices pour une architecture orientée web n°3 : Organisation des équipes pour un projet d’architecture en microservices

Etoile Talan
Avatar François BERTHAULT

François BERTHAULT

Coach DevOps

comments powered by Disqus