Building microservices on Azure (Création de microservices sur Azure)Building microservices on Azure

Les microservices sont un style architectural répandu pour générer des applications résilientes, hautement scalables, capables d’évoluer rapidement et pouvant être déployées indépendamment.Microservices are a popular architectural style for building applications that are resilient, highly scalable, independently deployable, and able to evolve quickly. Mais une architecture de microservices réussie nécessite une approche différente pour concevoir et générer des applications.But a successful microservices architecture requires a different approach to designing and building applications.

Une architecture de microservices se compose d’un ensemble de petits services autonomes.A microservices architecture consists of a collection of small, autonomous services. Chaque service est autonome et doit implémenter une fonctionnalité unique.Each service is self-contained and should implement a single business capability.

Diagramme logique du style d’architecture de microservices

Que sont les microservices ?What are microservices?

  • Les microservices sont de petite taille, indépendants et faiblement couplés.Microservices are small, independent, and loosely coupled. Une équipe réduite de développeurs peut écrire un service et en assurer la maintenance.A single small team of developers can write and maintain a service.

  • Chaque service est un code base distinct, qui peut être géré par une petite équipe de développement.Each service is a separate codebase, which can be managed by a small development team.

  • Les services peuvent être déployés de manière indépendante.Services can be deployed independently. Une équipe peut mettre à jour un service existant sans avoir à recréer et redéployer l’application entière.A team can update an existing service without rebuilding and redeploying the entire application.

  • Les services sont responsables de la persistance de leurs propres données ou de leur propre état externe.Services are responsible for persisting their own data or external state. Ils se distinguent en cela du modèle traditionnel dans lequel une couche de données distincte gère la persistance des données.This differs from the traditional model, where a separate data layer handles data persistence.

  • Les services communiquent entre eux à l’aide d’API bien définies.Services communicate with each other by using well-defined APIs. Les détails de l’implémentation interne de chaque service sont cachés aux autres services.Internal implementation details of each service are hidden from other services.

  • Les services n’ont pas besoin de partager une pile de technologies, des bibliothèques ou des frameworks identiques.Services don't need to share the same technology stack, libraries, or frameworks.

Outre les services proprement dits, une architecture de microservices type est constituée d’autres composants :Besides for the services themselves, some other components appear in a typical microservices architecture:

Gestion/orchestration.Management/orchestration. Ce composant est chargé de placer les services sur des nœuds, d’identifier les défaillances, de rééquilibrer les services entre les nœuds, etc.This component is responsible for placing services on nodes, identifying failures, rebalancing services across nodes, and so forth. En général, ce composant est une technologie prête à l’emploi comme Kubernetes, plutôt qu’un élément personnalisé.Typically this component is an off-the-shelf technology such as Kubernetes, rather than something custom built.

Passerelle d’API :API Gateway. la passerelle d’API est le point d’entrée des clients.The API gateway is the entry point for clients. Au lieu d’appeler directement les services, les clients appellent la passerelle d’API, qui transfère l’appel aux services appropriés sur le back-end.Instead of calling services directly, clients call the API gateway, which forwards the call to the appropriate services on the back end.

L’utilisation de la passerelle d’API offre les avantages suivants :Advantages of using an API gateway include:

  • Il dissocie les clients des services.It decouples clients from services. Les services peuvent être versionnés ou refactorisés sans avoir à mettre à jour tous les clients.Services can be versioned or refactored without needing to update all of the clients.

  • Les services peuvent utiliser des protocoles de messagerie qui ne sont pas compatibles avec le web, comme AMQP.Services can use messaging protocols that are not web friendly, such as AMQP.

  • La passerelle d’API peut exécuter d’autres fonctions transversales, telles que l’authentification, la journalisation, la terminaison SSL et l’équilibrage de charge.The API Gateway can perform other cross-cutting functions such as authentication, logging, SSL termination, and load balancing.

AvantagesBenefits

  • Agilité.Agility. Les microservices sont déployés de manière indépendante, ce qui facilite la gestion des correctifs de bogues et des nouvelles fonctionnalités.Because microservices are deployed independently, it's easier to manage bug fixes and feature releases. Vous pouvez mettre à jour un service sans avoir à redéployer l’application entière et effectuer une restauration si une mise à jour est source de problèmes.You can update a service without redeploying the entire application, and roll back an update if something goes wrong. Dans de nombreuses applications traditionnelles, s’il existe un bogue dans une partie de l’application, il peut bloquer tout le processus de mise en production.In many traditional applications, if a bug is found in one part of the application, it can block the entire release process. Les nouvelles fonctionnalités peuvent être retardées le temps qu’une résolution de bogue soit intégrée, testée et publiée.New features may be held up waiting for a bug fix to be integrated, tested, and published.

  • Équipes spécialisées de taille restreinte.Small, focused teams. Un microservice doit être suffisamment petit pour qu’une seule équipe de fonctionnalité puisse le générer, le tester et le déployer.A microservice should be small enough that a single feature team can build, test, and deploy it. Les petites équipes favorisent une plus grande souplesse.Small team sizes promote greater agility. Les grandes équipes ont tendance à être moins productives, car la communication est plus lente, le temps de gestion augmente et l’agilité diminue.Large teams tend be less productive, because communication is slower, management overhead goes up, and agility diminishes.

  • Base de code de petite taille.Small code base. Dans une application monolithique, les dépendances de code ont tendance à s’entremêler au fil du temps. L’ajout d’une nouvelle fonctionnalité nécessite de modifier le code à beaucoup d’endroits.In a monolithic application, there is a tendency over time for code dependencies to become tangled Adding a new feature requires touching code in a lot of places. En ne partageant ni code, ni magasins de données, une architecture de microservices minimise les dépendances, ce qui facilite l’ajout de nouvelles fonctionnalités.By not sharing code or data stores, a microservices architecture minimizes dependencies, and that makes it easier to add new features.

  • Pot-pourri de technologies.Mix of technologies. Les équipes peuvent choisir la technologie qui convient le mieux à leur service à l’aide de diverses piles technologiques.Teams can pick the technology that best fits their service, using a mix of technology stacks as appropriate.

  • Isolation des erreurs :Fault isolation. Si un microservice individuel devient indisponible, il n’interrompt pas l’application toute entière, tant qu’un microservice en amont est conçus pour gérer correctement les erreurs (par exemple, en implémentant une coupure du circuit).If an individual microservice becomes unavailable, it won't disrupt the entire application, as long as any upstream microservices are designed to handle faults correctly (for example, by implementing circuit breaking).

  • Extensibilité.Scalability. Les services peuvent être mis à l’échelle de manière indépendante, ce qui permet d’effectuer un scale-out de sous-systèmes qui nécessitent plus de ressources, sans effectuer un scale-out de l’ensemble de l’application.Services can be scaled independently, letting you scale out subsystems that require more resources, without scaling out the entire application. À l’aide d’un orchestrateur comme Kubernetes ou Service Fabric, vous pouvez packager une densité plus élevée de services sur un seul hôte, ce qui permet une utilisation plus efficace des ressources.Using an orchestrator such as Kubernetes or Service Fabric, you can pack a higher density of services onto a single host, which allows for more efficient utilization of resources.

  • Isolation des données.Data isolation. Il est beaucoup plus facile d’effectuer des mises à jour de schéma, car un seul microservice est concerné.It is much easier to perform schema updates, because only a single microservice is affected. Dans une application monolithique, les mises à jour de schéma peuvent devenir très difficiles, car les différentes parties de l’application impliquer les mêmes données, d’où le risque de modifier le schéma.In a monolithic application, schema updates can become very challenging, because different parts of the application may all touch the same data, making any alterations to the schema risky.

DéfisChallenges

Les avantages des microservices ont néanmoins un prix.The benefits of microservices don't come for free. Voici certains des défis à prendre en compte avant de se lancer dans une architecture de microservices.Here are some of the challenges to consider before embarking on a microservices architecture.

  • Complexité :Complexity. une application de microservices possède plus d’éléments mobiles qu’une application monolithique équivalente.A microservices application has more moving parts than the equivalent monolithic application. Si chaque service est plus simple, le système dans son ensemble est plus complexe.Each service is simpler, but the entire system as a whole is more complex.

  • Développement et test.Development and testing. L’écriture d’un petit service qui s’appuie sur d’autres services dépendants nécessite une approche différente de celle consistant à écrire une application monolithique ou en couches traditionnelle.Writing a small service that relies on other dependent services requires a different approach than a writing a traditional monolithic or layered application. Les outils existants ne sont pas toujours conçus pour fonctionner avec des dépendances de services.Existing tools are not always designed to work with service dependencies. Refactoriser au-delà des limites des services peut être une tâche ardue.Refactoring across service boundaries can be difficult. Il est aussi difficile de tester les dépendances de services, en particulier quand l’application évolue rapidement.It is also challenging to test service dependencies, especially when the application is evolving quickly.

  • Manque de gouvernance :Lack of governance. l’approche décentralisée de création de microservices présente des avantages, mais elle peut aussi être une source de problèmes.The decentralized approach to building microservices has advantages, but it can also lead to problems. Vous pouvez en effet vous trouver face à une diversité de langages et de frameworks telle que l’application devient difficile à gérer.You may end up with so many different languages and frameworks that the application becomes hard to maintain. Il peut être utile de mettre en place certains standards à l’échelle du projet, sans trop amoindrir la flexibilité des équipes.It may be useful to put some project-wide standards in place, without overly restricting teams' flexibility. Cela vaut en particulier pour les fonctionnalités transversales, telles que la journalisation.This especially applies to cross-cutting functionality such as logging.

  • Surcharge du réseau et latence :Network congestion and latency. l’utilisation de nombreux services granulaires de petite taille peut se traduire par une intensification des communications entre les services.The use of many small, granular services can result in more interservice communication. De même, si la chaîne des dépendances de services devient trop longue (le service A appelle le service B, qui appelle le service C, etc.), la latence supplémentaire qui s’ensuit peut devenir un problème.Also, if the chain of service dependencies gets too long (service A calls B, which calls C...), the additional latency can become a problem. Vous devrez faire preuve de circonspection au moment de concevoir des API.You will need to design APIs carefully. Évitez les API trop bavardes, envisagez des formats de sérialisation et cherchez à utiliser des modèles de communication asynchrone.Avoid overly chatty APIs, think about serialization formats, and look for places to use asynchronous communication patterns.

  • Intégrité des données :Data integrity. chaque microservice étant responsable de la persistance de ses propres données,With each microservice responsible for its own data persistence. la cohérence des données peut être une gageure.As a result, data consistency can be a challenge. Adoptez la cohérence éventuelle dans la mesure du possible.Embrace eventual consistency where possible.

  • Gestion :Management. une expérience réussie avec les microservices exige une culture DevOps mature.To be successful with microservices requires a mature DevOps culture. La mise en place d’une journalisation corrélée entre les services peut poser des problèmes.Correlated logging across services can be challenging. En règle générale, la journalisation doit mettre en corrélation plusieurs appels de services pour une même opération utilisateur.Typically, logging must correlate multiple service calls for a single user operation.

  • Gestion des versions :Versioning. les mises à jour apportées à un service ne doivent pas perturber les services qui en dépendent.Updates to a service must not break services that depend on it. Plusieurs services pouvant être mis à jour à tout moment, sans une conception minutieuse, vous risquez de rencontrer des problèmes de compatibilité descendante ou ascendante.Multiple services could be updated at any given time, so without careful design, you might have problems with backward or forward compatibility.

  • Compétences :Skillset. les microservices sont des systèmes hautement distribués.Microservices are highly distributed systems. Évaluez avec soin les chances de réussite en tenant compte des compétences et de l’expérience de l’équipe.Carefully evaluate whether the team has the skills and experience to be successful.

Processus de génération d’une architecture de microservicesProcess for building a microservices architecture

Les articles listés ici présentent une approche structurée pour la conception, la génération et l’utilisation d’une architecture de microservices.The articles listed here present a structured approach for designing, building, and operating a microservices architecture.

Analyse de domaine.Domain analysis. Pour éviter certains pièges lors de la conception de microservices, utilisez l’analyse de domaine pour définir les limites de vos microservices.To avoid some common pitfalls when designing microservices, use domain analysis to define your microservice boundaries. Procédez comme suit :Follow these steps:

  1. Utilisez l’analyse de domaine pour modéliser les microservices.Use domain analysis to model microservices.
  2. Utilisez la tactique de la conception pilotée par domaine pour concevoir des microservices.Use tactical DDD to design microservices.
  3. Identifiez les limites des microservices.Identify microservice boundaries.

Concevez les services.Design the services. Les microservices requièrent une approche différente pour concevoir et générer des applications.Microservices require a different approach to designing and building applications. Pour plus d’informations, consultez Conception d’une architecture de microservices.For more information, see Designing a microservices architecture.

Utilisez-les dans un environnement de production.Operate in production. Étant donné que les architectures de microservices sont distribuées, vous devez disposer d’opérations fiables pour le déploiement et la supervision.Because microservices architectures are distributed, you must have robust operations for deployment and monitoring.