{"id":83248,"date":"2020-05-29T19:42:48","date_gmt":"2020-05-29T17:42:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam"},"modified":"2020-05-29T19:42:48","modified_gmt":"2020-05-29T17:42:48","slug":"dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam","title":{"rendered":"Dichotomie des donn\u00e9es : repenser notre rapport aux donn\u00e9es et aux services","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bonjour \u00e0 tous ! Nous avons de bonnes nouvelles, en juin, OTUS relance \u00e0 nouveau un cours \u00ab Architecte Logiciel \u00bb<\/a><\/noindex>, c'est pourquoi nous partageons traditionnellement avec vous du mat\u00e9riel utile.<\/b><\/i><\/p>\n

\"Dichotomie
\n
\n Si vous \u00eates confront\u00e9 \u00e0 toute cette histoire de microservices sans aucun contexte, vous pouvez l\u00e9gitimement la trouver un peu \u00e9trange. D\u00e9composer une application en fragments reli\u00e9s par un r\u00e9seau implique n\u00e9cessairement d'ajouter des modes de r\u00e9silience complexes dans le syst\u00e8me distribu\u00e9 r\u00e9sultant. <\/p>\n

Bien que cette approche implique de diviser en de multiples services ind\u00e9pendants, l'objectif final va bien au-del\u00e0 de simplement faire fonctionner ces services sur des machines diff\u00e9rentes. Il s'agit ici de l'interaction avec le monde environnant, qui est lui aussi fondamentalement distribu\u00e9. Pas au sens technique, mais plut\u00f4t dans le sens d'un \u00e9cosyst\u00e8me compos\u00e9 de nombreuses personnes, \u00e9quipes, programmes, et chacune de ces parties doit, d'une mani\u00e8re ou d'une autre, remplir son r\u00f4le.<\/a><\/noindex><\/p>\n

Les entreprises, par exemple, repr\u00e9sentent un ensemble de syst\u00e8mes distribu\u00e9s qui, ensemble, contribuent \u00e0 atteindre un certain objectif. Nous avons ignor\u00e9 ce fait pendant des d\u00e9cennies, essayant d'atteindre une int\u00e9gration en transf\u00e9rant des fichiers par FTP ou en utilisant des outils d'int\u00e9gration d'entreprise, tout en nous concentrant sur nos propres objectifs isol\u00e9s. Mais avec l'arriv\u00e9e des services, tout a chang\u00e9. Les services nous ont aid\u00e9s \u00e0 voir au-del\u00e0 de l'horizon et \u00e0 percevoir un monde de programmes interd\u00e9pendants qui travaillent ensemble. Cependant, pour r\u00e9ussir, il est n\u00e9cessaire de concevoir et de comprendre deux mondes fondamentalement diff\u00e9rents : le monde ext\u00e9rieur, o\u00f9 nous vivons dans un \u00e9cosyst\u00e8me de nombreux autres services, et notre monde personnel, int\u00e9rieur, o\u00f9 nous r\u00e9gnons seuls.<\/p>\n

\"Dichotomie
\n
\n Ce monde distribu\u00e9 diff\u00e8re de celui dans lequel nous avons grandi et auquel nous sommes habitu\u00e9s. Les principes de la construction d'une architecture monolithique traditionnelle ne tiennent pas la route. Par cons\u00e9quent, comprendre correctement ces syst\u00e8mes est plus qu'un simple exercice de cr\u00e9ation d'un joli sch\u00e9ma sur un tableau blanc ou une belle preuve de concept. Il s'agit de faire en sorte qu'un tel syst\u00e8me fonctionne avec succ\u00e8s sur le long terme. Heureusement, les services existent depuis un certain temps, bien qu'ils prennent diff\u00e9rentes formes. Le\u00e7ons de SOA<\/a><\/noindex> ils sont toujours pertinents, m\u00eame agr\u00e9ment\u00e9s de Docker, Kubernetes et l\u00e9g\u00e8rement \u00e9bouriff\u00e9s par des barbes de hipsters. <\/p>\n

Aujourd'hui, nous allons examiner comment les r\u00e8gles ont chang\u00e9, pourquoi nous devons repenser notre approche des services et des donn\u00e9es qu'ils \u00e9changent entre eux, et pourquoi cela n\u00e9cessite des outils compl\u00e8tement diff\u00e9rents.<\/p>\n

L'encapsulation ne sera pas toujours votre amie.<\/h3>\n

\n Les microservices peuvent fonctionner ind\u00e9pendamment les uns des autres. C'est cette caract\u00e9ristique qui leur conf\u00e8re leur plus grande valeur. Cette m\u00eame propri\u00e9t\u00e9 permet aux services de se d\u00e9velopper et de cro\u00eetre. Pas tant en termes de mise \u00e0 l'\u00e9chelle jusqu'\u00e0 des quadrillions d'utilisateurs ou des p\u00e9taoctets de donn\u00e9es (bien qu'ils puissent \u00e9galement aider dans ce cas), mais en termes de mise \u00e0 l'\u00e9chelle du point de vue des personnes, car les \u00e9quipes et les organisations continuent de cro\u00eetre.<\/p>\n

\"Dichotomie
\n
\nCependant, l'ind\u00e9pendance est une arme \u00e0 double tranchant. C'est-\u00e0-dire qu'un service peut fonctionner facilement et sans effort. Mais si une fonction \u00e0 l'int\u00e9rieur du service n\u00e9cessite d'engager un autre service, alors finalement, nous devons apporter des modifications aux deux services presque simultan\u00e9ment. Dans un monolithe, cela est facile, vous effectuez simplement le changement et le d\u00e9ployez en production, mais dans le cas de la synchronisation des services ind\u00e9pendants, il y aura plus de probl\u00e8mes. La coordination entre les \u00e9quipes et les cycles de publication d\u00e9truit la flexibilit\u00e9.<\/p>\n

\"Dichotomie
\n
\nDans le cadre de l'approche standard, les changements transversaux frustrants sont simplement \u00e9vit\u00e9s, en s\u00e9parant clairement les fonctionnalit\u00e9s entre les services. Un service d'authentification unique peut en \u00eatre un bon exemple. Il a un r\u00f4le clairement d\u00e9fini qui le distingue des autres services. Cette s\u00e9paration nette signifie que dans un monde o\u00f9 les exigences changeantes affectent les services environnants, le service d'authentification unique aura peu de chances de changer. Il existe dans un contexte strictement limit\u00e9.<\/p>\n

\"Dichotomie
\n
\n Le probl\u00e8me est que dans le monde r\u00e9el, les services commerciaux ne peuvent pas maintenir une s\u00e9paration des r\u00f4les toujours claire. Par exemple, ces m\u00eames services commerciaux travaillent dans une large mesure avec des donn\u00e9es provenant d'autres services similaires. Si vous \u00eates impliqu\u00e9 dans le commerce en ligne, le traitement des flux de commandes, du catalogue de produits ou des informations sur les utilisateurs deviendra une exigence pour de nombreux services. Chacun des services n\u00e9cessitera un acc\u00e8s \u00e0 ces donn\u00e9es pour fonctionner. <\/p>\n

\"Dichotomie
\nLa plupart des services commerciaux utilisent les m\u00eames flux de donn\u00e9es, ce qui entra\u00eene des interconnexions in\u00e9vitables dans leur fonctionnement.<\/i><\/p>\n

Nous avons donc atteint un point crucial dont il convient de parler. Alors que les services fonctionnent bien pour les composants d'infrastructure qui op\u00e8rent de mani\u00e8re relativement isol\u00e9e, la plupart des services commerciaux se retrouvent \u00e9troitement li\u00e9s.<\/p>\n

Dichotomie des donn\u00e9es<\/h3>\n

\n Des approches ax\u00e9es sur les services existent peut-\u00eatre d\u00e9j\u00e0, mais il y a encore peu d'informations sur la fa\u00e7on d'\u00e9changer de gros volumes de donn\u00e9es entre les services.<\/p>\n

Le probl\u00e8me principal est que les donn\u00e9es et les services sont indissociables. D'une part, l'encapsulation nous encourage \u00e0 masquer les donn\u00e9es afin que les services puissent \u00eatre s\u00e9par\u00e9s les uns des autres, facilitant leur croissance et leurs \u00e9volutions ult\u00e9rieures. D'autre part, nous devons \u00eatre capables de partager librement et de g\u00e9rer des donn\u00e9es communes, comme n'importe lesquelles d'autres. Il s'agit d'\u00eatre capable de commencer \u00e0 travailler imm\u00e9diatement, aussi librement que dans n'importe quel autre syst\u00e8me d'information.<\/p>\n

Cependant, les syst\u00e8mes d'information ont peu \u00e0 voir avec l'encapsulation. En fait, c'est m\u00eame l'inverse. Les bases de donn\u00e9es font tout ce qu'elles peuvent pour donner acc\u00e8s aux donn\u00e9es qu'elles contiennent. Elles sont fournies avec une interface d\u00e9clarative puissante qui permet de modifier les donn\u00e9es selon vos besoins. Cette fonctionnalit\u00e9 est essentielle lors des \u00e9tudes pr\u00e9liminaires, mais pas pour g\u00e9rer la complexit\u00e9 croissante d'un service en \u00e9volution constante.<\/p>\n

\"Dichotomie
\n
\n Et c'est ici que se pose le dilemme. La contradiction. La dichotomie. En effet, les syst\u00e8mes d'information visent \u00e0 fournir des donn\u00e9es, tandis que les services visent \u00e0 masquer.<\/p>\n

Ces deux forces sont fondamentales. Elles constituent la base de la plupart de notre travail, se battant constamment pour dominer les syst\u00e8mes que nous cr\u00e9ons.<\/p>\n

\u00c0 mesure que les syst\u00e8mes de services croissent et \u00e9voluent, nous observons diff\u00e9rentes manifestations des cons\u00e9quences de la dichotomie des donn\u00e9es. Soit l'interface du service se d\u00e9veloppe, offrant un ensemble de fonctionnalit\u00e9s de plus en plus large, et commence \u00e0 ressembler \u00e0 une base de donn\u00e9es maison tr\u00e8s particuli\u00e8re, soit nous ressentons de la frustration et mettons en \u0153uvre une mani\u00e8re d'extraire ou de d\u00e9placer massivement des ensembles de donn\u00e9es entiers d'un service \u00e0 un autre.<\/p>\n

\"Dichotomie
\n
\n En retour, cr\u00e9er quelque chose qui ressemble \u00e0 une base de donn\u00e9es maison tr\u00e8s particuli\u00e8re engendrera toute une s\u00e9rie de probl\u00e8mes. Nous n'allons pas entrer dans les d\u00e9tails de ce qui est dangereux \u00e0 propos de shared database<\/i>, simplement dire qu'elle repr\u00e9sente des difficult\u00e9s d'ing\u00e9nierie et d'op\u00e9rations significatives et co\u00fbteuses pour l'entreprise qui tente de l'utiliser.<\/a><\/noindex> Pire encore, les volumes de donn\u00e9es exacerbent les probl\u00e8mes de fronti\u00e8res des services. Plus il y a de donn\u00e9es partag\u00e9es \u00e0 l'int\u00e9rieur d'un service, plus l'interface deviendra complexe et plus il sera difficile de fusionner des ensembles de donn\u00e9es provenant de diff\u00e9rents services.<\/p>\n

Une approche alternative consistant \u00e0 extraire et \u00e0 d\u00e9placer des ensembles de donn\u00e9es entiers a aussi ses propres probl\u00e8mes. L'approche courante \u00e0 cette question semble \u00eatre l'extraction simple et le stockage d'un ensemble de donn\u00e9es complet, puis son stockage local dans chaque service consommateur.<\/p>\n

Le probl\u00e8me est que diff\u00e9rents services interpr\u00e8tent les donn\u00e9es qu'ils consomment de mani\u00e8re diff\u00e9rente. Ces donn\u00e9es sont toujours \u00e0 port\u00e9e de main. Elles changent et sont trait\u00e9es localement. Assez rapidement, elles cessent d'avoir quoi que ce soit en commun avec les donn\u00e9es de la source.<\/p>\n

\"Dichotomie
\n
\n Plus les copies sont mutables, plus les donn\u00e9es vont diverger avec le temps.<\/p>\n

\"Dichotomie
\n Pire encore, ces donn\u00e9es sont difficiles \u00e0 corriger r\u00e9trospectivement (<\/i><\/p>\n

MDMici, peut vraiment venir \u00e0 la rescousse). En r\u00e9alit\u00e9, certains des probl\u00e8mes technologiques difficiles auxquels les entreprises sont confront\u00e9es proviennent de donn\u00e9es h\u00e9t\u00e9rog\u00e8nes qui se multiplient d'une application \u00e0 l'autre.<\/a><\/noindex> Pour trouver une solution \u00e0 ce probl\u00e8me concernant les donn\u00e9es partag\u00e9es, il faut penser diff\u00e9remment. Elles doivent devenir des objets de premier plan dans les architectures que nous construisons.<\/p>\n

Pat Helland P\u00e9t Helland<\/a><\/noindex> appelle ces donn\u00e9es des \u00ab externes \u00bb, et c'est une caract\u00e9ristique tr\u00e8s importante. Nous avons besoin d'encapsulation pour ne pas r\u00e9v\u00e9ler l'architecture interne du service, mais nous devons faciliter l'acc\u00e8s des services aux donn\u00e9es partag\u00e9es afin qu'ils puissent effectuer leur travail correctement.<\/p>\n

\"Dichotomie
\n
\n Le probl\u00e8me est qu'aucun des approches actuelles n'est pertinente, car ni les interfaces de service, ni l'\u00e9change de messages, ni la base de donn\u00e9es partag\u00e9e ne proposent de bonne solution pour travailler avec des donn\u00e9es externes. Les interfaces de service sont mal adapt\u00e9es pour le partage de donn\u00e9es \u00e0 grande \u00e9chelle. L'\u00e9change de messages d\u00e9place des donn\u00e9es mais ne conserve pas leur historique, donc avec le temps, les donn\u00e9es se d\u00e9t\u00e9riorent. Les bases de donn\u00e9es partag\u00e9es se concentrent trop sur un seul point, ce qui limite l'avancement. Nous coincions in\u00e9vitablement dans un cycle d'incapacit\u00e9 des donn\u00e9es :<\/p>\n

\"Dichotomie
\n Cycle d'incapacit\u00e9 des donn\u00e9es<\/i><\/p>\n

Flux : approche d\u00e9centralis\u00e9e des donn\u00e9es et des services<\/h3>\n

\n Id\u00e9alement, nous devons changer notre approche quant \u00e0 la mani\u00e8re dont les services travaillent avec des donn\u00e9es communes. Actuellement, toute approche se heurte \u00e0 la dichotomie mentionn\u00e9e ci-dessus, car il n'existe pas de solution magique que l'on pourrait g\u00e9n\u00e9reusement saupoudrer pour qu'elle disparaisse. Toutefois, nous pouvons repenser le probl\u00e8me et parvenir \u00e0 un compromis.<\/p>\n

Ce compromis implique un certain degr\u00e9 de centralisation. Nous pouvons tirer parti du m\u00e9canisme de journaux distribu\u00e9s, car il permet des flux \u00e9volutifs et fiables. Il est maintenant n\u00e9cessaire que les services puissent se connecter et travailler avec ces flux communs, mais nous souhaitons \u00e9viter des services centraux complexes qui r\u00e9alisent ce traitement. Par cons\u00e9quent, la meilleure option est d'int\u00e9grer le traitement des flux dans chaque service consommateur. Ainsi, les services pourront combiner des ensembles de donn\u00e9es provenant de diff\u00e9rentes sources et travailler avec eux comme ils le souhaitent.<\/p>\n

Une des mani\u00e8res d'atteindre une telle approche est d'utiliser une plateforme de streaming. Il existe de nombreuses options, mais aujourd'hui nous allons nous concentrer sur Kafka, car son traitement des flux d'\u00e9tat permet de r\u00e9soudre efficacement le probl\u00e8me pr\u00e9sent\u00e9.<\/p>\n

\"Dichotomie
\n
\n L'utilisation du m\u00e9canisme de journalisation distribu\u00e9e nous permet de suivre un chemin balis\u00e9 et d'utiliser l'\u00e9change de messages pour travailler avec. architecture orient\u00e9e \u00e9v\u00e9nements<\/a><\/noindex>. On pense qu'une telle approche offre une meilleure scalabilit\u00e9 et segmentation que le m\u00e9canisme \u00ab requ\u00eate-r\u00e9ponse \u00bb, car elle donne le contr\u00f4le du flux au destinataire plut\u00f4t qu'\u00e0 l'exp\u00e9diteur. Cependant, tout dans cette vie a un co\u00fbt, et ici vous aurez besoin d'un courtier. Mais pour les grandes syst\u00e8mes, ce compromis en vaut la peine (contrairement \u00e0 vos applications web typiques).<\/p>\n

Si le courtier est responsable de la journalisation distribu\u00e9e plut\u00f4t que d'un syst\u00e8me de messagerie traditionnel, il est possible de tirer parti de fonctionnalit\u00e9s additionnelles. Le transport peut \u00eatre mis \u00e0 l'\u00e9chelle lin\u00e9aire presque aussi bien qu'un syst\u00e8me de fichiers distribu\u00e9. Les donn\u00e9es peuvent \u00eatre stock\u00e9es dans les journaux assez longtemps, ce qui nous donne non seulement un \u00e9change de messages, mais aussi un stockage d'informations. Un stockage \u00e9volutif sans crainte d'obtenir un \u00e9tat global modifiable.<\/p>\n

On peut ensuite utiliser un m\u00e9canisme de traitement de flux avec \u00e9tat pour ajouter des outils de base de donn\u00e9es d\u00e9claratifs aux services consommateurs. C'est une pens\u00e9e tr\u00e8s importante. Tant que les donn\u00e9es sont stock\u00e9es dans des flux communs, auxquels tous les services peuvent acc\u00e9der, l'agr\u00e9gation et le traitement effectu\u00e9s par le service sont priv\u00e9s. Ils se retrouvent isol\u00e9s dans un contexte strictement limit\u00e9.<\/p>\n

\"Dichotomie
\n \u00c9liminez la dichotomie des donn\u00e9es en divisant le flux d'\u00e9tats immuables. Ajoutez ensuite cette fonctionnalit\u00e9 \u00e0 chaque service gr\u00e2ce au traitement de flux avec \u00e9tat.<\/i><\/p>\n

Ainsi, si votre service doit travailler avec des commandes, un catalogue de produits, des stocks, il aura un acc\u00e8s complet : vous serez le seul \u00e0 d\u00e9cider quelles donn\u00e9es amalgamer, o\u00f9 les traiter et comment elles doivent \u00e9voluer dans le temps. Bien que les donn\u00e9es soient partag\u00e9es, leur manipulation est totalement d\u00e9centralis\u00e9e. Elle s'effectue \u00e0 l'int\u00e9rieur de chaque service, dans un monde o\u00f9 tout se passe selon vos r\u00e8gles.<\/p>\n

\"Dichotomie
\nPartagez les donn\u00e9es de mani\u00e8re \u00e0 ne pas compromettre leur int\u00e9grit\u00e9. Encapsulez la fonction, et non la source, dans chaque service o\u00f9 elle est n\u00e9cessaire.<\/i><\/p>\n

Il arrive que des donn\u00e9es doivent \u00eatre transf\u00e9r\u00e9es en masse. Parfois, un service n\u00e9cessite un ensemble historique local de donn\u00e9es dans le moteur de base de donn\u00e9es choisi. L'essentiel est que l'on peut garantir qu'en cas de besoin, une copie peut \u00eatre restaur\u00e9e \u00e0 partir de la source gr\u00e2ce \u00e0 un appel au m\u00e9canisme de journalisation distribu\u00e9e. Les connecteurs dans Kafka s'acquittent tr\u00e8s bien de cette t\u00e2che.<\/p>\n

Ainsi, l'approche examin\u00e9e aujourd'hui pr\u00e9sente plusieurs avantages :<\/p>\n