Les microservices en pratique: de l'architecture au déploiement – Bien choisir son serveur d impression

Les microservices sont l'un des mots à la mode les plus populaires dans le domaine de l'architecture logicielle. Il existe de nombreux supports d'apprentissage sur les principes fondamentaux et les avantages des microservices, mais il existe très peu de ressources sur la façon d'utiliser les microservices dans des scénarios d'entreprise réels. Dans cet article, je vais couvrir les concepts architecturaux clés de l'architecture des microservices (MSA) et comment vous pouvez utiliser ces principes architecturaux dans la pratique. Architecture monolithique Les applications logicielles d'entreprise sont conçues pour faciliter de nombreuses exigences commerciales; une application logicielle donnée offre des centaines de fonctionnalités et toutes ces fonctionnalités sont empilées dans une seule application monolithique. Par exemple, les ERP, les CRM et divers autres systèmes logiciels sont construits comme un monolithe avec plusieurs centaines de fonctionnalités. Le déploiement, le dépannage, la mise à l'échelle et la mise à niveau de ces applications logicielles monstrueuses est un cauchemar. L'architecture orientée services (SOA) a été conçue pour surmonter certaines des limitations susmentionnées en introduisant le concept de service, une agrégation et un regroupement de fonctionnalités similaires offertes à partir d'une application. Avec SOA, une application logicielle est conçue comme une combinaison de services à granularité grossière. Cependant, dans SOA, la portée d'un service est très large. Cela conduit à des services complexes et gigantesques avec plusieurs dizaines d'opérations (fonctionnalités), ainsi que des formats de message et des normes complexes (par exemple: toutes les normes WS *).

Architecture monolithique Dans la plupart des cas, les services SOA sont indépendants les uns des autres; pourtant, ils sont déployés dans le même runtime avec tous les autres services (pensez simplement à avoir plusieurs applications Web qui sont déployées dans la même instance Tomcat). Semblables aux applications logicielles monolithiques, ces services ont l'habitude de se développer au fil du temps en accumulant diverses fonctionnalités. Littéralement, cela transforme ces applications en globes monolithiques qui ne sont pas différents des applications monolithiques conventionnelles telles que les ERP. Le montre une application logicielle de vente au détail qui comprend plusieurs services. Tous ces services sont déployés dans le même runtime d'application. C'est donc un très bon exemple d'architecture monolithique. Voici quelques caractéristiques des applications basées sur une architecture monolithique.

Les applications monolithiques sont conçues, développées et déployées comme une seule unité. Les applications monolithiques sont extrêmement complexes; cela conduit à des cauchemars dans le maintien, la mise à niveau et l'ajout de nouvelles fonctionnalités. Il est difficile de pratiquer des méthodologies de développement et de livraison agiles avec une architecture monolithique. Il est nécessaire de redéployer l'intégralité de l'application afin d'en mettre à jour une partie. L'application doit être mise à l'échelle comme une seule unité, ce qui rend difficile la gestion des exigences de ressources conflictuelles (par exemple, un service nécessite plus de CPU, tandis que l'autre nécessite plus de mémoire) Un service instable peut faire tomber toute l'application. Il est vraiment difficile d'adopter de nouvelles technologies et de nouveaux cadres, car toutes les fonctionnalités doivent s'appuyer sur des technologies / cadres homogènes.

Architecture des microservices La base de l'architecture de microservices (MSA) consiste à développer une seule application en tant que suite de petits services indépendants qui sont exécutés dans leur propre processus, développés et déployés de manière indépendante. Dans la plupart des définitions de l'architecture des microservices, elle est expliquée comme le processus de séparation des services disponibles dans le monolithe en un ensemble de services indépendants. Cependant, à mon avis, les microservices ne consistent pas seulement à diviser les services disponibles dans monolith en services indépendants. L'idée clé est qu'en examinant les fonctionnalités offertes par le monolithe, nous pouvons identifier les capacités commerciales requises. Ces capacités commerciales peuvent ensuite être mises en œuvre en tant que (micro) services entièrement indépendants, à granularité fine et autonomes. Ils peuvent être mis en œuvre sur différentes piles technologiques et chaque service s'adresse à un domaine d'activité très spécifique et limité. Par conséquent, le scénario de système de vente au détail en ligne que nous expliquons ci-dessus peut être réalisé avec une architecture de microservices, comme illustré dans la figure ci-dessous. Avec une architecture de microservices, l'application logicielle de vente au détail est implémentée comme une suite de microservices. Ainsi, comme vous pouvez le voir ci-dessous, en fonction des besoins de l'entreprise, il existe un microservice supplémentaire créé à partir de l'ensemble de services d'origine qui se trouvent dans le monolithe. Il est donc tout à fait évident que l'utilisation de l'architecture de microservices va au-delà du fractionnement des services dans le monolithe.

Architecture de microservices Plongeons-nous dans les principes architecturaux clés des microservices et, plus important encore, concentrons-nous sur la façon dont ils peuvent être utilisés dans la pratique. Conception de microservices: taille, portée et capacités Vous pouvez créer votre application logicielle à partir de zéro en utilisant une architecture de microservices ou convertir des applications / services existants en microservices. Quoi qu'il en soit, il est très important que vous décidiez correctement de la taille, de la portée et des capacités des microservices. C'est probablement la chose la plus difficile que vous rencontrez au départ lorsque vous implémentez l'architecture des microservices dans la pratique. Voyons quelques-unes des principales préoccupations pratiques et idées fausses liées à la taille, à la portée et aux capacités des microservices.

Les lignes de code / la taille de l'équipe sont des mesures pourries: Il y a plusieurs discussions sur la décision de la taille des microservices en fonction des lignes de code de sa mise en œuvre ou de la taille de son équipe (c'est-à-dire l'équipe de deux pizzas). Cependant, ceux-ci sont considérés comme des métriques très peu pratiques et moche, car nous pouvons toujours développer des services avec moins de code / avec une taille de deux équipes de pizza mais violant totalement les principes architecturaux du microservice. "Micro" est un terme un peu trompeur: La plupart des développeurs ont tendance à penser qu'ils devraient essayer de rendre le service aussi petit que possible. C'est une idée fausse. Contexte SOA: Dans le contexte SOA, les services sont souvent implémentés sous forme de globes monolithiques avec la prise en charge de plusieurs dizaines d'opérations / fonctionnalités. Donc, avoir des services de type SOA et les renommer en microservices ne vous procurera aucun avantage de l'architecture des microservices.

Alors, comment devrions-nous concevoir correctement les services dans l'architecture des microservices? Lignes directrices pour la conception de microservices

Principe de responsabilité unique (SRP): Avoir une portée commerciale limitée et ciblée pour un microservice nous aide à répondre à l'agilité dans le développement et la prestation de services. Pendant la phase de conception des microservices, nous devons trouver leurs limites et les aligner avec les capacités métier (également appelées contexte borné dans Domain-Driven-Design). Assurez-vous que la conception des microservices assure le développement et le déploiement agiles / indépendants du service. Notre objectif devrait être la portée du microservice, mais pas la réduction du service. La taille (à droite) du service doit être la taille requise pour faciliter une capacité commerciale donnée. Contrairement au service SOA, un microservice donné doit avoir très peu d'opérations / fonctionnalités et un format de message simple. C'est souvent une bonne pratique de commencer par des limites de services relativement larges pour commencer, puis de refactoriser les plus petites (en fonction des besoins de l'entreprise) au fil du temps.

Dans notre cas d'utilisation au détail, vous pouvez constater que nous avons divisé les fonctionnalités du monolithe en quatre microservices différents, à savoir "inventaire", "comptabilité", "expédition" et "magasin". Ils s'adressent à un périmètre d'activité limité mais ciblé afin que chaque service soit complètement découplé les uns des autres et assure l'agilité dans le développement et le déploiement. Messagerie dans les microservices Dans les applications monolithiques, les fonctionnalités métier de différents processeurs / composants sont appelées à l'aide d'appels de fonction ou d'appels de méthode au niveau du langage. Dans SOA, cela a été déplacé vers une messagerie au niveau du service Web beaucoup plus faiblement couplée, qui est principalement basée sur SOAP au-dessus de différents protocoles tels que HTTP, JMS. Les services Web avec plusieurs dizaines d'opérations et schémas de messages complexes étaient une force résistive clé pour la popularité des services Web. Pour l'architecture des microservices, il est nécessaire d'avoir un mécanisme de messagerie simple et léger. Messagerie synchrone – REST, Thrift Pour la messagerie synchrone (le client attend une réponse opportune du service et attend qu'il l'obtienne) dans Microservices Architecture, REST est le choix unanime car il fournit un style de messagerie simple implémenté avec la réponse-requête HTTP, basé sur le style API de ressource. Par conséquent, la plupart des implémentations de microservices utilisent HTTP avec des styles basés sur l'API de ressources (chaque fonctionnalité est représentée avec une ressource et des opérations effectuées au-dessus de ces ressources).

Utilisation d'interfaces REST pour exposer des microservices Thrift est utilisé (dans lequel vous pouvez définir une définition d'interface pour votre microservice), comme alternative à la messagerie synchrone REST / HTTP. Messagerie asynchrone – AMQP, STOMP, MQTT Pour certains scénarios de microservices, il est nécessaire d'utiliser des techniques de messagerie asynchrone (le client n'attend pas de réponse immédiatement ou n'accepte aucune réponse du tout). Dans de tels scénarios, les protocoles de messagerie asynchrones tels que AMQP, STOMP ou MQTT sont largement utilisés. Formats des messages – JSON, XML, Thrift, ProtoBuf, Avro Décider du meilleur format de message pour les microservices est un autre facteur clé. Les applications monolithiques traditionnelles utilisent des formats binaires complexes, les applications basées sur les services SOA / Web utilisent des messages texte basés sur des formats de messages complexes (SOAP) et des schémas (xsd). Dans la plupart des applications basées sur des microservices, ils utilisent des formats de message texte simples, tels que JSON et XML, en plus du style API de ressources HTTP. Dans les cas où nous avons besoin de formats de messages binaires (les messages texte peuvent devenir verbeux dans certains cas d'utilisation), les microservices peuvent tirer parti des formats de messages binaires tels que Thrift binaire, ProtoBuf ou Avro. Contrats de service – Définition des interfaces de service – Swagger, RAML, Thrift IDL Lorsque vous avez une capacité métier implémentée en tant que service, vous devez définir et publier le contrat de service. Dans les applications monolithiques traditionnelles, nous trouvons à peine de telles fonctionnalités pour définir les capacités commerciales d'une application. Dans le monde des services SOA / Web, WSDL est utilisé pour définir le contrat de service, mais, comme nous le savons tous, WSDL n'est pas la solution idéale pour définir un contrat de microservices car WSDL est incroyablement complexe et étroitement couplé à SOAP. Puisque nous construisons des microservices au-dessus d'un style architectural REST, nous pouvons utiliser les mêmes techniques de définition d'API REST pour définir le contrat des microservices. Par conséquent, les microservices utilisent les langages de définition d'API REST standard, tels que Swagger et RAML pour définir les contrats de service. Pour d'autres implémentations de microservices qui ne sont pas basées sur HTTP / REST (telles que Thrift), nous pouvons utiliser les langages de définition d'interface (IDL) au niveau du protocole (par exemple: Thrift IDL). Intégration de microservices (communication interservices / processus) Dans l'architecture des microservices, les applications logicielles sont conçues comme une suite de services indépendants. Ainsi, afin de réaliser un cas d'utilisation métier, il est nécessaire d'avoir les structures de communication entre les différents microservices / processus. C'est pourquoi la communication interservices / processus entre microservices est un aspect si vital. Dans les implémentations SOA, la communication interservices entre les services est facilitée par un ESB (Enterprise Service Bus) et la majeure partie de la logique métier réside dans la couche intermédiaire (routage, transformation et orchestration des messages). Cependant, l'architecture des microservices permet d'éliminer le bus de messages central / ESB et de déplacer la «logique intelligente» ou la logique métier vers les services et le client (appelés Smart Endpoints). Étant donné que les microservices utilisent des protocoles standard tels que HTTP, JSON, etc., l'exigence d'intégration avec un protocole disparate est minime en ce qui concerne la communication entre les microservices. Une autre approche alternative dans la communication de microservices consiste à utiliser un bus de messages léger ou une passerelle avec des capacités de routage minimales et à agir comme un «canal muet» sans logique métier implémentée sur la passerelle. Sur la base de ces styles, plusieurs modèles de communication ont émergé dans l'architecture des microservices. Style point à point – Appel direct de services Dans un style point à point, l'intégralité de la logique de routage des messages réside sur chaque point d'extrémité et les services peuvent communiquer directement. Chaque microservice expose une API REST et un microservice donné ou un client externe peut invoquer un autre microservice via son API REST.

Communication interservices avec connectivité point à point De toute évidence, ce modèle fonctionne pour des applications basées sur des microservices relativement simples, mais à mesure que le nombre de services augmente, cela deviendra extrêmement complexe. Après tout, c'est la raison exacte pour laquelle utiliser ESB dans l'implémentation SOA traditionnelle: pour se débarrasser des liens d'intégration point à point compliqués. Essayons de résumer les principaux inconvénients du style point à point pour la communication de microservices.

Les exigences non fonctionnelles telles que l'authentification de l'utilisateur final, la limitation, la surveillance, etc. doivent être mises en œuvre à chaque niveau de microservice. Du fait de la duplication de fonctionnalités communes, chaque implémentation de microservices peut devenir complexe. Il n'y a aucun contrôle sur la communication entre les services et les clients (même pour la surveillance, le traçage ou le filtrage) Souvent, le style de communication directe est considéré comme un anti-modèle de microservice pour les implémentations de microservices à grande échelle.

Par conséquent, pour les cas d'utilisation complexes de microservices, plutôt que d'avoir une connectivité point à point ou un ESB central, nous pourrions avoir un bus de messagerie central léger qui peut fournir une couche d'abstraction pour les microservices et qui peut être utilisé pour implémenter divers non fonctionnels capacités. Ce style est appelé style API Gateway. Style de passerelle API L'idée clé derrière le style API Gateway est d'utiliser une passerelle de messages légère comme point d'entrée principal pour tous les clients / consommateurs et de mettre en œuvre les exigences non fonctionnelles communes au niveau de la passerelle. En général, une passerelle API vous permet de consommer une API gérée via REST / HTTP. Par conséquent, ici, nous pouvons exposer nos fonctionnalités commerciales qui sont implémentées en tant que microservices, via l'API-GW, en tant qu'API gérées. En fait, c'est une combinaison d'architecture de microservices et de gestion des API qui vous offre le meilleur des deux mondes.