{"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\/ro\/blog\/administrirovanie\/stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie","title":{"rendered":"Blocurile de baz\u0103 ale aplica\u021biilor distribuite. A doua aproximare","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Anun\u021b<\/strong><\/p>\n

<\/p>\n

Colegi, \u00een mijlocul verii, planific s\u0103 public un nou ciclu de articole despre proiectarea sistemelor de servicii de mas\u0103: \u201eExperimentul VTrade\u201d \u2014 o \u00eencercare de a scrie un cadru pentru sistemele de tranzac\u021bionare. \u00cen acest ciclu, vom analiza teoria \u0219i practica construirii unei burse, a unei licita\u021bii \u0219i a unui magazin. La finalul articolului, propun s\u0103 vot\u0103m pentru cele mai interesante subiecte pentru voi.
\n<\/em><\/p>\n

<\/p>\n

\"Blocurile<\/p>\n

<\/p>\n

Acesta este articolul de \u00eencheiere al ciclului despre aplica\u021biile reactive distribuite folosind Erlang\/Elixir. \u00cen articolul nostru ini\u021bial<\/a><\/noindex> pute\u021bi g\u0103si fundamentele teoretice ale arhitecturii reactive. Al doilea articol<\/a><\/noindex> ilustreaz\u0103 principalele modele \u0219i mecanisme de construire a acestor sisteme.<\/p>\n

<\/p>\n

Ast\u0103zi vom discuta despre dezvoltarea bazei de cod \u0219i a proiectelor \u00een general. <\/p>\n

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

Organizarea serviciilor<\/h2>\n

<\/p>\n

\u00cen via\u021ba real\u0103, c\u00e2nd dezvolt\u0103m un serviciu, adesea trebuie s\u0103 combin\u0103m mai multe modele de interac\u021biune \u00eentr-un singur controler. De exemplu, serviciul de utilizatori, care se ocup\u0103 de gestionarea profilurilor utilizatorilor proiectului, trebuie s\u0103 r\u0103spund\u0103 la cererile req-resp \u0219i s\u0103 anun\u021be actualiz\u0103rile profilurilor prin pub-sub. Acest caz este destul de simplu: pentru messaging exist\u0103 un singur controler care implementa logica serviciului \u0219i public\u0103 actualiz\u0103rile.<\/p>\n

<\/p>\n

Situa\u021bia devine mai complex\u0103 atunci c\u00e2nd trebuie s\u0103 implement\u0103m un serviciu distribuit rezistent la erori. S\u0103 ne imagin\u0103m c\u0103 cerin\u021bele pentru utilizatori s-au schimbat: <\/p>\n

<\/p>\n

    \n
  1. acum serviciul trebuie s\u0103 proceseze cereri pe 5 noduri din cluster, <\/li>\n
  2. s\u0103 aib\u0103 capacitatea de a executa sarcini de fundal pentru procesare, <\/li>\n
  3. \u0219i de asemenea s\u0103 fie capabil s\u0103 gestioneze dinamic listele de abonamente pentru actualiz\u0103rile profilurilor.<\/li>\n<\/ol>\n

    <\/p>\n

    Observa\u021bie:<\/em> Problema stoc\u0103rii consistente \u0219i replic\u0103rii datelor nu o discut\u0103m. S\u0103 presupunem c\u0103 aceste probleme au fost solu\u021bionate anterior \u0219i c\u0103 \u00een sistem exist\u0103 deja un strat de stocare fiabil \u0219i scalabil, iar handlerii au mecanisme de interac\u021biune cu acesta.<\/p>\n

    <\/p>\n

    Descrierea formal\u0103 a serviciului utilizatori s-a complicat. Din perspectiva programatorului, datorit\u0103 utiliz\u0103rii messaging-ului, modific\u0103rile sunt minime. Pentru a satisface prima cerin\u021b\u0103, trebuie s\u0103 configur\u0103m balansarea la punctul de schimb req-resp. <\/p>\n

    <\/p>\n

    Cererea de procesare a sarcinilor de fundal apare frecvent. \u00cen users, acestea pot fi verific\u0103ri ale documentelor utilizatorilor, procesarea multimedia \u00eenc\u0103rcate sau sincronizarea datelor cu re\u021belele sociale. Aceste sarcini trebuie cumva distribuite \u00een cadrul cluster-ului \u0219i controlate \u00een ceea ce prive\u0219te progresul. Prin urmare, avem dou\u0103 op\u021biuni de solu\u021bionare: fie utiliz\u0103m \u0219ablonul de distribu\u021bie a sarcinilor din articolul anterior, fie, dac\u0103 acesta nu se potrive\u0219te, scriem un planificator de sarcini personalizat, care va gestiona grupul de procesatori a\u0219a cum avem nevoie. <\/p>\n

    <\/p>\n

    Punctul 3 necesit\u0103 extinderea \u0219ablonului pub-sub. Iar pentru realizare, dup\u0103 crearea punctului de schimb pub-sub, trebuie s\u0103 pornim suplimentar controlerul acestui punct \u00een cadrul serviciului nostru. Astfel, parc\u0103 scoatem logica de procesare a abon\u0103rii \u0219i dezabon\u0103rii din stratul de messaging \u00een implementarea users.<\/p>\n

    <\/p>\n

    \u00cen cele din urm\u0103, decompunerea sarcinii a ar\u0103tat c\u0103 pentru a satisface cerin\u021bele trebuie s\u0103 pornim pe noduri diferite 5 instan\u021be ale serviciului \u0219i s\u0103 cre\u0103m o entitate suplimentar\u0103 \u2013 controlerul pub-sub, care este responsabil de abonare.
    \nPentru a porni 5 procesatori nu este necesar s\u0103 schimb\u0103m codul serviciului. Singura ac\u021biune suplimentar\u0103 \u2013 configurarea regulilor de echilibrare pe punctul de schimb, despre care vom vorbi mai t\u00e2rziu.
    \nDe asemenea, a ap\u0103rut o complexitate suplimentar\u0103: controlerul pub-sub \u0219i planificatorul de sarcini personalizat trebuie s\u0103 func\u021bioneze \u00eentr-o singur\u0103 instan\u021b\u0103. Din nou, serviciul de messaging, ca element fundamental, trebuie s\u0103 ofere un mecanism pentru alegerea unui lider.<\/p>\n

    <\/p>\n

    Alegerea liderului<\/h3>\n

    <\/p>\n

    \u00cen sistemele distribuite, alegerea liderului este o procedur\u0103 de numire a unui singur proces, responsabil pentru planificarea proces\u0103rii distribuite a unei anumite sarcini. <\/p>\n

    <\/p>\n

    \u00cen sistemele care nu sunt predispuse la centralizare, se utilizeaz\u0103 algoritmi universali \u0219i algoritmi baza\u021bi pe consens, cum ar fi paxos sau raft.
    \nDeoarece messaging este brokerul \u0219i elementul central, el cunoa\u0219te toate controlerele serviciului \u2013 candida\u021bii la pozi\u021bia de lider. Messaging poate numi un lider f\u0103r\u0103 a organiza o votare.<\/p>\n

    <\/p>\n

    Toate serviciile, dup\u0103 ce au fost pornite \u0219i conectate la punctul de schimb, primesc un mesaj sistemic #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}<\/code>. \u00cen cazul \u00een care LeaderPid<\/code> coincide cu pid<\/code> procesul curent, acesta este numit lider, iar lista Servers<\/code> include toate nodurile \u0219i parametrii lor.
    \nAt the moment a new node joins and an active cluster node is disconnected, all service controllers receive #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts}<\/code> \u0219i #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts}<\/code> corespunz\u0103tor.<\/p>\n

    <\/p>\n

    Thus, all components are aware of all changes, and at any given moment, there is guaranteed to be one leader in the cluster.<\/p>\n

    <\/p>\n

    Intermediaries<\/h2>\n

    <\/p>\n

    To implement complex distributed processing processes, as well as in tasks of optimizing the existing architecture, it is convenient to use intermediaries.
    \nTo avoid changing service codes and to handle, for example, tasks of additional processing, routing, or message logging, a proxy handler can be placed before the service, which will perform all the additional work.<\/p>\n

    <\/p>\n

    A classic example of pub-sub optimization is a distributed application with a business core that generates update events, such as price changes in the market, and an access layer \u2014 N servers providing a websocket API for web clients.
    \nIf we tackle it head-on, servicing the client looks as follows:<\/p>\n

    <\/p>\n