{"id":31124,"date":"2019-10-31T21:39:36","date_gmt":"2019-10-31T18:39:36","guid":{"rendered":"https:\/\/prohoster.info\/blog\/stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie\/"},"modified":"2019-10-31T21:39:36","modified_gmt":"2019-10-31T18:39:36","slug":"stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie","title":{"rendered":"\u00c9l\u00e9ments constitutifs des applications distribu\u00e9es. Deuxi\u00e8me approche","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Annonce<\/strong><\/p>\n

<\/p>\n

Coll\u00e8gues, au milieu de l'\u00e9t\u00e9, je pr\u00e9vois de publier un autre cycle d'articles sur la conception de syst\u00e8mes de service de masse : \u00ab Exp\u00e9rience VTrade \u00bb \u2014 une tentative d'\u00e9crire un cadre pour les syst\u00e8mes de trading. Le cycle abordera la th\u00e9orie et la pratique de la construction d'une bourse, d'une ench\u00e8re et d'un magasin. \u00c0 la fin de l'article, je vous propose de voter pour les sujets qui vous int\u00e9ressent le plus.
\n<\/em><\/p>\n

<\/p>\n

\"\u00c9l\u00e9ments<\/p>\n

<\/p>\n

C'est le dernier article de la s\u00e9rie sur les applications r\u00e9actives distribu\u00e9es en Erlang\/Elixir. Dans dans le premier article<\/a><\/noindex> vous pouvez trouver les bases th\u00e9oriques de l'architecture r\u00e9active. Le deuxi\u00e8me article<\/a><\/noindex> illustre les principaux mod\u00e8les et m\u00e9canismes de construction de tels syst\u00e8mes.<\/p>\n

<\/p>\n

Aujourd'hui, nous aborderons les questions du d\u00e9veloppement de la base de code et des projets dans leur ensemble. <\/p>\n

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

Organisation des services<\/h2>\n

<\/p>\n

Dans la vie r\u00e9elle, lors de la conception d'un service, on doit souvent combiner plusieurs mod\u00e8les d'interaction dans un seul contr\u00f4leur. Par exemple, le service users, qui s'occupe de la gestion des profils utilisateurs du projet, doit r\u00e9pondre aux requ\u00eates req-resp et informer des mises \u00e0 jour de profils via pub-sub. Ce cas est assez simple : un contr\u00f4leur g\u00e8re le messaging, impl\u00e9mentant la logique du service et publiant les mises \u00e0 jour.<\/p>\n

<\/p>\n

La situation se complique lorsque nous devons mettre en place un service distribu\u00e9 tol\u00e9rant aux pannes. Imaginons que les exigences relatives aux users aient chang\u00e9 : <\/p>\n

<\/p>\n

    \n
  1. maintenant, le service doit traiter les requ\u00eates sur 5 n\u0153uds du cluster, <\/li>\n
  2. avoir la capacit\u00e9 d'ex\u00e9cuter des t\u00e2ches de traitement en arri\u00e8re-plan, <\/li>\n
  3. et aussi \u00eatre capable de g\u00e9rer dynamiquement les listes d'abonnement aux mises \u00e0 jour de profils.<\/li>\n<\/ol>\n

    <\/p>\n

    Remarque :<\/em> Nous ne discutons pas de la question du stockage coh\u00e9rent et de la r\u00e9plication des donn\u00e9es. Supposons que ces questions aient \u00e9t\u00e9 r\u00e9solues au pr\u00e9alable et qu'il existe d\u00e9j\u00e0 dans le syst\u00e8me une couche de stockage fiable et \u00e9volutive, et que les gestionnaires aient des m\u00e9canismes pour interagir avec elle.<\/p>\n

    <\/p>\n

    La description formelle du service users est devenue plus complexe. Du point de vue du programmeur, gr\u00e2ce \u00e0 l'utilisation du messaging, les changements sont minimes. Pour satisfaire \u00e0 la premi\u00e8re exigence, nous devons configurer la r\u00e9partition \u00e0 la point d'\u00e9change req-resp. <\/p>\n

    <\/p>\n

    La n\u00e9cessit\u00e9 de traiter des t\u00e2ches en arri\u00e8re-plan se pr\u00e9sente souvent. Dans les utilisateurs, cela peut inclure des v\u00e9rifications de documents des utilisateurs, le traitement de multim\u00e9dias t\u00e9l\u00e9charg\u00e9s ou la synchronisation des donn\u00e9es avec les r\u00e9seaux sociaux. Ces t\u00e2ches doivent \u00eatre r\u00e9parties au sein du cluster et leur progression contr\u00f4l\u00e9e. Nous avons donc deux options : soit utiliser le mod\u00e8le de r\u00e9partition des t\u00e2ches de l'article pr\u00e9c\u00e9dent, soit, si cela ne convient pas, \u00e9crire un planificateur de t\u00e2ches personnalis\u00e9 qui g\u00e9rera le pool de travailleurs comme n\u00e9cessaire. <\/p>\n

    <\/p>\n

    Le point 3 n\u00e9cessite une extension du mod\u00e8le pub-sub. Pour cela, apr\u00e8s avoir cr\u00e9\u00e9 un point d'\u00e9change pub-sub, nous devons \u00e9galement d\u00e9marrer le contr\u00f4leur de ce point dans notre service. Ainsi, nous extrayons la logique de gestion des abonnements et des d\u00e9sabonnements de la couche de messagerie vers l'impl\u00e9mentation des utilisateurs.<\/p>\n

    <\/p>\n

    En fin de compte, la d\u00e9composition de la t\u00e2che a montr\u00e9 qu'afin de satisfaire les exigences, nous devions lancer 5 instances du service sur diff\u00e9rents n\u0153uds et cr\u00e9er une entit\u00e9 suppl\u00e9mentaire - un contr\u00f4leur pub-sub responsable des abonnements.
    \nPour lancer 5 travailleurs, il n'est pas n\u00e9cessaire de modifier le code du service. La seule action suppl\u00e9mentaire consiste \u00e0 configurer les r\u00e8gles d'\u00e9quilibrage au point d'\u00e9change, ce dont nous discuterons un peu plus tard.
    \nUne complexit\u00e9 suppl\u00e9mentaire est \u00e9galement apparue : le contr\u00f4leur pub-sub et le planificateur de t\u00e2ches personnalis\u00e9 doivent fonctionner en une seule instance. Encore une fois, le service de messagerie, en tant que fondamental, doit fournir un m\u00e9canisme de choix d'un leader.<\/p>\n

    <\/p>\n

    Choix du leader<\/h3>\n

    <\/p>\n

    Dans les syst\u00e8mes distribu\u00e9s, le choix d'un leader est la proc\u00e9dure d'attribution d'un seul processus responsable de la planification du traitement distribu\u00e9 d'une charge donn\u00e9e. <\/p>\n

    <\/p>\n

    Dans les syst\u00e8mes peu enclins \u00e0 la centralisation, des algorithmes universels et des algorithmes bas\u00e9s sur le consensus, tels que paxos ou raft, sont utilis\u00e9s.
    \n\u00c9tant donn\u00e9 que la messagerie est un courtier et un \u00e9l\u00e9ment central, elle conna\u00eet tous les contr\u00f4leurs de service - candidats au leadership. La messagerie peut d\u00e9signer un leader sans vote.<\/p>\n

    <\/p>\n

    Tous les services, apr\u00e8s leur d\u00e9marrage et leur connexion au point d'\u00e9change, re\u00e7oivent un message syst\u00e8me #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}<\/code>. Dans le cas o\u00f9 LeaderPid<\/code> co\u00efncide avec pid<\/code> le processus actuel, il est d\u00e9sign\u00e9 comme leader, et la liste Servers<\/code> comprend tous les n\u0153uds et leurs param\u00e8tres.
    \nLorsqu'un nouveau n\u0153ud de cluster est ajout\u00e9 et qu'un n\u0153ud fonctionnel est d\u00e9sactiv\u00e9, tous les contr\u00f4leurs de service re\u00e7oivent #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts}<\/code> et #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts}<\/code> respectivement.<\/p>\n

    <\/p>\n

    Ainsi, tous les composants sont au courant de tous les changements, et dans le cluster, il y a toujours un leader assur\u00e9 \u00e0 tout moment.<\/p>\n

    <\/p>\n

    Interm\u00e9diaires<\/h2>\n

    <\/p>\n

    Pour mettre en \u0153uvre des processus de traitement distribu\u00e9s complexes, ainsi que pour optimiser une architecture existante, il est pratique d'utiliser des interm\u00e9diaires.
    \nPour ne pas modifier le code des services et r\u00e9soudre, par exemple, des t\u00e2ches de traitement suppl\u00e9mentaire, de routage ou de journalisation des messages, un gestionnaire proxy peut \u00eatre int\u00e9gr\u00e9 devant le service, qui effectuera tout le travail suppl\u00e9mentaire.<\/p>\n

    <\/p>\n

    Un exemple classique d'optimisation pub-sub est une application distribu\u00e9e avec un noyau m\u00e9tier g\u00e9n\u00e9rant des \u00e9v\u00e9nements de mise \u00e0 jour, comme un changement de prix sur le march\u00e9, et une couche d'acc\u00e8s \u2014 N serveurs fournissant une API websocket pour les clients web.
    \nSi l'on consid\u00e8re la situation de mani\u00e8re directe, le service client se d\u00e9roule comme suit :<\/p>\n

    <\/p>\n