Contexte

Vous développez une application d’entreprise côté serveur, qui doit prendre en charge une variété de clients différents, notamment des navigateurs de bureau, des navigateurs mobiles et applications mobiles natives.L’application peut également exposer une API à des tiers à consommer.Il peut également s’intégrer à d’autres applications via des services Web ou un courtier de messages.L’application gère les demandes (requêtes et messages HTTP) en exécutant une logique métier; accéder à une base de données; échanger des messages avec d’autres systèmes; et renvoyer une réponse HTML / JSON / XML. Il existe des composants logiques correspondant aux différents domaines fonctionnels de l’application.

Problème

Quelle est l’architecture de déploiement de l’application?

Forces

• Une équipe de développeurs travaille sur l’application
• Les nouveaux membres de l’équipe doivent devenir rapidement productifs
• L’application doit être facile à comprendre et modifier
• Vous souhaitez pratiquer le déploiement continu de l’application
• Vous devez exécuter plusieurs instances de l’application sur plusieurs machines afin de répondre aux exigences d’évolutivité et de disponibilité
• Vous souhaitez tirer parti des technologies émergentes (frameworks, langages de programmation, etc)

Solution

Définir une architecture qui structure l’application comme un ensemble de Cette approche correspond à l’axe Y du Scale Cube.Chaque service est:

• Hautement maintenable et testable – permet Développement et déploiement pid et fréquents
• Lâchement couplé avec d’autres services – permet à une équipe de travailler de manière indépendante la majorité du temps sur son (ses) service (s) sans être impactée par les modifications apportées aux autres services et sans affecter les autres services
• Déploiement indépendant – permet à une équipe de déployer son service sans avoir à se coordonner avec d’autres équipes
• Capable d’être développé par une petite équipe – essentiel pour une productivité élevée en évitant la haute communication des grands

Les services communiquent en utilisant soit des protocoles synchrones tels que HTTP / REST, soit des protocoles asynchrones tels que AMQP. Les services peuvent être développés et déployés indépendamment les uns des autres. Chaque service dispose de sa propre base de données afin de être découplé des autres services.La cohérence des données entre les services est maintenue à l’aide du modèle Saga

Pour en savoir plus sur la nature d’un service, veuillez lire cet article.

Exemples

Applications e-commerce fictives sur

Imaginons que vous construisiez une application e-commerce qui prend les commandes des clients, vérifie l’inventaire et le crédit disponible, et les expédie.L’application se compose de plusieurs composants dont StoreFrontUI, qui implémente l’interface utilisateur , ainsi que des services backend pour vérifier le crédit, maintenir l’inventaire et expédier les commandes. L’application se compose d’un ensemble de services.

Montrez-moi le code

Veuillez consulter les exemples d’applications développées par Chris Richardson. Ces exemples sur Github illustrent différents aspects de l’architecture des microservices.

Contexte résultant

Avantages

Cette solution présente un certain nombre d’avantages:

• Permet la livraison et le déploiement continus de grandes applications complexes.
  • Maintenabilité améliorée – chaque service est relativement petit et donc plus facile à comprendre et à modifier
  • Meilleure testabilité – les services sont plus petits et plus rapides à tester
  • Meilleure déployabilité – services peut être déployé indépendamment
  • Il vous permet d’organiser l’effort de développement autour de plusieurs équipes autonomes. Chaque équipe (dite de deux pizzas) possède et est responsable d’un ou plusieurs services. Chaque équipe peut développer, tester, déployer et faire évoluer ses services indépendamment de toutes les autres équipes.
• Chaque microservice est relativement petit:
  • Plus facile pour un développeur à comprendre
  • L’EDI est plus rapide, ce qui rend les développeurs plus productifs
  • L’application démarre plus rapidement, ce qui rend les développeurs plus productifs et accélère les déploiements
• Amélioration de l’isolation des pannes. Par exemple, s’il y a une fuite de mémoire dans un service, alors seul ce service sera affecté. Les autres services continueront à gérer les demandes. En comparaison, un composant qui se comporte mal d’une architecture monolithique peut faire tomber le système entier.
• Élimine tout engagement à long terme envers une pile technologique. Lorsque vous développez un nouveau service, vous pouvez choisir une nouvelle pile technologique. De même, lorsque vous apportez des modifications majeures à un service existant, vous pouvez le réécrire en utilisant une nouvelle pile technologique.

Inconvénients

Cette solution présente un certain nombre d’inconvénients:

• Les développeurs doivent faire face à la complexité supplémentaire de la création d’un système distribué:
  • Les développeurs doivent implémenter le mécanisme de communication interservices et gérer les pannes partielles
  • Il est plus difficile de mettre en œuvre des demandes qui couvrent plusieurs services
  • Il est plus difficile de tester les interactions entre les services difficile
  • La mise en œuvre de demandes qui couvrent plusieurs services nécessite une coordination minutieuse entre les équipes
  • Les outils de développement / IDE sont orientés vers la création d’applications monolithiques et ne fournissent pas de support explicite pour le développement d’applications distribuées.
• Complexité du déploiement. En production, il y a aussi la complexité opérationnelle du déploiement et de la gestion d’un système composé de nombreux services différents.
• Augmentation de la consommation de mémoire. L’architecture de microservice remplace N instances d’application monolithiques par des instances de services NxM. Si chaque service s’exécute dans sa propre JVM (ou équivalent), ce qui est généralement nécessaire pour isoler les instances, il y a une surcharge de M fois plus d’exécutables JVM. De plus, si chaque service fonctionne sur sa propre VM (par exemple, une instance EC2), comme c’est le cas chez Netflix, la surcharge est encore plus élevée.

Problèmes

Il y a de nombreux problèmes que vous devez résoudre.

Quand utiliser l’architecture de microservice?

L’un des défis liés à l’utilisation de cette approche est de décider quand il est judicieux de l’utiliser. Lors du développement de la première version de une application, vous n’avez souvent pas les problèmes que cette approche résout.En outre, l’utilisation d’une architecture distribuée élaborée ralentira le développement.Cela peut être un problème majeur pour les startups dont le plus grand défi est souvent de faire évoluer rapidement le modèle commercial et l’accompagnement L’utilisation des divisions sur l’axe Y peut rendre l’itération rapide beaucoup plus difficile.Plus tard, cependant, lorsque le défi est de savoir comment mettre à l’échelle et que vous devez utiliser la décomposition fonctionnelle, les dépendances enchevêtrées peuvent rendre difficile la décomposition de votre application monolithique en un ensemble de services.

Comment décomposer l’applica en services?

Un autre défi est de décider comment partitionner le système en microservices. C’est vraiment un art, mais il existe un certain nombre de stratégies qui peuvent aider:

• Décomposer par capacité métier et définir les services correspondant aux fonctionnalités métier.
• Décomposer par sous-domaine de conception pilotée par domaine.
• Décomposer par verbe ou cas d’utilisation et définir les services responsables d’actions particulières . par exemple. un Shipping Service qui est responsable de l’expédition des commandes complètes.
• Décomposer par noms ou ressources en définissant un service qui est responsable de toutes les opérations sur les entités / ressources d’un taper. par exemple. un Account Service responsable de la gestion des comptes utilisateurs.

Idéalement, chaque service ne devrait avoir qu’un petit ensemble de responsabilités. (Oncle) Bob Martin parle de la conception de classes en utilisant le principe de responsabilité unique (SRP) .Le SRP définit la responsabilité d’une classe comme une raison de changer et déclare qu’une classe ne devrait avoir qu’une seule raison de changer.Il est logique d’appliquer le SRP à la conception de services

Une autre analogie qui aide à la conception de services est la conception des utilitaires Unix. Unix fournit un grand nombre d’utilitaires tels que grep, cat et find. Chaque utilitaire fait exactement une chose, souvent exceptionnellement bien, et est destiné à être combiné avec d’autres utilitaires en utilisant un script shell pour effectuer des tâches complexes.

Comment maintenir la cohérence des données?

Afin d’assurer un couplage lâche, chaque service a son propre Le maintien de la cohérence des données entre les services est un défi car la validation en 2 phases / les transactions distribuées une option pour de nombreuses applications.Une application doit à la place utiliser le modèle Saga.Un service publie un événement lorsque ses données changent.D’autres services consomment cet événement et mettent à jour leurs données.Il existe plusieurs façons de mettre à jour de manière fiable les données et de publier des événements, notamment Event Sourcing et Transaction Log Tailing.

Comment implémenter des requêtes?

Un autre défi consiste à implémenter des requêtes qui doivent récupérer des données appartenant à plusieurs services.

• L’API Modèles CQRS (Composition and Command Query Responsibility Segregation).

Il existe de nombreux modèles liés au modèle de microservices. L’architecture monolithique est une alternative à l’architecture microservice. Les autres modèles résolvent les problèmes que vous rencontrerez lors de l’application de l’architecture microservice.

• Modèles de décomposition
  • Décomposer par capacité métier
  • Décomposer par sous-domaine
• Le modèle Base de données par service décrit comment chaque Le service dispose de sa propre base de données afin d’assurer un couplage lâche.
• Le modèle API Gateway définit la manière dont les clients accèdent aux services dans une architecture de microservice.
• Les modèles de découverte côté client et de découverte côté serveur sont utilisés pour acheminer les demandes d’un client vers un instance de service disponible dans une architecture de microservice.
• Les modèles de messagerie et d’appel de procédure distante sont deux manières différentes dont les services peuvent communiquer.
• Les modèles de service unique par hôte et de services multiples par hôte sont deux stratégies de déploiement différentes.
• Modèles de préoccupations transversales: modèle de châssis de microservice et configuration externalisée
• Modèles de test: test de composant de service et test de contrat d’intégration de service
• Circuit Breaker
• Jeton d’accès
• Modèles d’observabilité:
  • Agrégation de journaux
  • Métriques d’application
  • Journalisation d’audit
  • Traçage distribué
  • Suivi des exceptions
  • API de vérification de l’état
  • Journalisation des déploiements et des modifications
• Modèles d’interface utilisateur:
  • Composition de fragments de page côté serveur
  • Composition de l’interface utilisateur côté client

Utilisations connues

La plupart des sites Web à grande échelle, y compris Netflix, Amazon et eBay, sont passés d’une architecture monolithique à une architecture de microservices.

Netflix, qui est un service de streaming vidéo très populaire qui est responsable jusqu’à 30% du trafic Internet, dispose d’une architecture à grande échelle orientée services.Ils traitent plus d’un milliard d’appels par jour vers leur API de streaming vidéo à partir de plus de 800 types d’appareils différents.Chaque API appelle les fans jusqu’à une moyenne de six Appels aux services de backend.

À l’origine, Amazon.com avait une architecture à deux niveaux. Pour évoluer, ils ont migré vers une architecture orientée services composée de centaines de services de backend. Plusieurs applications appellent ces services, y compris les applications qui implémentent le site Web Amazon.com et l’API de service Web.L’application de site Web Amazon.com appelle 100-150 services pour obtenir le données qui servaient à créer une page Web.

Le site d’enchères ebay.com a également évolué d’une architecture monolithique à une architecture orientée services.Le niveau application se compose de plusieurs applications indépendantes.Chaque application met en œuvre la logique métier pour un domaine fonctionnel spécifique tel que l’achat ou la vente.Chaque application utilise des fractionnements sur l’axe X et certaines applications telles que la recherche utilisent des fractionnements sur l’axe Z.Ebay.com applique également une combinaison de mise à l’échelle de style X, Y et Z à la base de données.

Il existe de nombreux autres exemples d’entreprises utilisant l’architecture de microservices.

Chris Richardson a des exemples d’applications basées sur des microservices.

Voir aussi

Voir mon keynote Code Freeze 2018, qui fournit une bonne introduction à l’architecture des microservices.