Get best of the week

Dichotomie des données: repenser la relation avec les données et les services

Bonjour à tous! Nous avons une excellente nouvelle, en juin, OTUS lancera à nouveau le cours «Architecte logiciel» , dans le cadre duquel nous partageons traditionnellement du matériel utile avec vous.



Si vous rencontrez toute cette histoire avec des microservices sans aucun contexte, alors vous êtes excusable de la considérer un peu étrange. Le partitionnement de l'application en fragments connectés par un réseau signifie, bien sûr, l'ajout de modes complexes de tolérance aux pannes au système distribué résultant.

Malgré le fait que cette approche inclut la scission en de nombreux services indépendants, l'objectif final est bien plus que le simple fonctionnement de ces services sur différentes machines. Nous parlons d'interaction avec le monde extérieur, qui dans son essence est également distribué. Pas dans un sens technique, mais plutôt dans le sens d'un écosystème composé de nombreuses personnes, équipes, programmes, et chacune de ces parties doit en quelque sorte faire son travail.

Les entreprises, par exemple, sont un ensemble de systèmes distribués qui contribuent ensemble à la réalisation d'un certain objectif. Nous ignorons ce fait depuis des décennies, essayant de réaliser l'unification, de transférer des fichiers via FTP ou d'utiliser des outils d'intégration d'entreprise, tout en nous concentrant sur nos objectifs personnels 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 le monde des programmes interdépendants qui fonctionnent ensemble. Cependant, pour réussir, il est nécessaire de réaliser 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 règnons seuls.



Un tel 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. Par conséquent, une compréhension correcte de ces systèmes est plus que la création d'un diagramme de classe sur un tableau blanc ou une preuve de concept cool. Il s'agit d'un tel système fonctionnant avec succès depuis longtemps. Heureusement, les services existent depuis un certain temps, bien qu'ils soient différents. Les cours SOA sont toujours pertinents, même aromatisés avec des barbes Docker, Kubernetes et hipster légèrement battues.

Donc, aujourd'hui, nous regardons comment les règles ont changé, pourquoi nous devons repenser notre approche des services et des données qu'ils se transmettent et pourquoi nous avons besoin d'outils complètement différents pour cela.

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. La même propriété permet aux services d'évoluer et de se développer. Pas tant en termes d'évolution vers le quadrillion d'utilisateurs ou de pétaoctets de données (bien qu'ici ils puissent aider), mais en termes d'évolution du point de vue des personnes, car les équipes et les organisations ne cessent de croître.



Cependant, l'indépendance est une arme à double tranchant. Autrement dit, le service lui-même peut tourner facilement et naturellement. Mais si une fonction est implémentée à l'intérieur du service qui nécessite l'utilisation d'un autre service, nous devons finalement apporter des modifications aux deux services presque simultanément. Dans le monolithe, c'est facile à faire, il suffit de faire un changement 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 sortie détruit la flexibilité.



Dans le cadre de l'approche standard, les changements ennuyeux de bout en bout sont simplement évités, divisant clairement la fonctionnalité entre les services. Le service d'authentification unique ici peut être un bon exemple. Il a un rôle clairement défini qui le distingue des autres services. Une séparation aussi nette signifie que, dans un monde où les services qui l'entourent évoluent rapidement, le service d'authentification unique est peu susceptible de changer. Il existe dans un contexte strictement limité.



Le problème est que dans le monde réel, les services aux entreprises ne peuvent pas constamment maintenir une séparation des rôles tout aussi nette. Par exemple, les mêmes services commerciaux fonctionnent davantage avec des données provenant d'autres services similaires. Si vous êtes engagé dans la vente au détail en ligne, le traitement du flux de commandes, du catalogue de produits ou des informations utilisateur deviendra une exigence pour bon nombre de vos services. Chacun des services devra avoir accès à ces données pour fonctionner.


La plupart des services aux entreprises utilisent le même flux de données, de sorte que leur travail est toujours lié.

Nous arrivons donc à un point important qui mérite d'être abordé. Bien que les services fonctionnent bien pour les composants d'infrastructure qui fonctionnent en grande partie à part, la plupart des services aux entreprises sont plus étroitement liés.

Dichotomie des données


Il existe peut-être déjà des approches orientées services, mais elles disposent encore de peu d'informations sur la manière d'échanger 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 de nouveaux changements. D'un autre côté, nous devons être en mesure de partager et de gouverner librement les données générales, ainsi que toute autre. Il s'agit de pouvoir commencer immédiatement son travail, aussi librement que dans tout autre système d'information.

Cependant, les systèmes d'information ont peu à voir avec l'encapsulation. En fait, même le contraire. Les bases de données font tout leur possible pour donner accès aux données qui y sont stockées. 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 ici, un dilemme se pose. Contradiction. Dichotomie. Après tout, les systèmes d'information visent à fournir des données et les services à dissimuler.

Ces deux forces sont fondamentales. Ils constituent la base de la plupart de nos travaux, cherchant constamment l'excellence dans les systèmes que nous créons.

À mesure que les systèmes de services grandissent et évoluent, nous constatons différentes manifestations des effets de la dichotomie des données. Soit l'interface de service se développera, offrant une gamme de fonctions de plus en plus large et commencera à ressembler à une très belle base de données locale, soit nous serons déçus et nous mettrons en œuvre un moyen d'extraire ou de déplacer massivement des ensembles de données entiers d'un service à l'autre.



À son tour, la création de quelque chose qui ressemble à une merveilleuse base de données locale entraînera un certain nombre de problèmes. Nous n'entrerons pas dans les détails de ce qu'une base de données partagée est dangereuse , disons simplement qu'elle représente d'importantes difficultés d' ingénierie et d'exploitation coûteuses pour une entreprise qui essaie de l'utiliser.

Pire encore, les volumes de données multiplient les problèmes avec les limites des services. Plus les données sont communes au service, plus l'interface deviendra compliquée et plus il sera difficile de combiner les ensembles de données provenant de différents services.

Une autre approche pour extraire et déplacer des ensembles de données entiers a également ses problèmes. Une approche courante de ce problème ressemble à une simple récupération et stockage de l'ensemble des données, puis à leur stockage local dans chaque service client.



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 traités localement. Assez rapidement, ils cessent d'avoir quelque chose en commun avec les données de la source.


Plus les copies sont mutables, plus les données varieront avec le temps.

Pire encore, ces données sont difficiles à corriger rétrospectivement (le MDM peut vraiment venir à la rescousse ici). En fait, certains des problèmes technologiques insolubles auxquels une entreprise est confrontée sont dus à la multiplication des données hétérogènes d'une application à l'autre.

Pour trouver une solution à ce problème concernant les données partagées, vous devez penser différemment. Ils devraient devenir des objets de première classe dans les architectures que nous construisons. Pat hellandappelle ces données «externes», et c'est une caractéristique très importante. Nous avons besoin d'encapsulation pour ne pas exposer la structure interne du service, mais nous devons faciliter l'accès des services aux données partagées afin qu'ils puissent effectuer correctement leur travail.



Le problème est qu'aucune des approches n'est pertinente aujourd'hui, car 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 son 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 point, ce qui freine les progrès. Nous sommes inévitablement coincés dans un cycle de défaillance des données:


Cycle d'insolvabilité des données

Streams: une approche décentralisée des données et des services


Idéalement, nous devons changer l'approche du fonctionnement des services avec les données partagées. À l'heure actuelle, toute approche est confrontée à la dichotomie susmentionnée, car il n'y a pas de pollen magique qui pourrait être généreusement saupoudré dessus et fait en sorte qu'il disparaisse. Cependant, nous pouvons repenser le problème et parvenir à un compromis.

Ce compromis implique une certaine centralisation. Nous pouvons utiliser le mécanisme de journal distribué car il fournit des flux évolutifs fiables. Maintenant, nous avons besoin de services pour pouvoir rejoindre et travailler avec ces fils communs, mais nous voulons éviter les services divins centralisés complexes qui effectuent ce traitement. Par conséquent, la meilleure option consiste à intégrer le traitement en continu dans chaque service client. Les services pourront donc combiner des ensembles de données provenant de différentes sources et travailler avec eux selon leurs besoins.

Une façon de réaliser cette approche consiste à utiliser une plateforme de streaming. Il existe de nombreuses options, mais aujourd'hui, nous considérerons Kafka, car l'utilisation de son Stateful Stream Processing nous permet de résoudre efficacement le problème présenté.



L'utilisation du mécanisme de journalisation distribuée nous permet de suivre un chemin bien tracé et d'utiliser la messagerie pour travailler avec une architecture orientée événement . On pense que cette approche offre une meilleure mise à l'échelle et une meilleure séparation que le mécanisme de demande-réponse, car elle donne le contrôle du flux au récepteur, pas à l'expéditeur. Cependant, vous devez payer pour tout dans cette vie, et ici vous avez besoin d'un courtier. Mais pour les grands systèmes, ce compromis en vaut la peine (ce qui ne peut pas être dit à propos de vos applications Web moyennes).

Si un courtier est responsable de la journalisation distribuée et non d'un système de messagerie traditionnel, vous pouvez profiter de fonctionnalités supplémentaires. Le transport peut être mis à l'échelle de façon linéaire presque aussi bien qu'un système de fichiers distribué. Les données peuvent être stockées dans les journaux pendant une longue période, nous obtenons donc non seulement la messagerie, mais aussi le stockage d'informations. Stockage évolutif sans crainte d'un état général mutable.

Ensuite, vous pouvez utiliser le mécanisme de traitement de flux avec état pour ajouter des outils de base de données déclaratifs aux services aux consommateurs. C'est un point très important. Alors que les données sont stockées dans des flux partagés auxquels tous les services peuvent accéder, la mise en commun et le traitement effectués par le service sont privés. Ils se retrouvent isolés dans un contexte strictement limité.


Débarrassez-vous de la dichotomie des données en divisant le flux immunitaire des états. Ajoutez ensuite cette fonctionnalité à chaque service à l'aide du traitement de flux dynamique.

Ainsi, si votre service doit fonctionner 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 générales, le travail avec elles est complètement décentralisé. Elle se fait à l'intérieur de chaque service, dans un monde où tout se déroule selon vos règles.


Partagez des données afin que leur intégrité ne soit pas violée. Encapsulez une fonction, pas une source, dans chaque service qui en a besoin.

Il se trouve que les données doivent être massivement déplacées. Parfois, un service nécessite un ensemble de données historiques locales dans un moteur de base de données sélectionné. L'astuce est que vous pouvez garantir que si nécessaire, une copie peut être restaurée à partir de la source en accédant au mécanisme de journalisation distribué. Les connecteurs de Kafka font un excellent travail.

Ainsi, l'approche envisagée aujourd'hui présente plusieurs avantages:

  • Les données sont utilisées sous forme de flux partagés qui peuvent être stockés pendant longtemps dans les journaux, et le mécanisme de travail avec les données partagées est câblé dans chaque contexte individuel, ce qui permet aux services de fonctionner rapidement et facilement. De cette façon, vous pouvez équilibrer la dichotomie des données.
  • , , . .
  • Stateful Stream Processing , , .
  • , , , -.
  • , . , .
  • , .

Comme vous pouvez le voir, c'est plus que REST. Nous avons un ensemble d'outils qui vous permet de travailler avec des données partagées de manière décentralisée.

Dans l'article d'aujourd'hui, tous les aspects n'ont pas été dévoilés. Nous devons encore décider comment équilibrer le paradigme demande-réponse et le paradigme orienté événement. Mais nous y reviendrons la prochaine fois. Il y a des sujets que vous devez mieux connaître, par exemple, pourquoi le traitement dynamique des flux est si bon. Nous en parlerons dans le troisième article. Et il existe d'autres conceptions puissantes que nous pouvons utiliser si nous y recourons, par exemple, Exactly Once Processing . Avec son aide, les règles du jeu pour les systèmes commerciaux distribués sont modifiées, car cette conception offre des garanties transactionnelles pour XAsous forme évolutive. Cela sera discuté dans le quatrième article. Enfin, nous devrons passer en revue les détails de la mise en œuvre de ces principes.



Mais pour l'instant, rappelez-vous simplement ce qui suit: une dichotomie des données est la 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 à considérer les données générales comme des objets de première classe. Le traitement dynamique des flux fournit un compromis unique pour cela. Il évite les «Composants divins» centralisés qui freinent les progrès. De plus, il fournit la vitesse, l'évolutivité et la tolérance aux pannes 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. Les services sont donc plus évolutifs, interchangeables et autonomes. Par conséquent, ils seront non seulement beaux sur les tableaux blancs et lors du test d'hypothèses,mais aussi travailler et se développer pendant des décennies.


.

More articles:


All Articles