{"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\/da\/blog\/administrirovanie\/stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie","title":{"rendered":"Bygningsblokke for distribuerede applikationer. Andet n\u00e6rmere kig","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

<\/p>\n

Kollegaer, midt p\u00e5 sommeren planl\u00e6gger jeg at udgive endnu en r\u00e6kke artikler om design af systemer til massebetjening: \u201cEksperiment VTrade\u201d \u2014 et fors\u00f8g p\u00e5 at skrive et framework til handelssystemer. I serien vil teorien og praksis for opbygning af en b\u00f8rs, auktion og butik blive dr\u00f8ftet. I slutningen af artiklen foresl\u00e5r jeg at stemme om de emner, der interesserer jer mest.
\n<\/em><\/p>\n

<\/p>\n

\"Bygningsblokke<\/p>\n

<\/p>\n

Dette er den afsluttende artikel i r\u00e6kken om distribuerede reaktive applikationer p\u00e5 Erlang\/Elixir. I den f\u00f8rste artikel<\/a><\/noindex> kan man finde de teoretiske grundlag for reaktiv arkitektur. Den anden artikel<\/a><\/noindex> illustrerer de grundl\u00e6ggende m\u00f8nstre og mekanismer til opbygning af s\u00e5danne systemer.<\/p>\n

<\/p>\n

I dag vil vi tage fat p\u00e5 sp\u00f8rgsm\u00e5l ang\u00e5ende udviklingen af kodebasen og projekterne generelt. <\/p>\n

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

Organisering af tjenester<\/h2>\n

<\/p>\n

I det virkelige liv, n\u00e5r man udvikler en tjeneste, m\u00e5 man ofte forene flere interaktionsm\u00f8nstre i \u00e9n controller. For eksempel skal tjenesten users, som l\u00f8ser opgaver med at administrere brugerprofiler for projektet, h\u00e5ndtere foresp\u00f8rgsler req-resp og informere om opdateringer af profiler gennem pub-sub. Denne situation er ret simpel: for messaging st\u00e5r der \u00e9n controller, som implementerer logikken for tjenesten og offentligg\u00f8r opdateringer.<\/p>\n

<\/p>\n

Situationen bliver mere kompliceret, n\u00e5r vi skal implementere en fejltolerant distribueret tjeneste. Antag, at kravene til users er \u00e6ndret: <\/p>\n

<\/p>\n

    \n
  1. nu skal tjenesten h\u00e5ndtere foresp\u00f8rgsler p\u00e5 5 noder i klyngen, <\/li>\n
  2. have mulighed for at udf\u00f8re baggrundsbehandlingsopgaver, <\/li>\n
  3. samt v\u00e6re i stand til dynamisk at administrere lister over abonnementer p\u00e5 opdateringer af profiler.<\/li>\n<\/ol>\n

    <\/p>\n

    Bem\u00e6rk:<\/em> Sp\u00f8rgsm\u00e5let om konsistent lagring og replikering af data vil vi ikke behandle. Antag, at disse sp\u00f8rgsm\u00e5l er blevet l\u00f8st tidligere, og at systemet allerede har et p\u00e5lideligt og skalerbart lag for lagring, og at handlere har mekanismer til interaktion med det.<\/p>\n

    <\/p>\n

    Det formelle beskrivelser af tjenesten users er blevet mere kompliceret. Set fra programm\u00f8rens perspektiv, takket v\u00e6re brugen af messaging, er \u00e6ndringerne minimale. For at im\u00f8dekomme det f\u00f8rste krav skal vi konfigurere belastningsbalancering ved udvekslingspunktet req-resp. <\/p>\n

    <\/p>\n

    Kravet for behandling af baggrundsopgaver opst\u00e5r ofte. I users kan dette v\u00e6re kontrol af brugerens dokumenter, behandling af uploadet multimedie, eller synkronisering af data med sociale medier. Disse opgaver skal p\u00e5 en eller anden m\u00e5de fordeles inden for klyngen og kontroleres. Derfor har vi to l\u00f8sningsmuligheder: enten bruge skabelonen til opgavefordeling fra den tidligere artikel, eller, hvis den ikke passer, skrive en brugerdefineret opgavestyrer, der p\u00e5 den n\u00f8dvendige m\u00e5de skal h\u00e5ndtere puljen af behandlere. <\/p>\n

    <\/p>\n

    Punkt 3 kr\u00e6ver en udvidelse af pub-sub skabelonen. Og for at implementere dette, efter oprettelsen af pub-sub udvekslingspunktet, skal vi yderligere starte controllere for dette punkt inden for vores service. S\u00e5dan set tager vi som om logikken for behandling af abonnementer og afmeldinger ud af messaging-laget og ind i implementationen af users.<\/p>\n

    <\/p>\n

    Som et resultat viste dekompositionen af opgaven, at for at opfylde kravene skal vi k\u00f8re 5 instanser af servicen p\u00e5 forskellige noder og oprette en ekstra enhed \u2013 en pub-sub controller, der er ansvarlig for abonnementet.
    \nFor at starte 5 behandlere kr\u00e6ves der ikke \u00e6ndringer i servicekoden. Den eneste yderligere handling er at konfigurere balanceringsreglerne p\u00e5 udvekslingspunktet, hvilket vi vil tale mere om lidt senere.
    \nDer opstod ogs\u00e5 en ekstra kompleksitet: pub-sub controllere og den brugerdefinerede opgavestyrer skal k\u00f8re i en enkelt instans. Igen, messaging servicen, som det fundamentale element, skal levere en mekanisme til valg af leder.<\/p>\n

    <\/p>\n

    Valg af leder<\/h3>\n

    <\/p>\n

    I distribuerede systemer er valg af leder \u2013 proceduren for udn\u00e6vnelse af en enkelt proces, der er ansvarlig for planl\u00e6gning af distribueret behandling af en eller anden belastning. <\/p>\n

    <\/p>\n

    I systemer, der ikke er tilb\u00f8jelige til centralisering, anvendes universelle algoritmer og konsensusbaserede algoritmer, s\u00e5som Paxos eller Raft.
    \nDa messaging er broker og det centrale element, kender det til alle controllere af servicen \u2013 kandidater til lederskab. Messaging kan udn\u00e6vne en leder uden afholdelse af afstemning.<\/p>\n

    <\/p>\n

    Alle tjenester efter start og tilslutning til udvekslingspunktet modtager en systemmeddelelse #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}<\/code>. I tilf\u00e6lde af at LeaderPid<\/code> stemmer overens med pid<\/code> den nuv\u00e6rende proces, udn\u00e6vnes han som leder, og listen over Servers<\/code> inkluderer alle noder og deres parametre.
    \nN\u00e5r en ny node opst\u00e5r eller en fungerende node i klyngen deaktiveres, modtager alle servicekontrollere #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts}<\/code> og #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts}<\/code> henholdsvis.<\/p>\n

    <\/p>\n

    Dermed er alle komponenter informeret om alle \u00e6ndringer, og der er altid \u00e9n leder i klyngen p\u00e5 ethvert givent tidspunkt.<\/p>\n

    <\/p>\n

    Mellemled<\/h2>\n

    <\/p>\n

    For at implementere komplekse distribuerede behandlingsprocesser samt ved optimering af allerede eksisterende arkitektur kan det v\u00e6re praktisk at anvende mellemled.
    \nFor at undg\u00e5 at \u00e6ndre services koden og for at l\u00f8se f.eks. opgaver som yderligere behandling, routing eller logning af beskeder, kan man aktivere en proxybehandler f\u00f8r servicen, som udf\u00f8rer alt det ekstra arbejde.<\/p>\n

    <\/p>\n

    Et klassisk eksempel p\u00e5 optimalisering af pub-sub er en distribueret applikation med et forretningskerne, der genererer opdateringsbegivenheder, som f.eks. \u00e6ndring af pris p\u00e5 markedet, og et adgangslag - N servere, der tilbyder websocket API til webklienter.
    \nHvis man ser p\u00e5 det direkte, ser betjeningen af klienten s\u00e5ledes ud:<\/p>\n

    <\/p>\n