Vous êtes sur la page 1sur 59

Architecture de microservices pilotée par APIAPI-driven

Microservice Architecture
Une architecture de référence WSO2
Version Q1-2019

auteur

 Dakshitha Ratnayake, Architecte d’entreprise - CTO Office dakshitha@wso2.com

L’architecture de microservices (MSA) est une excellente approche de la création de systèmes décentralisés. Toutefois, les microservices
sont trop granulaires lorsqu’il s’agit d’architecturer des systèmes et des projets plus importants dans les friches industrielles. La plupart
des entreprises suivent une architecture en couches avec des principes d’architecture orientée services (SOA) et des concepts MSA en
regroupant les services ou microservices en couches dans l’architecture d’entreprise globale. Cette approche fait de chaque couche
d’architecture un ensemble logiquement centralisé de composants partagés.

Ce document présentera les microservices et abordera principalement l’approche en couches pour un MSA piloté par API. Il introduira
des moyens de passer progressivement d’une architecture monolithique à un MSA en couches via le modèle de passerelle API à l’aide
de l’intergiciel WSO2 et des technologies recommandées. Cet article couvrira également brièvement d’autres architectures de référence
telles que l’architecture segmentée, qui est un sous-modèle de l’architecture en couches, et l’architecture de référence alternative
connue sous le nom d’architecture basée sur les cellules. Ce document couvrira uniquement le style de communication demande-
réponse pour la communication client-microservice et un document distinct traitera du style de communication piloté par les
événements.

1.0 Introduction
À une époque où il est plus important que jamais d’offrir de superbes expériences numériques, le succès commercial réside dans
l’offre de services numériques agiles avec une grande satisfaction de la clientèle. Il doit y avoir un alignement entre la stratégie
globale de l’entreprise et les initiatives numériques poursuivies afin de transformer l’architecture opérationnelle de base en une
architecture numérique. Une architecture numérique favorise l’intégration rapide des nouvelles technologies pour alimenter la
transformation numérique. Pour élaborer, une architecture numérique est composée d’une pile de couches qui soutiennent la
chaîne de valeur de l’entreprise. La couche technologique, qui englobe l’application, la gestion des API, la sécurité, l’analyse,
l’intégration, les couches de services et de données et l’infrastructure de base, sous-tend tout cela.
Figure 1 : architecture numérique typique

Une architecture de microservices (MSA) est une méthode de développement d’applications logicielles en les créant sous forme de
collections de services indépendants et modulaires. Les microservices peuvent être déployés pour créer une architecture numérique
plus flexible. Les petites équipes peuvent travailler séparément sur ces microservices et les partager avec d’autres développeurs
d’applications via des API pour les réutiliser. En fait, ces services individuels peuvent être publiés, mis à l’échelle et mis à jour sans
impact sur le reste du système. Lorsqu’il est associé à un environnement conteneurisé, MSA est l’option idéale pour les entreprises
qui doivent fournir et évoluer rapidement et permettre la prise en charge d’une gamme de plates-formes et d’appareils. Lors de
l’adoption d’un MSA, ses microservices constitutifs peuvent être classés en plusieurs types et sous-types.

Dans le même temps, la plupart des organisations ne sont pas tout à fait prêtes à adopter un MSA pur. Même si une approche MSA
est suivie pour le développement plus récent, de nombreux systèmes conventionnels, tels que les systèmes SOA, Enterprise Service
Bus (ESB), les applications PaaS/SaaS et tout autre déploiement vertical monolithique d’applications héritées, continueront de faire
partie de la topologie globale d’une entreprise. Ces systèmes de friches industrielles ne peuvent pas être ignorés et devront être
accessibles par les microservices (au moins pendant la période de transition). Ces systèmes et services devront être exposés via des
API gérées pour un accès interne et externe transparent.

En tenant compte des faits ci-dessus, la vue holistique d’une architecture numérique compatible MSA peut être divisée en trois
zones comme indiqué ci-dessous :

 Zone 1 : Architecture interne


 Zone 2 : Architecture extérieure
 Zone 3 : Architecture externe
Architecture Microservices principaux : microservices qui contiennent uniquement des services de logique métier et de
interne données.
Architecture Microservices utilitaires : inclut les microservices d’intégration, les micro passerelles, les services d’émission
externe de jeton de sécurité, les micro-courtiers ou tout autre micro-runtime.

Architecture Applications des utilisateurs finaux, systèmes et données hérités, applications SaaS, systèmes partenaires,
externe etc.

Tableau 1 : zones d’architecture MSA

Par conséquent, une architecture numérique compatible MSA ressemblera étroitement à l’architecture illustrée à la figure 2 ci-
dessous.
Figure 2 : architecture numérique compatible MSA

À cette fin, ce document expliquera comment réaliser une architecture numérique compatible MSA. Il mettra également en évidence
les meilleures pratiques d’adoption d’une architecture de microservices basée sur les API afin de créer une architecture numérique
de manière itérative, qu’il s’agisse d’une nouvelle architecture ou d’une friches industrielles, et comment la pile de produits WSO2 et
ses dérivés peuvent aider à atteindre ces objectifs MSA.

2.0 Architecture de microservices (MSA)

2.1 Principales caractéristiques


MSA est un modèle d’architecture d’application dans lequel une application volumineuse est décomposée en de nombreux
microservices faiblement couplés. L’objectif des microservices est de décomposer suffisamment l’application afin de faciliter le
développement et le déploiement d’applications agiles.

Contrairement à une application monolithique plus classique, dans laquelle tout est étroitement couplé et déployé comme un seul
gros morceau, une architecture de microservice tente de découpler tous les modules, où chaque service a sa propre portée unique
et bien définie et s’exécute dans son propre processus. Chaque microservice doit idéalement posséder une seule responsabilité. En
permettant aux petites équipes autonomes de développer, déployer et mettre à l’échelle leurs services respectifs de manière
indépendante, les microservices permettent un développement parallèle, accélérant ainsi considérablement le cycle de production.

MSA est une évolution de l’architecture orientée services (SOA) et l’adoption d’une MSA est étroitement corrélée avec l’utilisation de
DevOps et l’intégration continue et la livraison continue (CI / CD). Le SOA classique est souvent implémenté à l’intérieur de
monolithes de déploiement et est davantage axé sur la plateforme, tandis que les microservices doivent être déployables
indépendamment et offrent donc plus de flexibilité dans toutes les dimensions. Les microservices natifs du cloud (microservices qui
exploitent les avantages du cloud computing, de l’empaquetage de conteneurs et de la gestion dynamique) amenent le concept
SOA à un nouveau niveau où l’infrastructure cloud permet aux services d’être implémentés et gérés à grande échelle. Docker et
Kubernetes fournissant des moyens efficaces de développer, déployer et gérer des microservices, les développeurs peuvent lancer
d’innombrables services en même temps, surveiller les services et fournir à chaque service les ressources dont il a besoin. Chaque
microservice peut être déployé, mis à niveau, mis à l’échelle et redémarré indépendamment de tous les services frères de
l’application.
Figure 3 : architecture monolithique et architecture de microservices

2.2 Architecture de microservices : avantages et inconvénients


Avantages

 Les services individuels sont beaucoup plus rapides à développer, tester et déployer, et beaucoup plus faciles à comprendre
et à gérer. Ils sont réutilisables aussi.
 Chaque service est développé indépendamment par une équipe qui se concentre sur ce service et qui est libre de choisir les
technologies qui ont du sens. Les développeurs ont rarement besoin de coordonner le déploiement des modifications qui
sont locales à leur service. Ces types de modifications peuvent être déployés dès qu’elles ont été testées.
 MSA permet la livraison et le déploiement continus d’applications volumineuses et complexes.
 MSA permet à chaque service d’être mis à l’échelle indépendamment. Les développeurs peuvent déployer uniquement le
nombre d’instances de chaque service qui répondent à ses contraintes de capacité et de disponibilité. En outre, ils peuvent
utiliser une infrastructure de déploiement optimisée qui correspond le mieux aux besoins en ressources d’un service.
 MSA crée une isolation améliorée des pannes. Par exemple, s’il existe une fuite de mémoire dans un service, seul ce service
sera affecté. Les autres services continueront à traiter les demandes. En comparaison, un composant qui se comporte mal
d’une architecture monolithique peut faire tomber l’ensemble du système.

Inconvénients

Comme toutes les autres technologies, l’architecture de microservices présente des inconvénients et n’est pas une solution miracle.
Voici une liste de quelques inconvénients.

 La décomposition des données et leur traitement en microservices indépendants peuvent augmenter la complexité de la
conception.
o Une application cliente doit connaître plusieurs points de terminaison pour exécuter une fonction significative et
chaque microservice doit connaître au moins un ou deux autres microservices, par exemple comment interagir,
adresses IP, etc.
o Les développeurs doivent faire la différence entre les microservices internes et externes et implémenter le mécanisme
de communication interservices entre ces types. En outre, la découverte de services côté client et côté serveur est
cruciale.
o Les développeurs doivent également écrire du code pour gérer l’échec partiel, car la destination d’une demande peut
être lente ou indisponible. Ils doivent également gérer les transactions distribuées pour implémenter des cas
d’utilisation qui s’étendent sur plusieurs services.
 Les applications clientes auront du mal à consommer les services en raison des variations dans les interfaces et les protocoles
de sécurité dues aux différentes équipes implémentant les microservices.
 Les microservices entraînent davantage d’appels réseau et, par conséquent, un monolithe étant donné que le même matériel
fonctionne généralement mieux.
 Les outils de développement/IDE sont orientés sur la création d’applications monolithiques et ne fournissent pas de prise en
charge explicite du développement d’applications distribuées.

2.3 Mise en œuvre de l’indemnité de services de sécurité


Malgré la complexité des microservices, ils constituent généralement un bon choix pour le développement rapide d’applications
piloté par les consommateurs et ils aident à définir des limites de fonctionnalité claires et des équipes auto-organisées. Ils créent un
développement durable, favorisant ainsi l’agilité. Cela signifie un développement collaboratif, une expédition fréquente et un
engagement fréquent avec le client. Chaque domaine fonctionnel d’une application est implémenté par son propre microservice. Les
développeurs peuvent commencer par décomposer l’application en microservices par capacité métier, cas d’utilisation ou verbe, par
exemple expédition, ou par noms ou ressources, par exemple commandes. Idéalement, chaque service devrait avoir une seule
responsabilité ou seulement un petit ensemble de responsabilités.
Pour la communication inter-processus, les microservices peuvent utiliser des mécanismes de communication synchrones basés sur
la demande/réponse tels que REST, Thrift ou gRPC basé sur HTTP. Vous pouvez également utiliser un mécanisme de communication
asynchrone basé sur des messages tel que AMQP, MQTT ou STOMP. Un format de message tel que JSON ou XML, qui sont lisibles
par l’homme, ou un format binaire tel qu’Avro ou Protocol Buffers peut être sélectionné. Afin de garantir un couplage lâche, chaque
service doit avoir sa propre base de données plutôt que de partager une base de données unique avec d’autres services.

Les microservices peuvent être implémentés dans n’importe quel langage de programmation qui prend en charge les services REST
et RPC. Ce document se concentrera sur le langage de programmation Ballerina en particulier. Ballerina est un langage de
programmation compilé, transactionnel, statiquement et fortement typé avec des syntaxes textuelles et graphiques qui peuvent être
utilisées pour implémenter des microservices. Ballerina intègre des concepts fondamentaux de l’intégration de systèmes distribués
dans le langage et offre un environnement simultané de type sécurisé pour implémenter des microservices avec des transactions
distribuées, une messagerie fiable, un traitement de flux et des flux de travail.

Une fois les microservices définis et implémentés, ils doivent être conteneurisés. Docker est la technologie préférée pour
l’empaquetage de microservices et est une technologie clé pour les microservices. Les déploiements immuables rapides,
l’optimisation de l’utilisation des ressources et les performances bare-metal sont quelques-uns des avantages de l’utilisation de
Docker. Les conteneurs Docker doivent être orchestrés dynamiquement à l’aide d’un gestionnaire de cluster de conteneurs
indépendant du cloud, tel que Kubernetes.The Docker containers should be dynamically orchestrated using a cloud-agnostic
container cluster manager, such as Kubernetes. Les développeurs peuvent déployer et mettre à l’échelle indépendamment chaque
microservice, coordonner leur déploiement via l’orchestration Kubernetes et collaborer entre les équipes tout en incluant des outils
de gestion des services et d’observation des déploiements.

2.4 Communication client-microservice


Figure 4 : architecture de microservices : exemple

Les microservices sont affinés, ce qui signifie que les clients doivent interagir avec plusieurs microservices. Dans l’application de
vente au détail de la figure 4, l’application cliente consomme directement plusieurs microservices. Si l’application cliente souhaite
répertorier les produits disponibles, elle appellera le microservice products, et si elle souhaite passer une commande, elle appellera
le microservice orders. Lorsqu’une commande est passée, le microservice de commandes doit vérifier l’état du stock de produits à
partir du service d’inventaire et parler au microservice d’expédition pour démarrer le processus d’expédition. En théorie, le client
peut effectuer des demandes à chacun des microservices directement, car chaque microservice a un point de terminaison public.
Toutefois, cette approche entraînera des problèmes ultérieurs considérables tels que les suivants :

 Il introduit le gâchis spaghetti point à point que SOA a essayé d’éliminer avec l’utilisation d’un Bus de service d’entreprise.
 S’il existe des incompatibilités entre les besoins du client et les API affinées exposées par chacun des microservices, le client
devra effectuer plusieurs appels pour obtenir ce dont il a besoin. Dans une application complexe, cela peut signifier des
centaines d’appels de service.
 Utilisation de services via des interfaces et des protocoles non uniformes Un service peut utiliser le protocole RPC binaire
Thrift tandis qu’un autre service peut utiliser le protocole de messagerie AMQP. Aucun des deux protocoles n’est
particulièrement convivial pour le navigateur ou le pare-feu et est mieux utilisé en interne. Une application doit utiliser des
protocoles tels que HTTP et WebSocket en dehors du pare-feu.
 La refactorisation des microservices sera difficile. Au fil du temps, les microservices devront être refactorisés. Par exemple,
modifiez la façon dont le système est partitionné en services. Si les clients communiquent directement avec les services, il
peut être extrêmement difficile d’effectuer ce type de refactorisation.
 L’implémentation de l’authentification, de l’autorisation, de la limitation, de la mise en cache et de la surveillance pour chaque
microservice crée une duplication et n’est pas nécessaire.

En raison de ces types de problèmes, il est rarement logique que les clients parlent directement aux microservices. Lors de la
conception et de la création d’applications basées sur des microservices volumineuses ou complexes, une bonne approche à
prendre en compte est une passerelle API.
2.4.1 Modèle API Gateway

2.4.1.1 Passerelle API

L’implémentation d’une passerelle API en tant que point d’entrée unique pour tous les clients résout les problèmes rencontrés dans
la communication directe client-microservice.
Figure 5 : architecture de microservice : modèle API Gateway

Dans le modèle de passerelle API, toutes les demandes des clients passent d’abord par des API bien définies dans une passerelle de
message légère (également alias passerelle API) via REST/HTTP. Ces API acheminent les demandes vers les microservices appropriés.
La passerelle est principalement responsable du routage des demandes, de la composition et de la traduction du protocole. Les API
de passerelle API gèrent souvent une seule demande en appelant plusieurs microservices et en agrégeant les résultats.

Fondamentalement, une passerelle API permet aux développeurs de consommer facilement des microservices en tant qu’API gérées
et fait généralement partie d’une offre de gestion des API. Une plateforme de gestion des API doit fournir des moyens d’intégrer et
de gérer les développeurs, de créer un catalogue et une documentation d’API, de générer des rapports d’utilisation des API, de
produire ou de monétiser les API et d’appliquer la limitation, la mise en cache et d’autres précautions de sécurité et de fiabilité.
Cette plateforme fournit les outils, le contrôle et la visibilité nécessaires pour mettre à l’échelle les microservices via des API aux
nouveaux développeurs et les connecter à de nouveaux systèmes.

Passerelle API : modèle de solution WSO2


Figure 6 : Greenfield MSA : modèle de passerelle API avec WSO2 API Manager

Wso2 API Manager, récemment nommé leader dans le rapport Forrester Wave™: API Management Solutions, Q4 2018, est une
solution de gestion d’API open source qui fournit une passerelle API avec prise en charge de la création, de la publication, de la
gestion du cycle de vie, du contrôle de vie, du contrôle de version, de la monétisation, de la gouvernance, de la sécurité, de la
limitation de débit et de l’analyse à l’aide de la technologie WSO2 éprouvée. Il fournit des interfaces Web permettant aux équipes
de développement de déployer et de surveiller des API, et aux consommateurs de s’abonner, de découvrir et de consommer des API
via une vitrine conviviale. API Manager se compose de plusieurs composants : API Gateway, Key Manager, Traffic Manager, Publisher
Portal, Developer Portal (Store) et Analytics. Selon le cas d’usage et les volumes de trafic, ces composants peuvent être déployés
dans un seul runtime ou en tant que runtimes distincts.

Certains projets de microservices seraient des réécritures complètes de tous les composants ou simplement de la couche de
services. Dans de tels cas, les développeurs ont le luxe de sélectionner la pile technologique pour adopter le modèle MSA. La
logique métier peut être écrite en tant que microservices Ballerina. Les microservices peuvent être directement exposés aux
applications clientes via WSO2 API Manager Gateway.The microservices can be directly exposed to client applications via WSO2 API
Manager Gateway. La passerelle peut sécuriser les microservices en utilisant une combinaison d’OAuth2/OIDC à la périphérie et en
envoyant des informations aux microservices via des jetons Web Java (JWT). Le Gestionnaire de clés peut gérer la génération et la
validation de ces jetons de sécurité. WSO2 API Manager fournira également d’autres fonctionnalités de gestion des API telles que la
documentation, la découverte de service via le portail des développeurs et l’analyse des API exposées. WSO2 API Manager peut être
déployé en tant que passerelle API, comme illustré à la figure 6 ci-dessus. Le profil WSO2 API Analytics est toujours déployé en tant
qu’exécution distincte.

2.4.1.2 Orchestration de microservices

L’implémentation de microservices et leur exposition via une couche API Gateway semblent être un choix approprié lorsqu’il s’agit
d’implémenter un MSA vierge. Même si la popularité des microservices augmente de jour en jour, cela ne signifie pas que les
applications monolithiques sont obsolètes. Il existe des applications qui conviennent toujours à une architecture monolithique et,
par conséquent, les friches industrielles continueront d’exister. Ainsi, dans la plupart des scénarios de greenfield et de friches
industrielles et avec l’évolution des besoins de l’entreprise, qui nécessitera une intégration intensive de plusieurs microservices et
d’autres systèmes hérités, la passerelle API seule ne suffira pas. Les fonctionnalités d’un Bus des services d’entreprise dans un SOA,
telles que le routage des messages, les compositions/chaînages de services, les transformations de protocole et de format de
message, l’implémentation de modèles de résilience et divers autres modèles d’intégration d’entreprise (EEP), sont toujours requises
dans un MSA pour créer une expérience cohérente. Comment ces capacités doivent-elles être absorbées dans un MSA ?

Microservices d’intégration

Dans un SOA typique, les services composites virtuels sont exposés à partir d’une couche ESB pour intégrer plusieurs services et
d’autres systèmes. L’ESB est utilisé comme bus centralisé qui connecte tous ces services et systèmes. Cependant, il s’agit d’un anti-
modèle dans MSA car tout système qui nécessite beaucoup de gestion centrale peut devenir problématique comme avec n’importe
quel monolithe. La logique est intégrée dans le tuyau, augmentant ainsi le couplage dans le système. En outre, en raison de ses
incompatibilités fondamentales, l’ESB n’est pas en mesure de s’intégrer dans un accord de services de sécurité.

Comme alternative à un ESB centralisé, l’implémentation de microservices d’intégration est la meilleure option d’un point de vue
MSA. Dans cette approche, les services d’intégration ou composites seront hébergés en tant que deuxième couche de microservices.
Ces services doivent souvent prendre en charge les fonctionnalités ESB telles que le routage, les transformations, l’orchestration, la
résilience et les modèles de stabilité. Si nous prenons l’exemple de l’application de vente au détail, nous pouvons créer un
microservice d’intégration qui consomme les commandes et les microservices d’expédition comme indiqué ci-dessous.
Contrairement à l’approche ESB monolithique, toutes les fonctionnalités ESB/intégration sont séparées et dispersées entre tous les
microservices d’intégration.
Figure 7 - Architecture de microservices : microservices d’intégration

WSO2 a mis au jour deux façons d’implémenter ces microservices d’intégration.

Pour une approche de configuration, un runtime ESB moderne compatible avec les microservices appelé WSO2 Micro Integrator
peut être utilisé. WSO2 Micro Integrator est un runtime léger construit à l’aide de la même technologie que wso2 Enterprise Service
Bus. La logique est rédigée en XML. Divers modèles d’intégration d’entreprise peuvent être implémentés et de nombreuses autres
applications peuvent être connectées via des connecteurs.

D’autre part, Ballerina est un langage de programmation et une plate-forme qui vise à combler le fossé entre les produits
d’intégration et les langages de programmation à usage général. Ballerina facilite la création de microservices qui s’intègrent et
orchestrent sur des points de terminaison distribués. Il tente de fournir simultanément agilité et simplicité d’intégration et il y
parvient en empaquetant un langage, une syntaxe d’intégration et des constructions de déploiement environnemental dans un
fichier de code unique qui est compilé dans un fichier binaire, exécutable au sein d’une machine virtuelle, puis intégré à la chaîne
d’outils d’un développeur avec des serveurs de langage IntelliSense et des débogueurs pour les IDE.

Microservices d’intégration : modèle de solution WSO2


Figure 8 : architecture de microservices : microservices d’intégration avec Ballerina ou WSO2 Micro Integrator

Comme le montre la figure 8, la logique métier et la logique d’intégration peuvent être écrites en tant que microservices et
résideront dans des runtimes distincts. Les services d’intégration, qui intègrent les microservices, peuvent être exposés aux
applications clientes via la passerelle. Ballerina peut être utilisé pour écrire ces microservices d’intégration. Dans le même temps, le
micro-intégrateur WSO2 peut également être utilisé pour écrire la logique d’intégration à l’aide de l’approche de configuration.

2.4.1.3 Portes d’entrée décentralisées

Les passerelles décentralisées sont extrêmement utiles lorsqu’il s’agit de mise à l’échelle. Par exemple, supposons un scénario où
plusieurs instances des microservices de produits sont requises, mais que seules une ou quelques instances des microservices de
commandes sont nécessaires. Il s’agit d’un scénario réaliste où de nombreuses demandes seront reçues par un ensemble particulier
de microservices, tels que le microservice de produits (pour parcourir le catalogue de produits), mais pas autant de demandes
seront reçues par le microservice de commandes (pour passer des commandes). Imaginez une architecture de passerelle API
monolithe unique où toutes les API résident sur la passerelle monolithe et les microservices derrière cette passerelle API. Pour
mettre à l’échelle le microservice de produits, la passerelle monolithe devra également être mise à l’échelle. La mise à l’échelle d’une
partie du système entraîne une mise à l’échelle de l’ensemble du déploiement de la passerelle. Pour éviter une telle situation, une
passerelle décentralisée est une bonne option où il existe une microgate par microservice. Chaque fois qu’un microservice doit être
mis à l’échelle, seule la passerelle qui l’utilise sera mise à l’échelle avec le microservice.
Figure 9 : architecture de microservices : passerelles décentralisées

Passerelles décentralisées : modèle de solution WSO2

WSO2 API Microgateway est une passerelle API immuable, éphémère et légère. La microgateway est utilisée pour la sécurité des
messages, la sécurité du transport, le routage et d’autres services de gestion d’API courants. La microgate WSO2 est conçue pour
évoluer, où elle ne nécessite aucune connexion obligatoire à d’autres composants, tels que le gestionnaire de clés, l’analyse, le
gestionnaire de trafic, etc., comme cela se fait avec le gestionnaire d’API WSO2 monolithique standard. De cette façon, il peut être
mis à l’échelle facilement sans avoir à se soucier de la mise à l’échelle des autres composants. Ceci est réalisé grâce à des jetons
d’auto-validation, à la limitation de débit localisée, à l’analyse hors ligne et à l’immuabilité. La microgateway a une prise en charge
native de Docker et Kubernetes, et les développeurs peuvent obtenir des images Docker et des artefacts Kubernetes en tant que
résultat de génération d’une microgateway.
Figure 10 : architecture de microservices : passerelles décentralisées avec microgateways WSO2

Dans la figure 10, l’approche de passerelle désagrégée est suivie, où chaque passerelle est une instance de la microgateway WSO2
et une seule passerelle indépendante peut faire face à chaque microservice ou service d’intégration. Les API de passerelle doivent
être définies dans WSO2 API Manager avec les informations d’API, les points de terminaison cibles, etc. Une boîte à outils de
microgateway, lorsqu’elle est exécutée avec certains paramètres, se connecte au gestionnaire d’API, télécharge les définitions et les
stratégies des API dans la boîte à outils et fait tourner une instance de microgateway. Par exemple, si une microgate doit être créée
pour le microservice products, une API products doit d’abord être définie et publiée dans le gestionnaire d’API via les portails
Publisher et Store respectivement. La boîte à outils téléchargera la définition de l’API des produits et toutes les stratégies qui lui sont
associées et générera le runtime de microgateway pour l’API des produits. Vous pouvez également fournir une définition d’API
(fichier Swagger) au lieu de créer les API dans API Manager. La taille du runtime, l’heure de démarrage, la mémoire, l’espace disque
peuvent être définis. Ce runtime peut s’exécuter sur une machine virtuelle ou un conteneur Docker.This runtime can run on a virtual
machine or a Docker container.

La microgateway prend en charge le flux OAuth2 standard, où une application cliente obtiendra d’abord un jeton JWT signé émis
par le service d’émission de jeton de sécurité (STS), qui peut être le Gestionnaire de clés du Gestionnaire d’API WSO2 ou de tout
autre STS. Lorsque l’application cliente envoie le JWT signé à la microgateway, la microgateway peut auto-valider le jeton car le STS
est approuvé par la microgateway. Dans ce scénario particulier, la microgateway n’a aucun lien avec le gestionnaire de clés. Si la
microgate doit être mise à l’échelle, cela peut être fait sans avoir à mettre à l’échelle le STS. Pour l’analyse, les méta-informations des
demandes d’API sont enregistrées dans des fichiers de données résidant dans le système de fichiers local de la microgateway
(partagé ou privé). Par la suite, ces fichiers seront téléchargés périodiquement sur le serveur API Analytics (ce processus peut
s’exécuter dans le processus de passerelle lui-même ou dans un processus distinct). Le serveur API Analytics analysera les données
brutes et générera une aide à la décision. Pour la gestion du trafic, des stratégies de limitation de débit sont intégrées dans
l’exécution de microgateway.

2.4.1.4 Passerelles API vs maillages de services

L’une des questions fréquemment posées concernant la passerelle API est en quoi elle est différente d’un maillage de service. Un
maillage de service gère les interactions de microservice à microservice et est utilisé pour un routage compliqué. Il peut effectuer
des tâches telles que l’équilibrage de charge, l’authentification du service, la découverte de service, le routage et l’application des
stratégies. Un maillage de service peut également fournir des informations détaillées sur l’environnement de microservices,
contrôler le trafic, implémenter la sécurité et appliquer des stratégies pour tous les services au sein du maillage. Deux composants
logiques créent un maillage de service : un plan de données et un plan de contrôle. Le sidecar, qui est un proxy pour le microservice,
tombe sous le plan de données. Outre les proxys sidecar, toutes les solutions de maillage de services ont un contrôleur (plan de
contrôle), qui définit le fonctionnement des proxys sidecar. Le plan de contrôle de maillage de service est l’endroit central pour
gérer les proxys de service et il enregistre beaucoup d’informations réseau.

Istio est la plate-forme de maillage de services la plus populaire et la plus complète sur le marché au moment de la rédaction de cet
article. En utilisant le modèle sidecar, Istio s’exécute dans un conteneur Linux dans les pods Kubernetes et injecte et extrait des
fonctionnalités et des informations en fonction de la configuration du contrôleur. Cette configuration vit en dehors du code du
microservice et rend donc le code petit et simple en éloignant les aspects opérationnels du développement de code.
Figure 11 : plan de contrôle et plan de données dans un maillage de service

Même si la passerelle API et le maillage de services ont des fonctionnalités qui se chevauchent, la principale différence entre elles est
que la passerelle API est fondamentale pour exposer les microservices en tant qu’API gérées à des parties externes (en dehors du
MSA), tandis que le maillage de services est simplement une infrastructure de communication inter-services qui n’a aucune notion
métier de l’ensemble de la solution. Les maillages de service dans leur forme native ont une lacune de gestion des API qui doit être
comblée. Ceux-ci sont liés à l’exposition de services à des consommateurs externes (sécurité avancée, découverte, gouvernance,
etc.), à des informations commerciales, à l’application des stratégies et à la monétisation.

Le maillage de services et la passerelle API sont complémentaires de sorte qu’ils vivent à des niveaux différents et résolvent des
problèmes différents. Ils peuvent exister indépendamment mais coexister de manière complémentaire.
Figure 12 : adaptateur istio mixer pour WSO2 API Manager

WSO2 API Manager peut être positionné pour s’intégrer à Istio et gérer les microservices déployés dans Istio en tant qu’API via
l’adaptateur de mélangeur Istio pour WSO2 API Manager. WSO2 API Manager va au-delà et fournit des fonctionnalités
commerciales plus larges telles que la conception, la publication, la documentation, l’analyse et la monétisation des API dans un
environnement sécurisé.

L’adaptateur de mélangeur Istio pour WSO2 API Manager peut sécuriser les services à l’aide de jetons JWT et OAuth2, valider les
abonnements et les étendues, utiliser WSO2 API Manager Analytics pour des informations commerciales et bien plus encore.

3.0 Architecture de microservices - Architectures de référence

3.1 Architecture de microservices en couches


La plupart des entreprises suivent une architecture en couches avec les principes SOA et les concepts MSA en regroupant les
services ou les microservices en couches dans l’architecture d’entreprise globale. Cette approche fait de chaque couche
d’architecture un ensemble logiquement centralisé de composants partagés.
Figure 13 : architecture en couches de microservices

Dans ce modèle MSA, les capacités fonctionnelles sont regroupées en couches en suivant une vue système de systèmes. Il s’agit
d’un système centralisé où les données se déplacent d’une couche à l’autre. Avec la couche de passerelle également désagrégée, un
MSA pur peut être mis en application avec différents types de services qui peuvent être classés en quelques couches différentes
comme indiqué dans Figure 13 ci-dessus.

Les microservices core/atomic sont placés dans la couche inférieure. Il s’agit de services autonomes extrêmement affinés (sans
dépendances de service externe) comprenant la logique métier avec peu ou pas de logique de communication réseau.

Les microservices composites/d’intégration gèrent la composition de plusieurs services atomiques/principaux et la couche


intermédiaire se compose de ces microservices composites ou d’intégration. Ces services doivent souvent prendre en charge une
partie importante des fonctionnalités ESB telles que le routage, les transformations, l’orchestration, la résilience et les modèles de
stabilité. Ils sont plus grossiers que les services atomiques et indépendants les uns des autres. Ils contiennent une logique de
routage, une logique de mappage de données et une logique de communication réseau qui gère la communication interservices via
divers protocoles et comportements de résilience tels que les disjoncteurs. Ces services pourraient également relier les autres
systèmes hérités et propriétaires (par exemple SAP ERP), les API Web externes (par exemple Salesforce) et les bases de données
partagées (souvent connues sous le nom de couche anti-corruption).

Les microservices API/Edge sont le troisième type de microservices et les plus importants dans une architecture en couches. Les
services composites ou même certains services atomiques peuvent être exposés en tant qu’API managées à l’aide de services
API/Edge. Ces services sont un type spécial de services composites qui appliquent des fonctionnalités de routage de base, le
contrôle de version, les modèles de sécurité des API, la limitation, la monétisation, etc.

3.1.1 Architecture en couches avec WSO2 : un déploiement en terrain vierge


Figure 14 : architecture en couches de microservices avec la pile technologique WSO2

La gestion des microservices est gérée par WSO2 API Microgateway, qui fournit un accès sécurisé et à faible latence aux
microservices et élimine le besoin d’une passerelle centrale en permettant aux entreprises d’appliquer des stratégies de gestion des
API de manière décentralisée. L’intégration des microservices est optimisée à l’aide de Ballerina ou de WSO2 Micro Integrator. En
plus du gestionnaire de clés du gestionnaire d’API, qui s’occupe de la génération et de la validation des jetons, le serveur d’identité
WSO2 peut être utilisé pour la fédération d’identité, l’authentification unique, le pontage d’identité, l’authentification adaptative et
forte, ainsi que la gestion des comptes et l’approvisionnement d’identité en tant que composant transversal du MSA.

3.1.2 Architecture en couches avec WSO2 : déploiement de friches industrielles

La plupart des projets de microservices sont implémentés dans des environnements de friches industrielles qui ont déjà des services
hérités, cloud et autres, un environnement ESB, etc. Dans un tel scénario, une réécriture complète est généralement coûteuse. Une
approche typique consiste à mettre en œuvre des services plus récents en tant que microservices et une architecture en couches
distincte (microservices d’intégration et microgateways ainsi que les microservices principaux) sera formée tandis que
l’environnement SOA existant (services Web, API, systèmes hérités et couche ESB) restera tel quel. L’ESB continuera d’intégrer
plusieurs services et d’autres systèmes et sera utilisé comme bus centralisé qui relie tous ces services et systèmes en dehors de la
MSA. Ces points de terminaison sur l’ESB seront exposés aux applications clientes via la passerelle API centralisée où ils seront
sécurisés, limités et surveillés.
Figure 15 - Architecture en couches MSA et SOA dans la coexistence avec la pile WSO2

Dans l’architecture ci-dessus, un MSA en couches coexiste également avec le SOA. De nouvelles fonctionnalités peuvent être
implémentées dans le MSA et les services et applications existants dans le SOA peuvent résider en l’état.

3.1.2.1 Transition d’un monolithe à une architecture de microservices

L’un des avantages de l’introduction d’une passerelle vers un MSA est la possibilité de passer en douceur et en continu d’une
application monolithique à un MSA. La réécriture d’une grande application monolithique à partir de zéro est un effort massif et
comporte une bonne quantité de risques associés. Cela empêche également les utilisateurs d’utiliser le nouveau système jusqu’à ce
qu’il soit terminé. Il y aura beaucoup d’incertitude jusqu’à ce que le nouveau système soit mis au point et fonctionne comme prévu.
Par conséquent, il y aura des améliorations minimales ou de nouvelles fonctionnalités fournies sur la plate-forme actuelle, de sorte
que l’entreprise devra attendre que de nouvelles fonctionnalités soient développées et publiées. Cette tâche devra, le plus souvent,
être progressivement supprimée.

Connu sous le nom de modèle d’étranglement, il s’agit d’un modèle de conception pour transformer de manière incrémentielle le
monolithe en microservices en remplaçant une fonctionnalité particulière par un nouveau service. Une fois que la nouvelle
fonctionnalité est prête, l’ancien composant est étranglé, le nouveau service est mis en service et, enfin, l’ancien composant est
complètement mis hors service. Cependant, lors de l’élimination progressive, il y a de fortes chances qu’il y ait beaucoup de
changements. Les interfaces de microservice changeront et cela au fil du temps entraînera un cauchemar pour les applications
consommatrices. Pour rendre les applications clientes indépendantes de ces modifications fréquentes, la passerelle API peut être
utilisée comme façade strangler.
Figure 16 : architecture de microservice : façade d’étranglement dans le modèle d’étranglement

En tant que Strangler Facade, la passerelle API agira comme une couche proxy avec des interfaces statiques ou bien définies
correspondant aux microservices principaux. Les modifications ultérieures dans les microservices n’affecteront pas les applications
clientes, car elles ne traiteront que la couche de passerelle API.

3.2 Architecture de microservices segmentée


L’architecture segmentée est un sous-modèle de l’architecture en couches, qui est créée en divisant l’architecture en couches en
petits segments en fonction des capacités fonctionnelles de chaque couche d’architecture et de la propriété organisationnelle. Il
s’agit également d’un système centralisé où le flux de données se déplace d’une couche à l’autre. Ce modèle sépare les couches de
chaque subdivision et rend la subdivision responsable de sa fonctionnalité globale à chaque couche.
Figure 17 : architecture segmentée MSA

3.2.1 Architecture de microservice segmentée avec WSO2


Figure 18 - Architecture segmentée MSA avec pile de technologie WSO2

Semblable à l’architecture en couches, les composants WSO2 peuvent être utilisés de manière en couches avec la gestion
transversale des identités et des accès avec WSO2 Identity Server. Chaque couche sera désormais segmentée pour répondre aux
besoins de l’entreprise et pourra être implémentée séparément.

3.3 Architecture de microservices basée sur les cellules


(Cette section est basée sur le document Cell-based Reference Architecture [13]. Une lecture préalable est recommandée.)

Une architecture segmentée est trop élevée pour appliquer une unité d’architecture décentralisée et autonome. En même temps, les
microservices sont généralement trop précis pour être traités comme une unité d’architecture. Dans une architecture basée sur des
cellules, les fonctionnalités sont regroupées dans une unité d’architecture, appelée cellule, en fonction de la portée et de la
propriété. Une cellule est déployable indépendamment, gérable et observable. Les composants à l’intérieur de la cellule peuvent
communiquer entre eux à l’aide de transports pris en charge pour la communication intracellulaire. Toutes les communications
externes doivent s’effectuer via la passerelle edge ou le proxy, qui fournit des API, des événements ou des flux via des points de
terminaison réseau régis à l’aide de protocoles réseau standard. Les équipes peuvent s’auto-organiser pour produire des unités
d’architecture qui sont déployées en continu et mises à jour de manière incrémentielle. L’architecture basée sur les cellules va au-
delà de l’architecture en couches traditionnelle et crée un cadre pour la décentralisation.

La passerelle est le point de contrôle d’une architecture basée sur des cellules, qui fournit une interface bien définie à un sous-
ensemble d’API, d’événements et de flux. Dans ce modèle, la passerelle devient le seul point d’accès (point de terminaison) pour la
cellule. Par conséquent, la passerelle agit comme un point d’application de stratégie, un point de contact d’observabilité et un
catalyseur pour les infrastructures de gouvernance. L’architecture basée sur les cellules peut fonctionner sur un modèle de sécurité
local dans la cellule ou s’étendre à un modèle de sécurité fédéré (ce qui est courant) en se connectant au-delà de la limite de la
cellule.
Figure 19 - Cellule : Une unité d’architecture autonome

La figure 20 représente une partie d’une architecture basée sur des cellules mappée avec des composants WSO2 où les
fonctionnalités de l’application sont divisées en plusieurs cellules. Chaque cellule contient différents composants pour créer les
fonctionnalités attendues.
Figure 20 - Architecture basée sur cellule : une implémentation WSO2

4.0 Expérience d’installation

4.1 Intégration continue et déploiement continu


Pour créer de superbes expériences numériques, l’adoption des « continus » n’est plus un « agréable à avoir », car la vitesse de mise
sur le marché peut briser une entreprise ou lui permettre de survivre et de prospérer à l’avenir. Dans de nombreuses entreprises de
premier plan, le passage d’un pipeline de développement unique à plusieurs pipelines, et du développement en cascade aux
processus automatisés d’intégration continue /livraison continue (CI/CD) qui facilitent l’itération rapide, est déjà en cours, et les
microservices sont un moteur majeur. La nature distribuée et indépendante des microservices se prête naturellement à
l’implémentation de l’intégration continue (CI) et du déploiement continu (CD). L’infrastructure requise pour que l’équipe intègre,
teste et déploie les modifications doit être entièrement automatisée. Cela favorise une expérience utilisateur très réactive.

Chaque microservice aura son propre pipeline CI/CD. Les canaux CI/CD doivent être configurés afin que les modifications apportées
au code source entraînent automatiquement la construction, le test et le déploiement d’un nouveau conteneur en cours de mise en
lots et finalement poussé en production. Les équipes autonomes seront propriétaires de l’intégralité du cycle de vie d’un
microservice. L’équipe travaillera en permanence à l’amélioration des fonctionnalités du microservice et à la résolution des
problèmes rencontrés en production. Le pipeline CI/CD pour chaque microservice sera comme indiqué dans Figure 21.
Figure 21 : pipeline CI/CD pour microservices
Figure 22 - CI/CD Pipeline for Microservices

1. The team commits the changes to a version control repository such as Git.
2. Un système CI/CD tel que Jenkins peut être utilisé pour générer les modifications et exécuter les tests unitaires pour le
microservice pour lequel la modification est validée.
3. En cas d’échec des tests, une alerte est renvoyée à l’équipe. Ce processus se répète jusqu’à ce que tous les tests réussissent.
4. Une fois les tests réussis, le système CI/CD fusionne les modifications avec la ligne principale et prépare un artefact de version
pour le service. Les artefacts pour les microservices sont empaquetés en tant que conteneurs Docker qui sont facilement
déployables par un outil d’orchestration tel que Kubernetes.Artifacts for microservices are packaged as Docker containers
that are readily deployable by an orchestration tool such as Kubernetes.
5. Par la suite, le système CI/CD publie la version dans un référentiel central et indique à l’outil d’orchestration de choisir la
dernière version du microservice qui contient les modifications récentes.
6. Le moteur d’orchestration extrait ensuite la dernière version du référentiel et la déploie en production.
7. Toutes les instances en production sont surveillées par des outils automatisés qui génèrent des alertes pour l’équipe en cas
de problème. Une fois alertée, l’équipe résout les problèmes et envoie la demande de modification au système de contrôle
de version qui déclenche la génération. L’ensemble du processus se répète ensuite pour pousser les changements à la
production.

Le moteur d’orchestration effectue généralement une mise à niveau propagée du service lors du déploiement des mises à jour. Cela
permet aux microservices d’être mis à niveau sans aucun temps d’arrêt. Certaines équipes préfèrent effectuer un déploiement
bleu/vert tandis que d’autres préfèrent une version Canary.

Les microservices principaux et le microservice d’intégration écrits en Ballerina dans un MSA peuvent s’intégrer de manière
transparente dans un pipeline CI/CD. Toutes les modifications d’un microservice peuvent être validées dans un référentiel de
contrôle de version, tel que Git.All the changes in a microservice can be committed to a version control repository, such as Git.
Ballerina est livré avec son propre système de construction et de gestion de module et fonctionne également avec des outils CI / CD
tels que Jenkins et Codefresh. Il peut générer des artefacts de déploiement pendant la compilation et exécuter des tests unitaires. En
outre, il dispose d’un support de conteneur intégré; en d’autres termes, Ballerina fournit des annotations pour générer des images
Docker et des artefacts Kubernetes.in other words, Ballerina provides annotations to generate Docker images and Kubernetes
artifacts.

Pour automatiser le déploiement des micro passerelles et de leurs API, les API REST de l’éditeur WSO2 API Manager peuvent être
utilisées de différentes manières dans l’implémentation du processus CI/CD. Les tâches d’automatisation périodiques ou
déclenchées manuellement peuvent lire les métadonnées d’API d’un environnement, les créer ou les mettre à jour dans
l’environnement suivant et, idéalement, exécuter des tests d’API sur l’environnement de niveau supérieur qui s’assurent qu’aucun
contrat n’est rompu par les modifications introduites. Les tests d’API peuvent être effectués via des suites de tests JMeter ou SOAP
UI qui effectuent des appels d’API dans la microgate pour vérifier les réponses reçues. Les outils de gestion de la configuration tels
que Chef, Ansible et Puppet peuvent être utilisés pour automatiser la configuration d’une instance de microgateway/API manager.
Étant donné que la microgateway prend en charge Nativement Docker et Kubernetes, les images Docker et les artefacts Kubernetes
peuvent être obtenus en tant que résultat de génération de la microgateway configurée.

4.2 La pile technologique


Les organisations qui implémentent des microservices adoptent souvent le style MSA ainsi que la plupart des technologies
complémentaires répertoriées ci-dessous.

Ballerina
Microgateway
Micro Integrator
Technologie WSO2
API Manager
Enterprise Integrator
Identity Server

ide Eclipse
IntelliJ
VSCode

Github
Référentiel de code
Gitlab

Maven
Référentiel binaire Ballerina Central
JFrog

Jenkins
CI/CD Travis
Codefresh

SOAP UI
Infrastructures de test JMeter
TestNG

Chef
Outils de gestion de la
configuration
marionnette Ansible

Orchestration de Kubernetes
conteneurs
OpenShift Mesosphere
DC/OS

Hashicorp Nomad Docker Essaim

Istio
Maillage de service
Linkerd
Conduit nginMesh

observabilité surveillance

 Métriques d’application
o WSO2 Analytics Server (WSO2 API Analytics, WSO2 Integrator Analytics, etc.)
o Prométhée/Grafana
o Splunk
o AppDynamics
 Métriques système
o Icinga
o AWS Cloud Watch

exploitation forestière

 Fluentd
 Pile ELK
o Beats - Agents qui expédient des données à Logstash ou Elasticsearch. Filebeat
expédiera les journaux WSO2 à Logstash.
o Logstash - Traite et structure les fichiers journaux reçus de Filebeat et les envoie à
Elasticsearch.
o Elasticsearch - Stocke et indexe les journaux reçus par Logstash.
o Kibana - Visualise les données stockées dans Elasticsearch

Suivi distribué

 Jaeger
 Zipkin |
 AppDash
 AppDynamics
 WSO2 Analytics Server (WSO2 API Analytics, WSO2 Integrator Analytics, etc.)

|
Tableau 2 : Technologies utiles pour un MSA

5.0 Résumé
L’architecture de microservices est le choix idéal pour créer des applications complexes et évolutives. Ils créent un développement
durable, favorisant ainsi l’agilité et l’évolutivité. Msa n’est pas non plus pour tout le monde - ses conditions préalables et son impact
perturbateur doivent être compris avant de déterminer où, quand et s’il faut l’utiliser. En outre, les architectures monolithiques plus
anciennes continueront de faire partie de la topologie globale d’une entreprise, principalement parce qu’il est coûteux de les
éliminer complètement. Une façon de gérer la vitesse et la flexibilité que les microservices offrent tout en s’attaquant à la complexité
consiste à utiliser des API. Une stratégie d’API adaptée facilite la gestion des microservices et leur permet de coexister avec les
systèmes hérités existants. Par conséquent, la combinaison d’un MSA avec une stratégie d’API holistique est un moyen éprouvé de
récolter les avantages des microservices tout en limitant les inconvénients.

C’est pourquoi l’implémentation d’un MSA piloté par API est essentielle pour rendre les microservices efficaces pour la plupart des
entreprises. Les API ne sont plus seulement des interfaces de code de programmation de bas niveau. Ils sont maintenant largement
produits, adhérant à des normes telles que REST, qui les rendent conviviaux pour les développeurs en matière de gestion et de
gouvernance. Le modèle de passerelle API pour les microservices aborde tous ces aspects avec la gestion des API, qui est une
capacité à fournir un contrôle, une visibilité et une gouvernance sur ces actifs métier de plus en plus précieux.

Alors que Ballerina simplifie le développement de microservices et aide à atteindre la simplicité d’intégration avec sa syntaxe
d’intégration de première classe, WSO2 fournit une plate-forme convaincante pour la gestion des API, l’intégration et la gestion des
identités et des accès pour faciliter un MSA basé sur les API. En fournissant des fonctionnalités sur une plateforme cloud native et
open source, WSO2 facilite l’agilité en étendant la prise en charge à l’échelle de la plateforme pour le développement et le
déploiement de microservices distribués et légers.

références
[1] Ballerine https://ballerina.io/

[2] https://wso2.com/api-management/ WSO2 API Manager

[3] https://wso2.com/integration/ d’intégration d’entreprise WSO2

[4] https://wso2.com/identity-and-access-management/ de serveur d’identité WSO2

[5] Https://thenewstack.io/category/microservices/ de microservices

[6] Michelle Gienow - Microservices 101 ]https://thenewstack.io/microservices-101/

[7] Chris Richardson - Modèle : architecture de microservices https://microservices.io/patterns/microservices.html


[8] Samir Behara - Monolithe vers microservices à l’aide du modèle d’étranglement https://dzone.com/articles/monolith-to-
microservices-using-the-strangler-patt

[9] Martin Fowler - https://www.martinfowler.com/bliki/StranglerApplication.html de demande d’étranglement

[10] Https://developers.redhat.com/topics/service-mesh/ Istio Service Mesh

[11] Kasun Indrasiri - Service Mesh vs API Gateway https://medium.com/microservices-in-practice/service-mesh-vs-api-gateway-


a6d814b9bf56

[12] Kasun Indrasiri - Architecture en couches de microservices https://medium.com/microservices-in-practice/microservices-


layered-architecture-88a7fc38d3f1

[13] Asanka Abeysinghe et Paul Fremantle - Architecture de référence basée sur les cellules : version Q2-
2018 https://github.com/wso2/reference-architecture/blob/master/reference-architecture-cell-based.md

[14] WSO2 nommé leader | The Forrester Wave™: API Management Solutions, https://wso2.com/resources/analyst-reports/the-
forrester-wave-api-management-solutions-q4-2018/?utm_source=landiniam&utm_campaign=forrester_wave_apim_2018B7 du 4e
trimestre 2018

[15] Anne Thomas et Aashish Gupta - Innovation Insight for Microservices https://www.gartner.com/doc/3579057/innovation-


insight-microservices

[16] Communication inter-processus pour les microservices https://ballerina.io/learn/by-guide/inter-microservice-communication/

[17] Asanka Abeysinghe - Navigation dans les ins et les outs d’une architecture de microservices
(MSA) https://www.infoq.com/articles/navigating-microservices-architecture

Vous aimerez peut-être aussi