Bonjour, Habr!
Nous commençons à traduire le livre
Microservices Patterns de Chris Richardson
avec des exemples en Java . Cela fait six mois avant la première en russe, mais nous aimerions vous offrir une sorte de bande-annonce - une critique légèrement abrégée de ce livre de Ben Nadel, qui a lu la version MEAP. La revue cite activement le texte de la version Kindle de Richardson.
Bienvenue au chat!
J'ai entendu parler de Chris Richardson lorsque j'ai
découvert sa ressource en ligne
Microservices.io . Là où, pour être honnête, il y a une quantité stupéfiante d'informations - que j'ai décidé de reporter pour plus tard, car à ce moment-là, je ne savais pas comment l'aborder, d'autant plus que je n'avais pratiquement pas affaire à des microservices. J'aime en lire plus. Par conséquent, quand j'ai découvert que Chris publiait le livre de l'auteur
Microservices Patterns: With Examples In Java , j'ai été simplement inspiré. À tel point qu'il ne pouvait pas attendre sa sortie. J'ai donc acquis et lu la «première version» de Manning (MEAP). La semaine dernière, je viens de faire ce que j'ai étudié ce livre, et je pense que c'est une étude fascinante, pragmatique et holistique de l'approche microservice du développement.
Le livre entier est construit sous la forme de l'histoire de Mary - CTO (CTO) de Food To Go, Inc (FTGO). L'entreprise cherche à développer son activité en lançant le refactoring de son ancienne application monolithique et en la transformant en architecture de microservice. Mary se charge de ce projet, car la vitesse de développement a diminué, et les patrons sont de plus en plus ennuyés que les programmeurs sous la direction de Mary ne soient pas en mesure de produire de nouvelles fonctionnalités sous une forme assez de haute qualité.
Bien sûr, le principal problème de Mary est ce que l’on appelle «l’enfer monolithique» dans la terminologie de Richardson. Alors que le monolithe est une application importante et croissante, Richardson se concentre sur un aspect plutôt subtil de la migration FTGO, de sorte qu'il est plus pratique d'exposer et de transmettre tous les concepts. En même temps, le contenu du livre est incroyablement digeste. La plupart des considérations d'architecture sont généralement trop simplifiées ou trop compliquées. Cependant, Richardson a réussi à trouver un terrain d'entente en construisant un modèle de domaine qui s'inscrit (presque) dans la tête, mais est en même temps suffisamment complexe pour illustrer d'intéressants flux de tâches interservices.
Depuis le tout début, j'avais hâte que Richardson soit pragmatique dans les moindres détails. Pas un seul aspect du livre n'est présenté comme une «solution miracle» ou «la seule solution». Partout, nous voyons un choix calculé, un ensemble de compromis clairement définis. Par exemple, l'auteur soumet même l'idée de microservices dans cette veine: l'architecture de microservices doit toujours être évitée, sauf dans les cas où cela est absolument nécessaire:
Un autre défi associé à l'utilisation de l'architecture de microservices est de décider à quel moment du cycle de vie de l'application commencer à utiliser cette architecture. Lors du développement de la première version d'une application, vous ne rencontrez souvent toujours pas les problèmes qu'une telle architecture résout. De plus, l'utilisation d'une architecture distribuée bien équilibrée ne fera que ralentir le développement. Un tel dilemme peut survenir dans les startups, où le défi le plus important réside généralement dans le développement rapide d'un modèle d'entreprise et de sa propre application. Lors de l'utilisation d'une architecture de microservice, il est beaucoup plus difficile d'organiser des itérations rapides. Le développement d'une startup devrait définitivement commencer par une application monolithique. (Version Kindle, adresse 416)
Richardson considère également les microservices dans une perspective holistique, discutant de la dynamique de l'équipe comme un cercle de problèmes complètement indépendant qui est construit sur la partie technologique. Bien sûr, il considère des sujets tels que
Conway’s Law et «
Conway ’s Reverse Maneuver», mais en même temps, il aborde également le fait que les programmeurs sont des personnages pathétiques émotionnels avec lesquels vous devriez «vendre» l’idée de microservices:
En passant au paradigme des microservices, vous êtes obligé de changer votre architecture, votre organisation et vos processus de développement. Cependant, en fin de compte, l'environnement de travail change, les conditions dans lesquelles les gens travaillent et les gens, comme nous l'avons déjà mentionné, sont émotionnels. Si les émotions humaines sont ignorées, l'introduction de microservices dans une organisation peut se transformer en une route escarpée. (Version Kindle, adresse 718)
Les stratégies décrites par l'auteur concernent l'ensemble de l'entreprise, affectent les managers et les cadres qui n'osent peut-être pas entamer une refactorisation d'envergure, en y prenant des ressources précieuses, des personnes qui pourraient activement développer de nouvelles fonctionnalités:
Un avantage significatif du refactoring étape par étape vers une architecture de microservices est qu'une telle stratégie commence immédiatement à porter ses fruits. Ce n'est pas du tout le cas lors de la «refonte» d'un code qui n'apporte aucun bénéfice tant qu'il n'est pas complètement terminé ...
Un autre avantage de la situation dans laquelle la valeur de la transition est acquise à un stade précoce est que nous pouvons attirer le soutien des entreprises pour assurer la migration. Un tel soutien continu est crucial, car plus la refactorisation est active, moins vous pourrez passer de temps à développer des fonctionnalités. Dans certaines organisations, il est difficile de se débarrasser de la dette technique, car les tentatives précédentes peuvent s'avérer trop ambitieuses et n'apportent pas les avantages souhaités. Par conséquent, l'entreprise hésite à continuer d'investir dans le «nettoyage». La nature pas à pas de la refactorisation dans le cas des microservices signifie qu'une équipe peut afficher très souvent des résultats précieux. (Adresse de version Kindle 10769)
D'un point de vue technologique, dans le livre «Microservices. Modèles de développement et de refactorisation »ont examiné un large éventail de sujets: des architectures hexagonales, des tests et de l'intégration continue aux modèles de messagerie et à la création de systèmes observables. Une telle couverture implique que certains sujets du livre sont traités plus en détail que d'autres. Cependant, encore une fois, Richardson parvient parfaitement à tout équilibrer et à donner tellement de détails afin que l'on puisse raisonnablement discuter du sujet sans décourager le lecteur.
En fait, le contenu du livre est organisé de telle manière que vous pouvez vous-même choisir les sujets à approfondir. Dans chaque chapitre, avant une immersion détaillée dans le sujet, une liste de TL; DR est donnée, qui énumère brièvement tous les avantages et les inconvénients. Ainsi, vous parvenez à saisir les points les plus importants du chapitre sans lire tous les mots.
Honnêtement, je viens de parcourir deux chapitres sur le test des microservices et un chapitre sur le déploiement des microservices. Je suis sûr que l'auteur a parfaitement travaillé ces sujets, mais il me semblait qu'il y avait simplement plus d'informations que je ne pouvais en digérer. Le déploiement n'est pas une tâche quotidienne urgente pour moi. Il a écrit plusieurs tests dans sa vie.
Ainsi, je voulais laisser suffisamment d'espace dans ma conscience de grotte peu claire pour y mettre le matériel de tous les autres chapitres: sur la conception orientée sujet (DDD), la communication interprocessus et la synchronisation des données.
L'une des sections qui m'a particulièrement impressionné indique quel service doit traiter les demandes d'un type spécialisé, à savoir: trouver des restaurants appropriés près de l'emplacement actuel de l'utilisateur:
Cependant, il peut être difficile de mettre en œuvre même les demandes qui sont locales en termes d'un service particulier. Cela est possible pour plusieurs raisons. Premièrement, car (comme décrit ci-dessous), il est parfois déraisonnable de mettre en œuvre une demande dans le service propriétaire des données. Une autre raison est que parfois la base de données de services (ou le modèle de données) ne peut pas prendre en charge efficacement la demande (version Kindle, adresse 5659)
... Si, dans l'application FTGO, les informations sur les restaurants sont stockées dans [une autre] base de données, la mise en œuvre de la requête findAvailableRestaurant() est beaucoup plus compliquée. Une réplique des données du restaurant doit être stockée sous une forme qui prend en charge les requêtes géospatiales. Par exemple, une application peut utiliser la bibliothèque d'indexation géospatiale pour DynamoDB, où la table est utilisée comme index géospatial. Alternative: l'application peut stocker une réplique des données du restaurant dans un type de base de données complètement différent. Une situation similaire se produit lorsque nous utilisons des requêtes de texte avec une base de données pour la recherche de texte. (Version Kindle, adresse 5675)
... Dans ce cas, il est conseillé (au moins à première vue) que l'opération de requête soit mise en œuvre par le service même propriétaire des données. Cependant, en plus de la propriété des données, d'autres facteurs doivent être pris en compte.
Il est également nécessaire de prendre en compte la nécessité d'une séparation des tâches et d'éviter de surcharger les services avec trop de fonctionnalités. Par exemple, la principale responsabilité de l'équipe qui développe le service de restauration est d'aider les gérants de restaurant à servir le travail de l'établissement. Cette tâche n'est pas du tout du plan que la mise en œuvre d'une demande critique pour travailler avec de grandes quantités de données. De plus, si l'équipe de développement était responsable de l'opération findAvailableRestaurants() , elle aurait constamment peur d'introduire de tels changements qui pourraient empêcher les consommateurs de passer des commandes. (Version Kindle, adresse 5675)
Ici, mon cerveau a explosé un peu parce que j'ai vu pour la première fois un service dont la seule fonction était d'optimiser les données d'un autre service pour effectuer une tâche spécifique. Cependant, comme le souligne Richardson, il s'agit simplement d'une abstraction plus généralisée de l'idée même qui sous-tend la recherche de texte intégral, par exemple dans Apache Lucene (cet outil fournit une indexation de texte intégral au-dessus d'un autre entrepôt de données).
Je soupçonne - ou plutôt, je veux l'espérer - qu'ayant vu une telle répartition des responsabilités, le lecteur commencera à tracer une nouvelle ligne entre les services. Il ne pensera pas seulement à la «propriété des données», mais commencera également à prendre en compte les «opportunités commerciales» - c'est-à-dire un facteur de valeur réelle afin que la base de données ne semble pas être uniquement l'endroit où l'État est stocké.
Un autre aspect mis en évidence dans cette discussion est l'importance absolue de la synchronisation et de la réplication des données, ainsi que de la messagerie asynchrone dans l'architecture des microservices. Ce sujet traverse tout le livre de Richardson avec un fil rouge, peu importe de quoi ils parlent: la création d'un microservice à partir de zéro ou la refactorisation progressive d'un monolithe en microservices (un chapitre séparé est consacré à ce sujet). Il indique très clairement que la synchronisation est cette force de base qui permet vraiment de réaliser beaucoup de choses.
Je pourrais mentionner beaucoup de choses intéressantes. Qu'est-ce qui vaut, par exemple, le fait que Richardson parle correctement de l'authentification et de l'autorisation dans un système distribué? Je pense que ce sujet n'a pas encore été complètement exploré, pour le dire en douceur. L'auteur explique la conception orientée sujet de la manière la plus accessible. Il démontre également que même des classes très simples peuvent avoir un comportement.
Depuis plus d'un an maintenant, j'essaie de bien comprendre l'architecture des systèmes distribués et les modèles de microservices (ce qui est particulièrement difficile, car mon travail quotidien est lié à l'entretien du monolithe). Beaucoup de textes que j'ai lus sur ces sujets sont soit excessivement superficiels, soit trop étroits et en même temps approfondis. Le livre "Microservices. Modèles de développement et de refactorisation »est en effet le juste milieu entre ces deux extrêmes.
Je recommande fortement ce livre à tous (nos audacieux) qui essaient (y compris, jusqu'à présent sans succès) de passer d'une architecture monolithique à un système distribué.