Microservices, dessinés honnêtement

Pas "quels services existent" - une liste s'en charge, et cette liste est généralement dans les noms de dépôts. La question est : l'un quelconque d'entre eux peut-il être déployé seul ? Tout ce qu'on espère des microservices - des livraisons indépendantes, une montée en charge indépendante, une équipe qui livre sans réunion de coordination - découle du fait que la réponse soit oui, et aucune autre propriété du dessin ne compte si elle est non.

Un diagramme de composants y répond, à condition de dessiner les bonnes choses. Chaque service déployable est un composant ; chaque contrat publié une interface ; chaque événement un «signal». Couvrez ensuite un service de la main : si ce qui reste spécifie entièrement son remplaçant, ce service peut être livré à son propre rythme.

Sur la figure ci-dessus, la passerelle dépend de IOrders - un contrat synchrone, parce qu'elle ne peut pas répondre à l'utilisateur sans une commande. Shipping et billing pointent vers OrderPlaced, un signal que l'order service émet sans l'attendre.

Dessiner les deux différemment est toute la valeur de l'image. Les arêtes synchrones sont là où la disponibilité se compose : si l'order service est en panne, la passerelle renvoie une erreur. Les arêtes d'événement sont là où elle ne se compose pas : shipping en panne retarde un colis et n'entraîne rien d'autre. Un diagramme qui trace les deux en simples flèches a effacé la distinction qui décide comment le système tombe.

Voici un monolithe distribué, et c'est la forme la plus répandue en production. Rien n'y est illégal, rien n'est mal nommé, et cela passera la relecture parce que cela ressemble à tous les autres diagrammes de microservices. Ce que cela dit, si l'on lit les flèches plutôt que les boîtes, c'est que les quatre services doivent être déployés ensemble, testés ensemble et debout ensemble : l'équipe a donc pris tous les coûts de la distribution et gardé toutes les contraintes d'un monolithe.

Le signe se compte : le nombre de sauts synchrones sur une requête. Un, c'est bien. Deux, en général c'est bien. Trois ou plus, et la disponibilité de l'ensemble est le produit de celles des parties : quatre services à 99,9 % chacun donnent environ 99,6 % ensemble, soit trois heures par mois où personne ne peut rien commander.

Les correctifs sont visibles sur le même dessin. Laissez orders publier un événement et laissez pricing et inventory y réagir. Ou fusionnez deux des boîtes, réponse légitime que l'on propose rarement. Ou mettez en cache ce dont pricing a besoin, pour que le saut quitte le chemin de la requête. Les trois sont des modifications de ce diagramme, et c'est pourquoi les vingt minutes passées à le dessiner avant de construire en valent la peine.

La notation est traitée dans le guide du diagramme de composants, et cinq autres arrangements - dont le cycle à deux sens que cet article ne répète pas - sont dans les exemples de diagrammes de composants.