{"id":80035,"date":"2020-05-02T13:42:54","date_gmt":"2020-05-02T11:42:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny"},"modified":"2020-05-02T13:42:54","modified_gmt":"2020-05-02T11:42:54","slug":"udobnye-arhitekturnye-patterny","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny","title":{"rendered":"Mod\u00e8les architecturaux pratiques","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Salut, Habr !<\/p>\n

<\/p>\n

\u00c0 la lumi\u00e8re des \u00e9v\u00e9nements actuels li\u00e9s au coronavirus, plusieurs services en ligne font face \u00e0 une charge accrue. Par exemple, une des cha\u00eenes de magasins au Royaume-Uni a simplement arr\u00eat\u00e9 son site de commandes en ligne,<\/a><\/noindex>car les ressources n'\u00e9taient pas suffisantes. De plus, il n'est pas toujours possible d'acc\u00e9l\u00e9rer un serveur simplement en ajoutant du mat\u00e9riel plus puissant, mais il est n\u00e9cessaire de traiter les demandes des clients (sinon, ils iront chez les concurrents).<\/p>\n

<\/p>\n

Dans cet article, je vais bri\u00e8vement parler des pratiques populaires qui permettront de cr\u00e9er un service rapide et r\u00e9silient. Cependant, parmi les sch\u00e9mas de d\u00e9veloppement possibles, j'ai s\u00e9lectionn\u00e9 uniquement ceux que vous pouvez actuellement facilement utiliser.<\/strong>Pour chaque point, vous avez soit d\u00e9j\u00e0 des biblioth\u00e8ques pr\u00eates \u00e0 l'emploi, soit la possibilit\u00e9 de r\u00e9soudre le probl\u00e8me en utilisant une plateforme cloud.<\/p>\n

<\/a><\/noindex><\/p>\n

Scalabilit\u00e9 horizontale<\/h1>\n

<\/p>\n

Le point le plus simple et le plus connu. On distingue g\u00e9n\u00e9ralement deux m\u00e9thodes de r\u00e9partition de la charge : la scalabilit\u00e9 horizontale et verticale. Dans le premier cas,<\/a><\/noindex> vous permettez aux services de fonctionner en parall\u00e8le, r\u00e9partissant ainsi la charge entre eux. Dans le second,<\/a><\/noindex> vous commandez des serveurs plus puissants ou optimisez le code.<\/p>\n

<\/p>\n

\u00c0 titre d'exemple, je vais prendre un stockage cloud abstrait de fichiers, c'est-\u00e0-dire un certain \u00e9quivalent d'OwnCloud, OneDrive, etc.<\/p>\n

<\/p>\n

L'image standard de ce type de sch\u00e9ma est ci-dessous, mais elle ne fait qu'illustrer la complexit\u00e9 du syst\u00e8me. En effet, nous devons synchroniser les services. Que se passe-t-il si un utilisateur sauvegarde un fichier depuis sa tablette et souhaite ensuite le consulter sur son t\u00e9l\u00e9phone ?<\/p>\n

<\/p>\n

\"Mod\u00e8les
\nLa diff\u00e9rence entre les approches : dans la scalabilit\u00e9 verticale, nous sommes pr\u00eats \u00e0 accro\u00eetre la puissance des n\u0153uds, tandis que dans la scalabilit\u00e9 horizontale, nous ajoutons de nouveaux n\u0153uds pour r\u00e9partir la charge.<\/p>\n

<\/p>\n

CQRS<\/h1>\n

<\/p>\n

Command Query Responsibility Segregation<\/a><\/noindex> est un mod\u00e8le assez important, car il permet \u00e0 diff\u00e9rents clients non seulement de se connecter \u00e0 diff\u00e9rents services, mais \u00e9galement de recevoir des flux d'\u00e9v\u00e9nements identiques. Ses avantages ne sont pas si \u00e9vidents pour une application simple, mais ils sont extr\u00eamement importants (et simples) pour un service charg\u00e9. Son principe : les flux de donn\u00e9es entrants et sortants ne doivent pas se croiser. En d'autres termes, vous ne pouvez pas envoyer une requ\u00eate et attendre une r\u00e9ponse, au lieu de cela, vous envoyez une requ\u00eate au service A, mais vous obtenez une r\u00e9ponse dans le service B.<\/p>\n

<\/p>\n

Le premier avantage de cette approche est la possibilit\u00e9 d'interrompre la connexion (au sens large du terme) pendant l'ex\u00e9cution d'une longue requ\u00eate. Prenons par exemple une s\u00e9quence standard :<\/p>\n

<\/p>\n

    \n
  1. Le client a envoy\u00e9 une requ\u00eate au serveur.<\/li>\n
  2. Le serveur a lanc\u00e9 un traitement long.<\/li>\n
  3. Le serveur a r\u00e9pondu au client avec un r\u00e9sultat.<\/li>\n<\/ol>\n

    <\/p>\n

    Imaginons que, dans le point 2, une interruption de connexion se soit produite (soit en raison d'une d\u00e9connexion r\u00e9seau, soit parce que l'utilisateur est pass\u00e9 \u00e0 une autre page, rompant ainsi la connexion). Dans ce cas, il sera difficile pour le serveur d'envoyer une r\u00e9ponse \u00e0 l'utilisateur concernant ce qui a \u00e9t\u00e9 trait\u00e9. En appliquant CQRS, la s\u00e9quence sera l\u00e9g\u00e8rement diff\u00e9rente :<\/p>\n

    <\/p>\n

      \n
    1. Le client s'est abonn\u00e9 aux mises \u00e0 jour.<\/li>\n
    2. Le client a envoy\u00e9 une requ\u00eate au serveur.<\/li>\n
    3. Le serveur a r\u00e9pondu \u00ab requ\u00eate re\u00e7ue \u00bb.<\/li>\n
    4. Le serveur a r\u00e9pondu avec le r\u00e9sultat via le canal du point \u00ab 1 \u00bb.<\/li>\n<\/ol>\n

      <\/p>\n

      \"Mod\u00e8les<\/p>\n

      <\/p>\n

      Comme on le voit, le sch\u00e9ma est l\u00e9g\u00e8rement plus complexe. De plus, l'approche intuitive request-response est absente ici. Cependant, comme on peut le voir, une interruption de connexion pendant le traitement de la requ\u00eate ne conduira pas \u00e0 une erreur. De plus, si l'utilisateur est effectivement connect\u00e9 au service depuis plusieurs appareils (par exemple, un t\u00e9l\u00e9phone mobile et une tablette), il est possible de faire en sorte que la r\u00e9ponse parvienne aux deux appareils.<\/p>\n

      <\/p>\n

      Il est int\u00e9ressant de noter que le code de traitement des messages entrants devient identique (\u00e0 100 %) tant pour les \u00e9v\u00e9nements affect\u00e9s par le client lui-m\u00eame que pour les autres \u00e9v\u00e9nements, y compris ceux d'autres clients.<\/p>\n

      <\/p>\n

      Cependant, dans la r\u00e9alit\u00e9, nous obtenons des avantages suppl\u00e9mentaires gr\u00e2ce au fait qu'un flux unidirectionnel peut \u00eatre trait\u00e9 de mani\u00e8re fonctionnelle (en utilisant RX et des analogues). Et c'est d\u00e9j\u00e0 un vrai plus, car en substance, l'application peut devenir compl\u00e8tement r\u00e9active, tout en utilisant \u00e9galement une approche fonctionnelle. Pour les applications lourdes, cela peut consid\u00e9rablement \u00e9conomiser des ressources en d\u00e9veloppement et en maintenance.<\/p>\n

      <\/p>\n

      Si nous combinons cette approche avec une mise \u00e0 l'\u00e9chelle horizontale, alors nous obtenons en prime la possibilit\u00e9 d'envoyer des requ\u00eates \u00e0 un serveur tout en recevant des r\u00e9ponses d'un autre. Ainsi, le client peut choisir le service qui lui convient le mieux, et le syst\u00e8me \u00e0 l'int\u00e9rieur pourra tout de m\u00eame traiter les \u00e9v\u00e9nements de mani\u00e8re appropri\u00e9e.<\/p>\n

      <\/p>\n

      Event Sourcing<\/h1>\n

      <\/p>\n

      Comme vous le savez, l'une des caract\u00e9ristiques principales d'un syst\u00e8me distribu\u00e9 est l'absence de temps commun et de section critique partag\u00e9e. Pour un seul processus, vous pouvez effectuer une synchronisation (sur les m\u00eames mutex), o\u00f9 vous \u00eates s\u00fbr que personne d'autre n'ex\u00e9cute ce code. Cependant, pour un syst\u00e8me distribu\u00e9, cela peut \u00eatre dangereux, car cela entra\u00eenera des frais g\u00e9n\u00e9raux et ruinera tout l'int\u00e9r\u00eat de l'\u00e9volutivit\u00e9 : tous les composants devront attendre les uns les autres.<\/p>\n

      <\/p>\n

      D'ici, nous obtenons un fait important : un syst\u00e8me distribu\u00e9 rapide ne peut pas \u00eatre synchronis\u00e9, car cela diminuerait les performances. D'un autre c\u00f4t\u00e9, nous avons souvent besoin d'une certaine coh\u00e9rence des composants. Et pour cela, nous pouvons utiliser l'approche de la coh\u00e9rence \u00e9ventuelle<\/a><\/noindex>, qui garantit qu'en l'absence de modifications des donn\u00e9es, apr\u00e8s un certain laps de temps apr\u00e8s la derni\u00e8re mise \u00e0 jour (\u00ab en fin de compte \u00bb), toutes les requ\u00eates renverront la derni\u00e8re valeur mise \u00e0 jour.<\/p>\n

      <\/p>\n

      Il est important de comprendre qu'une coh\u00e9rence stricte<\/a><\/noindex>est souvent appliqu\u00e9e aux bases de donn\u00e9es classiques, o\u00f9 chaque n\u0153ud poss\u00e8de les m\u00eames informations (ce qui est souvent r\u00e9alis\u00e9 lorsqu'une transaction est consid\u00e9r\u00e9e comme \u00e9tablie uniquement apr\u00e8s la r\u00e9ponse d'un deuxi\u00e8me serveur). Il existe certaines concessions dues aux niveaux d'isolation, mais l'id\u00e9e principale reste la m\u00eame : vous pouvez vivre dans un monde compl\u00e8tement coh\u00e9rent.<\/p>\n

      <\/p>\n

      Cependant, revenons \u00e0 la t\u00e2che initiale. Si une partie du syst\u00e8me peut \u00eatre construite avec la coh\u00e9rence \u00e9ventuelle<\/a><\/noindex>, alors on peut construire le sch\u00e9ma suivant.<\/p>\n

      <\/p>\n

      \"Mod\u00e8les<\/p>\n

      <\/p>\n

      Caract\u00e9ristiques importantes de cette approche :<\/p>\n

      <\/p>\n