Points clés:
- L'interaction directe entre les composants peut conduire à un comportement inattendu difficile à comprendre pour les développeurs, les opérateurs et les analystes métier.
- Pour garantir la pérennité de l'entreprise, vous devez voir toutes les interactions qui surviennent dans le système.
- : , -; , ; , ; (process mining), ; , .
- , , , .
En 2018, j'ai rencontré un architecte d'une grande entreprise Internet. Il m'a dit qu'ils suivaient toutes les directives correctes et divisaient les fonctionnalités en petits morceaux dans différents domaines, bien qu'ils n'appellent pas ce style architectural "microservices". Ensuite, nous avons parlé de la manière dont ces services interagissent les uns avec les autres pour prendre en charge une logique métier qui transcende les frontières des services, car c'est là que la théorie est mise en pratique. Il a dit que leurs services interagissent à l'aide d'événements publiés sur le bus - cette approche s'appelle « chorégraphie » (j'en parlerai plus en détail ci-dessous). L'entreprise considère que c'est optimal en termes de réduction de la cohésion. Mais ils ont été confrontés à un problème: il est difficile de comprendre ce qui se passe dans le système, et il est encore plus difficile de le changer. " Ce n'est pas la danse chorégraphiée que vous voyez dans les présentations de microservices, c'est un saut de pogo incontrôlable! "
Tout cela est en phase avec ce que d'autres clients m'ont dit, par exemple, Josh Wolf de Credit Sense :" Le système que nous remplaçons utilise une chorégraphie peer-to-peer complexe qui nécessite l'analyse de plusieurs bases de code pour comprendre. "
Comprenons cette situation à l'aide d'un exemple simplifié. Disons que vous créez une application de traitement des commandes. Vous avez choisi d'utiliser une architecture événementielle et avez choisi, par exemple, Apache Kafka comme bus d'événements. Lorsqu'une personne passe une commande, le service de paiement génère un événement qui est récupéré par le service de paiement. Ce service de paiement reçoit de l'argent et génère un événement qui est récupéré par le service d'inventaire.
Flux d'événements chorégraphiés.
L'avantage de cette approche est que vous pouvez facilement ajouter de nouveaux composants au système. Supposons que vous souhaitiez créer un service de notification qui envoie des e-mails à vos clients. Vous pouvez simplement ajouter un nouveau service et vous abonner aux événements appropriés sans toucher au reste du système. Et maintenant, vous pouvez gérer de manière centralisée les paramètres d'interaction et la complexité des notifications qui répondent aux exigences du RGPD (règlement européen sur la protection des données).
Ce style d'architecture est appelé chorégraphie car il n'est pas nécessaire qu'un orchestrateur dise aux autres composants ce qu'il faut faire. Ici, chaque composant génère des événements auxquels d'autres composants peuvent réagir. Ce style est censé réduire le couplage entre les composants et faciliter la conception et la modification du système, comme c'est le cas pour notre plan de service de notification.
Perte de transparence dans le flux des événements
Je souhaite me concentrer sur la question qui revient le plus souvent lorsque je participe aux discussions de cette architecture: "Comment éviter de perdre la transparence (et probablement le contrôle) du flux des événements?" Dans une étude , Camunda (où je travaille) a posé une question sur l'utilisation des microservices. 92% des répondants les ont au moins envisagés, et 64% les ont déjà utilisés sous une forme ou une autre. Ce n'est plus un battage médiatique. Mais dans cette étude, nous nous sommes également interrogés sur les difficultés, et avons reçu une confirmation claire de nos préoccupations: le plus souvent, on nous a parlé de la perte de transparence de bout en bout des processus commerciaux qui impliquent de multiples services.
Vous vous souvenez des architectures basées sur plusieurs déclencheurs de base de données? Des architectures dans lesquelles vous ne savez jamais ce qui se passera exactement en réponse à une action, et pourquoi cela se produira-t-il? Parfois, cela me rappelle les difficultés liées aux microservices réactifs, même si une telle comparaison est clairement inappropriée.
Assurer la transparence
Que peut-on faire dans une telle situation? Les approches suivantes vous aideront à retrouver la transparence, mais chacune a ses propres avantages et inconvénients:
- Traçage distribué (comme Zipkin ou Jaeger).
- Lacs de données ou outils analytiques (comme Elastic).
- Contrôle et analyse de l'extraction de processus (par exemple, ProM).
- Suivi à l'aide de l'automatisation des flux de tâches (comme Camunda).
Notez que toutes ces approches impliquent l'observation d'un système en cours d'exécution et l'examen des flux de données qu'il contient. Je ne connais aucun outil d'analyse statique capable d'extraire des informations utiles.
Traçage distribué
Cette approche surveille la pile d'appels entre différents systèmes et services. Pour cela, des identifiants uniques sont utilisés, généralement ajoutés à certains en-têtes (par exemple, dans les en-têtes HTTP ou de message). Si tout le monde dans votre système comprend ou du moins relaie ces en-têtes, vous pouvez suivre l'échange de demandes entre les services.
En règle générale, le traçage distribué est utilisé pour comprendre comment les demandes circulent dans le système, pour trouver où il y a des échecs et pour rechercher les causes de la dégradation des performances. Les avantages de l'approche incluent la maturité de la boîte à outils et l'écosystème vivant qui l'accompagne. Par conséquent, il vous sera relativement facile de commencer à utiliser le traçage distribué, même si vous devez généralement (peut-être de manière agressive) instruire vos applications ou conteneurs.
Alors pourquoi ne pas utiliser cette approche pour comprendre comment les processus métier génèrent des événements? Il y a généralement deux raisons à cela:
- . , , . . , -.
- . , , 90 % . Three Pillars with Zero Answers — towards a New Scorecard for Observability. .
Ainsi, en soi, le traçage ne nous convient guère. Il serait logique de se tourner vers une approche similaire, mais en tenant compte de notre tâche spécifique. Cela signifie généralement ne pas collecter des traces, mais des événements commerciaux ou thématiques importants que vous avez peut-être déjà rencontrés. Souvent, la solution se résume à la création d'un service qui écoute tous les événements et les stocke dans la base de données, ce qui peut augmenter la charge sur le système. Aujourd'hui, de nombreuses personnes utilisent Elastic pour cela.
C'est un mécanisme puissant qui est relativement facile à mettre en œuvre. Et il a déjà été mis en œuvre par la plupart de nos clients événementiels. Le principal obstacle à la mise en œuvre est généralement la question de savoir qui, dans une grande organisation, gérera un tel outil, car il doit certainement être géré de manière centralisée. Il vous sera facile de créer votre propre interface utilisateur pour travailler avec ce mécanisme, vous permettant de trouver rapidement des informations pertinentes pour certaines requêtes.
Un exemple d'interface de surveillance d'événements .
Les inconvénients incluent le manque de graphiques qui facilitent le travail avec la liste des événements. Mais vous pouvez les ajouter à l'infrastructure, par exemple en projetant des événements dans un moteur de rendu comme BPMN. Les petits frameworks comme bpmn.io vous permettent d'ajouter des informations aux diagrammes affichés sous forme de pages HTML simples ( exemple ) qui peuvent être intégrées dans le plugin Kibana.
Ce modèle ne peut être exécuté avec aucun module de gestion des processus métier, il s'agit simplement d'un diagramme utilisé pour visualiser les événements journalisés. De ce point de vue, vous disposez d'une certaine liberté dans le choix du détail de l'affichage. Et si vous êtes particulièrement intéressé par l'image complète, vous pouvez créer des modèles qui affichent les événements de différents microservices sur un même diagramme. Un diagramme comme celui-ci ne vous empêchera pas d'apporter des modifications aux services individuels, de sorte que la flexibilité de votre entreprise ne sera pas affectée. Mais il y a un risque que les diagrammes deviennent obsolètes par rapport à l'état actuel du système d'exploitation.
Outils d'extraction de processus
Dans l'approche précédente, vous auriez à modéliser explicitement le diagramme à utiliser pour le rendu. Mais si nous ne pouvons pas connaître à l'avance la nature du flux des événements, nous devons d'abord l'examiner.
Cela peut être fait à l'aide d'outils de surveillance et d'analyse des processus. Ils peuvent créer et afficher graphiquement un diagramme complet, ce qui vous permet souvent d'explorer les détails, en particulier liés aux goulots d'étranglement du système ou aux optimisations potentielles.
Sonne comme la solution parfaite à notre problème. Malheureusement, ces outils sont le plus souvent utilisés pour étudier les processus dans les architectures héritées, ils se concentrent donc sur l'analyse des journaux et fonctionnent de manière médiocre avec les flux d'événements en direct. Un autre inconvénient est qu'il s'agit d'instruments purement scientifiques difficiles à utiliser (par exemple ProM) ou très lourds (par exemple Celonis). D'après mon expérience, il n'est pas pratique d'utiliser ces types d'outils dans des efforts typiques de microservices.
Dans tous les cas, l'exploration des processus et l'analyse des données offrent des possibilités intéressantes pour fournir une visibilité sur les flux d'événements et les processus métier. Espérons qu'il y aura bientôt une technologie avec des fonctionnalités similaires, mais plus légère, plus conviviale pour les développeurs et plus facile à mettre en œuvre.
Suivi avec automatisation des flux de tâches
Une autre approche intéressante consiste à modéliser les flux de tâches, puis à les déployer et à les exécuter via le module de contrôle. Ce modèle est spécial en ce sens qu'il ne suit que les événements et ne fait rien activement. Autrement dit, il ne gère rien - il enregistre seulement. J'en ai parlé au Kafka Summit San Francisco 2018 , en utilisant Apache Kafka et le module de workflow open source Zeebe pour la démonstration .
Cette opportunité est particulièrement intéressante. Il existe de nombreuses innovations dans le domaine des modules de contrôle, ce qui conduit à l'émergence d'outils compacts, faciles à développer et hautement évolutifs. J'ai écrit à ce sujet dans Événements, flux et services de longue durée: une approche moderne de l'automatisation des flux de travail . Les inconvénients évidents incluent la nécessité d'une modélisation préliminaire du flux de tâches. Mais d'un autre côté, ce modèle peut être exécuté à l'aide du module de contrôle de processus, contrairement à la surveillance d'événements. Fondamentalement, vous démarrez des instances de processus pour les événements entrants ou vous mappez des événements à une instance. Il vous permet également de vérifier si la réalité correspond à votre modèle.
De plus, cette approche vous permet d'exploiter toute la chaîne d'outils fournie par la plateforme d'automatisation des flux de tâches. Vous pouvez voir l'état réel du système, suivre les SLA, détecter les échecs des instances de processus ou effectuer une analyse approfondie des données d'audit historiques.
Un exemple de surveillance d'un flux de tâches.
Lorsque j'ai testé cette approche avec nos clients, c'était facile à mettre en place. Nous venons de mettre en place un composant générique qui reçoit les événements du bus et l'a mis en correspondance avec le module de contrôle de flux de tâches. Si l'événement ne pouvait pas être réconcilié, nous avons utilisé une petite table de décision pour déterminer s'il pouvait être ignoré ou s'il conduirait à un incident qui devrait faire l'objet d'une enquête plus tard. Nous avons également amélioré les modules de contrôle de flux de tâches utilisés dans les microservices pour exécuter la logique métier afin qu'ils génèrent certains événements (par exemple, une instance de processus est démarrée, terminée ou a terminé une étape) qui feront partie de la vue d'ensemble.
Tout cela est similaire à la surveillance des événements, mais avec un accent sur les processus métier. Contrairement au traçage, l'approche capture tous les événements commerciaux et affiche une vue d'ensemble dans différents formats adaptés aux différentes parties prenantes.
Perspectives commerciales
La disponibilité des processus métier pour la surveillance vous permet de comprendre le contexte. Vous pouvez voir pour une instance spécifique comment, quand et dans quel état il s'est terminé. Cela signifie que vous pouvez comprendre quel chemin ce processus n'a pas suivi (et que d'autres le suivent souvent), et quels événements ou données ont conduit à certaines décisions. Vous pouvez également comprendre ce qui peut arriver dans un proche avenir. D'autres types de surveillance ne permettent pas cela. S'il n'est souvent pas courant aujourd'hui de discuter de la question de la cohérence entre l'entreprise et l'informatique, il est impératif que les non-spécialistes soient également en mesure de comprendre les processus métier et la manière dont les événements se déroulent à travers différents microservices.
Du suivi à la gestion
Le suivi des processus est un excellent outil pour fournir un suivi opérationnel, des rapports, des indicateurs de performance clés et de la transparence; ce sont tous des facteurs importants pour maintenir la flexibilité de l'entreprise. Mais dans les projets actuels, le suivi n'est que la première étape vers une gestion et une orchestration plus approfondies dans votre écosystème de microservices.
Par exemple, vous pouvez commencer par surveiller les délais d'expiration dans les processus de bout en bout. Lorsqu'un délai d'expiration se produit, une action est automatiquement exécutée. Dans l'exemple ci-dessous, après 14 jours, nous informerons le client du retard, mais nous attendrons toujours. Et après 21 jours, nous annulerons la commande.
Curieusement, envoyer une équipe pour annuler une commande ici est une orchestration qui est souvent discutée de manière controversée.
Orchestration
J'entends souvent que l'orchestration doit être évitée car elle conduit à la cohérence ou perturbe l'autonomie des microservices individuels, et bien sûr elle peut être mal implémentée. Mais il est également possible de mettre en œuvre l'orchestration d'une manière cohérente avec les principes des microservices et apportant une grande valeur commerciale. J'en ai parlé en détail à InfoQ New York 2018 .
Pour moi, l'orchestration signifie qu'un service peut dire à un autre de faire quelque chose. Et c'est tout. Ce n'est pas une connexion étroite, mais un autre type de connexion. Rappelons-nous notre exemple avec une commande. Il peut être souhaitable que le service de caisse génère simplement une commande et la place sur le bus événementiel sans savoir qui la traitera. Le service de commande récupère l'événement concernant la commande qui est apparue. Le destinataire prend connaissance de l'événement et décide de faire quelque chose. Autrement dit, la cohésion est présente du côté du destinataire.
Avec le paiement, la situation est différente, car il est plutôt étrange que le service de paiement sache pour quoi le paiement a été reçu. Mais il aura besoin de ces connaissances afin de réagir aux bons événements comme passer ou passer une commande. Cela signifie également que le service devra être changé chaque fois que vous souhaitez recevoir des paiements pour de nouveaux produits ou services. Dans de nombreux projets, cette connexion désagréable est contournée en générant les événements de paiement nécessaires, mais ce ne sont pas des événements, car l'expéditeur veut que quelqu'un fasse quelque chose. C'est une équipe! Le service de commande commande au service de paiement de recevoir de l'argent. Dans ce cas, l'expéditeur sait quelle commande envoyer et le fait, c'est-à-dire que la cohésion est présente du côté de l'expéditeur.
Pour que chaque interaction entre deux services soit efficace, cela implique un certain degré de couplage. Mais en fonction de la tâche spécifique, il peut être conseillé de mettre en œuvre la connectivité sur l'un des côtés.
Le service de commande peut même être responsable de l'orchestration et d'autres services, en suivant les étapes de l'exécution de la commande. J'ai discuté des avantages de cette approche en détail dans l'exposé ci-dessus. L'astuce est qu'une bonne architecture nécessite un équilibre entre orchestration et chorégraphie, ce qui n'est pas toujours facile à faire.
Cependant, dans cet article, je voulais me concentrer sur la transparence. Et il y a un avantage évident à l'orchestration à l'aide du module de flux de tâches: un modèle n'est pas seulement du code à exécuter par l'orchestrateur, il peut être utilisé pour assurer la transparence du flux.
Conclusion
Il est très important d'assurer la transparence de vos processus métiers, quelle que soit leur mise en œuvre. J'ai envisagé différentes approches, et dans de vrais projets, tout se résume généralement à une sorte de surveillance d'événements à l'aide d'outils comme Elastic, ou au suivi des processus à l'aide de modules de contrôle. En partie, le choix peut dépendre du cas spécifique et des rôles des personnes impliquées. Par exemple, un analyste métier doit comprendre les données collectées à partir de toutes les instances de processus avec le degré de détail requis, tandis qu'un responsable des opérations doit analyser un processus spécifique avec différents degrés de détail et, probablement, acquérir des outils pour résoudre rapidement les incidents au niveau du système.
Si votre projet repose fortement sur la chorégraphie, le suivi des processus peut vous conduire à ajouter une orchestration. Et je pense que c'est une étape très importante pour maintenir un contrôle à long terme sur vos processus métier. Sinon, vous pouvez «créer un système événementiel soigneusement découplé, sans vous rendre compte que vous perdrez la transparence à mesure que le nombre d'événements et de processus augmente, et ainsi vous assurer des problèmes dans les années à venir», comme l'a dit Martin Fowler . Si vous travaillez sur un tout nouveau système, trouvez dès le départ un équilibre entre orchestration et chorégraphie.
Cependant, quelles que soient les spécificités de la mise en œuvre du système, assurez-vous de fournir à l'entreprise un affichage compréhensible des processus métier mis en œuvre à l'aide de services interactifs.