J'ai lu beaucoup de choses sur les microservices ces derniers temps, et voici certaines des conclusions que j'ai obtenues jusqu'à présent (veuillez me corriger si je me trompe à un moment donné).
- L'architecture de micro-services va bien avec la conception pilotée par domaine. Habituellement, un EM représente un contexte limité.
- Si le micro-service A nécessite une fonctionnalité qui réside dans le micro-service B , mon modèle est probablement faux et A et B devraient en fait être un micro-service / BC.
- La communication synchrone entre les micro-services (requêtes HTTP directes) est mauvaise, car elle défie le but des micro-services et introduit le couplage entre les composants.
- Une communication asynchrone entre les services est souhaitable. Les services doivent publier des événements dans les files d'attente de messages, afin que d'autres services puissent s'abonner et traiter leur partie de l'événement, ou l'utiliser pour répliquer une partie des données nécessaires à leur contexte. De cette façon, les services peuvent traiter les demandes même si d'autres services sont en panne, ce qui ne serait pas le cas dans la communication synchrone.
- Si le micro-service A publie un événement, le micro-service B souscrit à cet événement et produit un nouvel événement comme résultat, le micro-service A ne doit pas être celui qui traite l'événement nouvellement créé, car ce serait une dépendance circulaire. Dans ce cas, nous devrions introduire un troisième micro-service ou combiner A et B dans le micro-service AB .
- Micro-service est en fait un terme trompeur. Nous devons viser les petits contextes, mais cela n'a pas besoin d'être le cas. Le terme ne doit pas être "micro-service", mais " assez grand pour faire le travail ".
- Les micro-services nous permettent d'introduire de nouvelles fonctionnalités avec plus de facilité et sans crainte de casser tout le système. Cela peut être fait en introduisant un nouveau service ou en refactorisant l'un des services existants.
- Chaque micro-service doit avoir son propre stockage de données. La réplication / duplication des données est un comportement souhaitable dans cette architecture.
Outre la confirmation de ma compréhension de cette architecture, mon autre partie de la question est principalement liée à la découverte de services. Si les services communiquent de manière asynchrone et utilisent une file d'attente d'événements centrale comme amazon SQS, cela signifie-t-il que la découverte de services n'a pas sa place dans une architecture comme celle-ci?
Les services ne doivent avoir aucune connaissance des autres services du système. Ils ne sont conscients que de leur contexte et des événements auxquels ils doivent publier ou auxquels ils doivent s'abonner?