Un concept que je ne comprends pas entièrement est celui du point de défaillance unique. Il me semble que chaque fois que vous avez plusieurs services, dites A , B et C , impliqués dans un système entier, alors si l'un d'entre eux est en panne, le système dans son ensemble ne peut rien faire d'aussi utile (si le système pouvait être utile sans B , alors pourquoi B est-il même nécessaire en premier lieu?) .
Par exemple, disons que nous avons un pipeline tel que A publie un événement qui est consommé par B puis B publie un message qui est consommé par C et ce flux de données est la façon dont l'ensemble du système remplit sa fonction.
A ===> B ===> C
Peut-être que C est le service qui traite les informations de carte de crédit: l'entreprise ne fonctionne pas vraiment s'il n'y a pas d'argent! p >
Puisqu'il s'agit d'un système de messagerie, ces services sont "indépendants" en ce sens que si l'un tombe en panne, cela n'en provoque pas un autre. Ok, mais si B tombe en panne, alors C ne recevra aucun nouveau message et l'ensemble du système ne sert pas son objectif. Alors, quelle différence cela fait-il d'avoir des services séparés A , B et C plutôt qu'un service ABC ?
5 Réponses :
Pensez à un service («B») comme un ensemble de routes parallèles ou de canaux de traitement. Une fois que ces routes sont construites selon une conception (le code), elles resteront là pour fonctionner. La conception ne change pas, donc le traitement ne change pas, et il fait ce que vous dites. Cependant, considérez qu'une route développe un défaut non lié à la conception - une défaillance matérielle. La surface de la route est physiquement non praticable. Le trafic ne peut pas circuler, mais heureusement nous avons de nombreuses routes parallèles qui peuvent absorber ce trafic! Si nous n'avions qu'une seule route (large), toute la route a été fermée pour resurfaçage afin qu'aucun trafic ne puisse circuler.
Vous pouvez aller plus loin. Imaginez que le trafic sur vos routes parallèles augmente et que les routes sont à pleine capacité. Il est facile de construire une autre route à voie unique. Ce n'est pas grand-chose, mais une fois construit, vous pouvez lui permettre de fonctionner à sa capacité maximale. Mais la rente foncière coûte de l'argent! Ainsi, lorsque le trafic est réduit, nous pouvons facilement mettre hors service la petite route et ne pas payer de loyer dessus.
Vous pouvez aller encore plus loin - disons que vous proposez une nouvelle conception de route, donc vous la construisez à côté des routes existantes. Vous pouvez autoriser le trafic sur cette route et tester son fonctionnement. S'il y a une erreur inconnue dans votre conception, du trafic peut être perdu. Mais la plupart du trafic peut passer par vos bonnes routes existantes. Maintenant, nous pouvons soit changer le design, soit le conserver et changer lentement chaque petite route dans le nouveau design.
Dans les premier et deuxième paragraphes, il semble que vous décriviez plusieurs instances d'une application. Vous pouvez avoir plusieurs instances de ABC et ce ne serait pas des microservices tels qu'ils sont généralement définis. Je parle d'avoir une logique métier distincte, des contextes limités, etc. pour A , B et C , chacun pouvant avoir plusieurs instances .
Différentes parties du service ont des besoins de capacité en ligne différents. L'analyse des modes de défaillance est essentielle pour vraiment comprendre où vous devez séparer les services et les rendre plus résilients. Par exemple, C n'est peut-être pas utile de séparer s'il n'est pas facultatif pour le flux de travail pour la commande, mais parce qu'il est si important, il devrait obtenir sa propre résilience supplémentaire (plusieurs nœuds de calcul de basculement sur plusieurs hôtes).
Si, d'un autre côté, C était un système de traitement des commandes (envoi du ticket de prélèvement à l'entrepôt), il n'aurait pas besoin de ce niveau de résilience et pourrait se permettre de tomber en panne. Il s'agit de décider où se trouvent vos points de défaillance et combien cela vaut la peine d'éviter ces défaillances.
En plus des modes de défaillance, il y a des problèmes de capacité à prendre en compte. Le traitement des cartes de crédit peut avoir des besoins de mise à l'échelle complètement différents d'un service de liste d'inventaire. Peut-être que les clients demandent des prix TRÈS fréquemment et, en tant que tel, vous devrez peut-être prendre en charge une capacité beaucoup plus grande que pour le service de traitement des cartes de crédit. En tant que tel, vous devez renforcer la capacité d'évolutivité pour cette partie de votre service. En outre, une défaillance de ce service peut être plus acceptable qu'une défaillance d'un service de traitement de commande réel (les revenus sont probables ou spéculatifs). Quoi qu'il en soit, vous devez comprendre la valeur de chacun de ces services et trouver des moyens de les diviser pour vous permettre de faire évoluer leur capacité et leur résilience de manière indépendante.
Modifiez légèrement le système et ajoutez de la redondance.
[(A) (A) (A)] ===> [(B) (B) (B)] ===> [(C) (C) (C)]
Maintenant, même si l'un des services répliqués dit que (B) tombe en panne, la user story serait terminée en raison de la disponibilité des nœuds de clonage (B).
Ce système (dans cette étendue) n'a pas de point de défaillance unique.
Point à noter, votre conception utilisait la messagerie ou essentiellement "couplé en vrac", il était très facile de modifier le système et de supprimer les points de défaillance.
Il existe d'autres aspects des microservices qui nécessiteraient une discussion détaillée. Le cube d'échelle est une perspective qui m'a aidé à comprendre les concepts alignés sur les microservices. modèle .
La composition des services est l'une des parties les plus difficiles des microservices. Sans lire quelques livres à ce sujet, voici quelques conseils. Si vous recherchez certains des avantages ci-dessous, il peut être judicieux de vous lancer dans un service indépendant:
Je vous recommande également de choisir judicieusement votre banque de données. Beaucoup de temps peut être passé à optimiser la fiabilité des services codés et de l'infrastructure qui l'accompagne, mais vous pouvez toujours avoir un point de défaillance unique dans votre architecture de base de données (ou réseau ou équilibreur de charge ou dns ou ...)
Je pense que votre question est rhétorique. De toute évidence, si le système dépend de tous les services, alors n'importe quel service est un point de défaillance unique. Si un seul service tombe en panne, le système ne «servira pas son objectif». Adopter des microservices ne vous libérera pas automatiquement du problème du point de défaillance unique.
La plupart des partisans des microservices vous diront que vous devez concevoir votre système de manière à ce que tout le système ne dépende d'aucun service. Mais, un tel système me semble être une licorne. C'est la même chose que de dire "si vous supprimez une partie de votre code, l'application devrait continuer à fonctionner"
En réalité, vous pouvez concevoir un système où il reste un utilitaire si un service tombe en panne. Mais je doute qu'il y ait un système qui puisse fonctionner correctement lorsque l'un de ses composants importants est manquant. Lorsqu'un système fonctionne correctement sans l'un de ses composants, le nombre de vérifications d'erreurs supplémentaires et ainsi de suite nécessaires est épouvantable.
Mais le fait est que ce n'est pas pour cela que les microservices sont conçus. Ce n'est qu'un des avantages supposés que les gens vantent. L'avantage ne vient que si vous concevez votre système pour tenir compte de l'échec. Mais, de toute façon, vous n'avez pas besoin d'utiliser des microservices pour le faire.
Créer des clients occasionnellement connectés peut être un autre moyen d'éviter un point de défaillance unique. Git est un bon exemple. Si GitHub tombe en panne, il n'y a pas de personnes assises en train de dire "oh, on dirait que je n'aurai pas à faire de travail aujourd'hui alors".
Remarque: un équilibreur de charge peut être jeté devant n'importe quel service afin que la machine physique ne devienne pas le point de défaillance unique.