Salut tout le monde! Nous avons une excellente nouvelle, OTUS relance le cours en juin , dans le cadre duquel nous partageons traditionnellement du matériel utile avec vous.
Si vous avez découvert toute cette histoire de microservices sans aucun contexte, vous seriez pardonné de penser que c'est un peu étrange. Diviser une application en fragments connectés par un réseau signifie nécessairement ajouter des modes complexes de tolérance aux pannes au système distribué résultant.
Bien que cette approche implique de le diviser en de nombreux services indépendants, l’objectif final va bien au-delà du simple fait que ces services s’exécutent sur différentes machines. Nous parlons ici d’interaction avec le monde extérieur, qui est également distribuée dans son essence. Pas au sens technique, mais plutôt dans le sens d’un écosystème composé de nombreuses personnes, équipes, programmes, et chacune de ces parties doit, d’une manière ou d’une autre, faire son travail.
Les entreprises, par exemple, sont un ensemble de systèmes distribués qui contribuent collectivement à la réalisation d'un objectif. Nous avons ignoré ce fait pendant des décennies, essayant de parvenir à l'unification en envoyant des fichiers FTP ou en utilisant des outils d'intégration d'entreprise tout en nous concentrant sur nos propres objectifs isolés. Mais avec l’avènement des services, tout a changé. Les services nous ont aidés à regarder au-delà de l’horizon et à voir un monde de programmes interdépendants qui fonctionnent ensemble. Cependant, pour réussir, il est nécessaire de reconnaître et de concevoir deux mondes fondamentalement différents : le monde extérieur, où nous vivons dans un écosystème de nombreux autres services, et notre monde personnel et intérieur, où nous gouvernons seuls.
Ce monde distribué est différent de celui dans lequel nous avons grandi et auquel nous sommes habitués. Les principes de construction d’une architecture monolithique traditionnelle ne résistent pas à la critique. Donc, mettre en place ces systèmes correctement ne se limite pas à créer un diagramme de tableau blanc sympa ou une preuve de concept intéressante. Il s’agit de garantir le bon fonctionnement d’un tel système sur une longue période. Heureusement, les services existent depuis un certain temps, même s’ils semblent différents. sont toujours d'actualité, même assaisonnés de Docker, Kubernetes et de barbes hipsters un peu minables.
Aujourd'hui, nous allons examiner comment les règles ont changé, pourquoi nous devons repenser la façon dont nous abordons les services et les données qu'ils se transmettent, et pourquoi nous aurons besoin d'outils complètement différents pour y parvenir.
L'encapsulation ne sera pas toujours votre amie
Les microservices peuvent fonctionner indépendamment les uns des autres. C'est cette propriété qui leur donne la plus grande valeur. Cette même propriété permet aux services d’évoluer et de se développer. Pas tant dans le sens d’une évolution vers des quadrillions d’utilisateurs ou des pétaoctets de données (bien que cela puisse également être utile), mais dans le sens d’une évolution en termes de personnes à mesure que les équipes et les organisations se développent continuellement.
Toutefois, l’indépendance est une arme à double tranchant. Autrement dit, le service lui-même peut fonctionner facilement et naturellement. Mais si une fonction est implémentée au sein d’un service qui nécessite l’utilisation d’un autre service, nous finissons par devoir apporter des modifications aux deux services presque simultanément. Dans un monolithe, c'est facile à faire, il vous suffit d'apporter une modification et de l'envoyer à la version, mais dans le cas de la synchronisation de services indépendants, il y aura plus de problèmes. La coordination entre les équipes et les cycles de publication détruit l’agilité.
Dans le cadre de l'approche standard, ils essaient simplement d'éviter les changements ennuyeux de bout en bout, en divisant clairement les fonctionnalités entre les services. Le service d’authentification unique peut être un bon exemple ici. Il a un rôle clairement défini qui le différencie des autres services. Cette séparation claire signifie que dans un monde où les demandes en matière de services évoluent rapidement, il est peu probable que le service d'authentification unique change. Elle existe dans un contexte strictement limité.
Le problème est que dans le monde réel, les services aux entreprises ne peuvent pas maintenir à tout moment la même séparation pure des rôles. Par exemple, les mêmes services métiers fonctionnent dans une plus grande mesure avec des données provenant d’autres services similaires. Si vous êtes impliqué dans la vente au détail en ligne, le traitement du flux de commandes, du catalogue de produits ou des informations sur les utilisateurs deviendra une exigence pour bon nombre de vos services. Chacun des services aura besoin d’accéder à ces données pour fonctionner.
La plupart des services métiers partagent le même flux de données, leur travail est donc invariablement lié.
Nous arrivons ainsi à un point important qui mérite d’être évoqué. Même si les services fonctionnent bien pour les composants d’infrastructure qui fonctionnent en grande partie de manière isolée, la plupart des services aux entreprises finissent par être beaucoup plus étroitement liés.
Dichotomie des données
Les approches orientées services existent peut-être déjà, mais elles manquent encore de connaissances sur la manière de partager de grandes quantités de données entre services.
Le principal problème est que les données et les services sont indissociables. D'une part, l'encapsulation nous encourage à masquer les données afin que les services puissent être séparés les uns des autres et faciliter leur croissance et leurs changements ultérieurs. D’un autre côté, nous devons pouvoir diviser et conquérir librement les données partagées, comme n’importe quelle autre donnée. L’enjeu est de pouvoir commencer à travailler immédiatement, aussi librement que dans n’importe quel autre système d’information.
Cependant, les systèmes d’information n’ont pas grand-chose à voir avec l’encapsulation. En fait, c'est tout le contraire. Les bases de données font tout ce qu’elles peuvent pour donner accès aux données qu’elles stockent. Ils sont livrés avec une puissante interface déclarative qui vous permet de modifier les données selon vos besoins. Une telle fonctionnalité est importante au stade de la recherche préliminaire, mais pas pour gérer la complexité croissante d'un service en constante évolution.
Et là, un dilemme se pose. Contradiction. Dichotomie. Après tout, les systèmes d’information servent à fournir des données et les services à cacher.
Ces deux forces sont fondamentales. Ils soutiennent une grande partie de notre travail, luttant constamment pour l’excellence dans les systèmes que nous construisons.
À mesure que les systèmes de services se développent et évoluent, nous constatons les conséquences de la dichotomie des données de plusieurs manières. Soit l'interface du service va se développer, offrant une gamme toujours croissante de fonctionnalités et commencer à ressembler à une base de données maison très sophistiquée, soit nous deviendrons frustrés et mettrons en œuvre un moyen de récupérer ou de déplacer en masse des ensembles entiers de données d'un service à l'autre.
À son tour, créer quelque chose qui ressemble à une base de données maison sophistiquée entraînera toute une série de problèmes. Nous n'entrerons pas dans les détails sur les raisons pour lesquelles c'est dangereux base de données partagée, disons simplement que cela représente des coûts d'ingénierie et d'exploitation importants et coûteux. pour l'entreprise qui essaie de l'utiliser.
Ce qui est pire, c'est que les volumes de données amplifient les problèmes de limites de service. Plus les données seront partagées au sein d’un service, plus l’interface deviendra complexe et plus il sera difficile de combiner des ensembles de données provenant de différents services.
L’approche alternative consistant à extraire et déplacer des ensembles de données entiers présente également ses problèmes. Une approche courante de cette question consiste simplement à récupérer et à stocker l’intégralité de l’ensemble de données, puis à le stocker localement dans chaque service consommateur.
Le problème est que différents services interprètent différemment les données qu’ils consomment. Ces données sont toujours à portée de main. Ils sont modifiés et transformés localement. Très vite, elles n’ont plus rien de commun avec les données de la source.
Plus les copies sont mutables, plus les données varieront dans le temps.
Pire encore, ces données sont difficiles à corriger rétrospectivement ( C’est là qu’il peut vraiment venir à la rescousse). En fait, certains des problèmes technologiques insolubles auxquels les entreprises sont confrontées proviennent de la disparité des données qui se multiplient d’une application à l’autre.
Pour trouver une solution à ce problème, nous devons penser différemment les données partagées. Ils doivent devenir des objets de premier ordre dans les architectures que nous construisons. appelle ces données « externes », et c'est une caractéristique très importante. Nous avons besoin d'une encapsulation pour ne pas exposer le fonctionnement interne d'un service, mais nous devons permettre aux services d'accéder facilement aux données partagées afin qu'ils puissent faire leur travail correctement.
Le problème est qu'aucune des deux approches n'est pertinente aujourd'hui, puisque ni les interfaces de service, ni la messagerie, ni la base de données partagée n'offrent une bonne solution pour travailler avec des données externes. Les interfaces de service sont mal adaptées à l’échange de données à n’importe quelle échelle. La messagerie déplace les données mais ne stocke pas leur historique, de sorte que les données sont corrompues au fil du temps. Les bases de données partagées se concentrent trop sur un seul point, ce qui freine les progrès. Nous nous retrouvons inévitablement coincés dans un cycle de défaillance des données :
Cycle de défaillance des données
Streams : une approche décentralisée des données et des services
Idéalement, nous devons changer la façon dont les services fonctionnent avec les données partagées. À ce stade, l’une ou l’autre approche se trouve confrontée à la dichotomie susmentionnée, car aucune poussière magique ne peut être saupoudrée dessus pour la faire disparaître. Cependant, nous pouvons repenser le problème et parvenir à un compromis.
Ce compromis implique un certain degré de centralisation. Nous pouvons utiliser le mécanisme de journalisation distribué car il fournit des flux fiables et évolutifs. Nous voulons maintenant que les services puissent rejoindre et fonctionner sur ces threads partagés, mais nous voulons éviter les services divins centralisés et complexes qui effectuent ce traitement. Par conséquent, la meilleure option consiste à intégrer le traitement des flux dans chaque service consommateur. De cette façon, les services pourront combiner des ensembles de données provenant de différentes sources et travailler avec eux comme ils le souhaitent.
Une façon de parvenir à cette approche consiste à utiliser une plateforme de streaming. Il existe de nombreuses options, mais aujourd'hui, nous examinerons Kafka, car l'utilisation de son Stateful Stream Processing nous permet de résoudre efficacement le problème présenté.
L'utilisation d'un mécanisme de journalisation distribué nous permet de suivre le chemin parcouru et d'utiliser la messagerie pour travailler avec . Cette approche est considérée comme offrant une meilleure mise à l'échelle et un meilleur partitionnement que le mécanisme requête-réponse, car elle donne le contrôle du flux au destinataire plutôt qu'à l'expéditeur. Cependant, pour tout dans cette vie, vous devez payer, et ici vous avez besoin d'un courtier. Mais pour les grands systèmes, le compromis en vaut la peine (ce qui n'est peut-être pas le cas pour votre application Web moyenne).
Si un courtier est responsable de la journalisation distribuée plutôt qu'un système de messagerie traditionnel, vous pouvez profiter de fonctionnalités supplémentaires. Le transport peut évoluer de manière linéaire presque aussi bien qu'un système de fichiers distribué. Les données peuvent être stockées dans des journaux pendant une période assez longue, nous obtenons donc non seulement un échange de messages, mais également un stockage d'informations. Stockage évolutif sans crainte d'un état partagé mutable.
Vous pouvez ensuite utiliser le traitement de flux avec état pour ajouter des outils de base de données déclarative aux services consommateurs. C'est une idée très importante. Bien que les données soient stockées dans des flux partagés auxquels tous les services peuvent accéder, l'agrégation et le traitement effectués par le service sont privés. Ils se retrouvent isolés dans un contexte strictement limité.
Éliminez la dichotomie des données en séparant le flux d’état immuable. Ajoutez ensuite cette fonctionnalité à chaque service à l’aide de Stateful Stream Processing.
Ainsi, si votre service doit travailler avec des commandes, un catalogue de produits, un entrepôt, il aura un accès complet : vous seul déciderez quelles données combiner, où les traiter et comment elles doivent évoluer dans le temps. Malgré le fait que les données soient partagées, leur utilisation est complètement décentralisée. Il est produit au sein de chaque service, dans un monde où tout se déroule selon vos règles.
Partagez des données sans compromettre leur intégrité. Encapsulez la fonction, et non la source, dans chaque service qui en a besoin.
Il arrive que les données doivent être déplacées en masse. Parfois, un service nécessite un ensemble de données historiques locales dans le moteur de base de données sélectionné. L'astuce est que vous pouvez garantir que, si nécessaire, une copie pourra être restaurée à partir de la source en accédant au mécanisme de journalisation distribuée. Les connecteurs de Kafka font un excellent travail à cet égard.
Ainsi, l'approche discutée aujourd'hui présente plusieurs avantages :
- Les données sont utilisées sous la forme de flux communs, qui peuvent être stockés dans des journaux pendant une longue période, et le mécanisme permettant de travailler avec des données communes est câblé dans chaque contexte individuel, ce qui permet aux services de fonctionner facilement et rapidement. De cette façon, la dichotomie des données peut être équilibrée.
- Les données provenant de différents services peuvent être facilement combinées en ensembles. Cela simplifie l'interaction avec les données partagées et élimine le besoin de conserver des ensembles de données locaux dans la base de données.
- Le traitement de flux avec état met uniquement en cache les données et la source de vérité reste les journaux généraux, de sorte que le problème de la corruption des données au fil du temps n'est pas si aigu.
- À la base, les services sont axés sur les données, ce qui signifie que malgré des volumes de données toujours croissants, les services peuvent toujours répondre rapidement aux événements commerciaux.
- Les problèmes d’évolutivité incombent au courtier et non aux services. Cela réduit considérablement la complexité des services d’écriture, puisqu’il n’est pas nécessaire de penser à l’évolutivité.
- L'ajout de nouveaux services ne nécessite pas de modifier les anciens, la connexion de nouveaux services devient donc plus facile.
Comme vous pouvez le constater, c’est bien plus que du REST. Nous avons reçu un ensemble d'outils qui vous permettent de travailler avec des données partagées de manière décentralisée.
Tous les aspects n'ont pas été abordés dans l'article d'aujourd'hui. Nous devons encore trouver un équilibre entre le paradigme requête-réponse et le paradigme événementiel. Mais nous y reviendrons la prochaine fois. Il y a des sujets que vous devez mieux connaître, par exemple pourquoi le traitement de flux avec état est si efficace. Nous en parlerons dans le troisième article. Et il existe d’autres constructions puissantes dont nous pouvons tirer parti si nous y recourons, par exemple : . Il change la donne pour les systèmes d'entreprise distribués car il offre des garanties transactionnelles pour sous une forme évolutive. Ceci sera discuté dans le quatrième article. Enfin, il nous faudra revenir sur les détails de mise en œuvre de ces principes.
Mais pour l’instant, rappelez-vous simplement ceci : la dichotomie des données est une force à laquelle nous sommes confrontés lors de la création de services aux entreprises. Et nous devons nous en souvenir. L’astuce consiste à tout renverser et à commencer à traiter les données partagées comme des objets de première classe. Le traitement de flux avec état fournit un compromis unique pour cela. Cela évite les « composants divins » centralisés qui freinent le progrès. De plus, il garantit l'agilité, l'évolutivité et la résilience des pipelines de streaming de données et les ajoute à chaque service. Par conséquent, nous pouvons nous concentrer sur le flux général de conscience auquel tout service peut se connecter et travailler avec ses données. Cela rend les services plus évolutifs, interchangeables et autonomes. Ainsi, non seulement ils apparaîtront bien sur les tableaux blancs et les tests d’hypothèses, mais ils fonctionneront et évolueront également pendant des décennies.
Source: habr.com