{"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\/sv\/blog\/administrirovanie\/stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie","title":{"rendered":"Byggstenar f\u00f6r distribuerade applikationer. Andra tillv\u00e4gag\u00e5ngss\u00e4ttet","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Tillk\u00e4nnagivande<\/strong><\/p>\n

<\/p>\n

Kolleger, jag planerar att sl\u00e4ppa en ny serie artiklar om design av massservice-system under mitten av sommaren: \"Experiment VTrade\" \u2014 ett f\u00f6rs\u00f6k att skriva ett ramverk f\u00f6r handelssystem. Serien kommer att g\u00e5 igenom teorin och praktiken f\u00f6r att bygga en b\u00f6rs, auktion och butik. I slutet av artikeln f\u00f6resl\u00e5r jag att vi r\u00f6star p\u00e5 de \u00e4mnen som intresserar er mest.
\n<\/em><\/p>\n

<\/p>\n

\"Byggstenar<\/p>\n

<\/p>\n

Detta \u00e4r den sista artikeln i serien om distribuerade reaktiva applikationer p\u00e5 Erlang\/Elixir. I den f\u00f6rsta artikeln<\/a><\/noindex> kan man hitta de teoretiska grunderna f\u00f6r reaktiv arkitektur. Den andra artikeln<\/a><\/noindex> illustrerar de grundl\u00e4ggande m\u00f6nstren och mekanismerna f\u00f6r att bygga s\u00e5dana system.<\/p>\n

<\/p>\n

Idag kommer vi att ta upp fr\u00e5gor om utvecklingen av kodbasen och projekten som helhet. <\/p>\n

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

Organisering av tj\u00e4nster<\/h2>\n

<\/p>\n

I verkliga livet, vid utvecklingen av en tj\u00e4nst, m\u00e5ste man ofta kombinera flera interaktionsm\u00f6nster i en och samma kontroller. Till exempel, tj\u00e4nsten users, som hanterar anv\u00e4ndarprofiler, b\u00f6r svara p\u00e5 req-resp-f\u00f6rfr\u00e5gningar och meddela om uppdateringar av profiler via pub-sub. Detta fall \u00e4r ganska enkelt: f\u00f6r messaging st\u00e5r en kontroller som implementerar tj\u00e4nstens logik och publicerar uppdateringar.<\/p>\n

<\/p>\n

Situationen kompliceras n\u00e4r vi m\u00e5ste implementera en felresistent distribuerad tj\u00e4nst. L\u00e5t oss anta att kraven p\u00e5 users har \u00e4ndrats: <\/p>\n

<\/p>\n

    \n
  1. nu m\u00e5ste tj\u00e4nsten kunna hantera f\u00f6rfr\u00e5gningar p\u00e5 5 noder i klustret, <\/li>\n
  2. ha m\u00f6jlighet att utf\u00f6ra bakgrundsbehandling, <\/li>\n
  3. samt kunna hantera abonnemangslister f\u00f6r uppdateringar av profiler dynamiskt.<\/li>\n<\/ol>\n

    <\/p>\n

    Anm\u00e4rkning:<\/em> Fr\u00e5gan om konsekvent lagring och replikering av data ska vi inte behandla. L\u00e5t oss anta att dessa fr\u00e5gor har l\u00f6sts tidigare och att det redan finns ett tillf\u00f6rlitligt och skalbart lagringsskikt i systemet, och att hanterarna har mekanismer f\u00f6r att interagera med det.<\/p>\n

    <\/p>\n

    Den formella beskrivningen av tj\u00e4nsten users har blivit mer komplex. Fr\u00e5n programm\u00f6rens perspektiv, tack vare anv\u00e4ndningen av messaging, \u00e4r f\u00f6r\u00e4ndringarna minimala. F\u00f6r att uppfylla det f\u00f6rsta kravet m\u00e5ste vi konfigurera belastningsbalansering vid punktutbytet a req-resp. <\/p>\n

    <\/p>\n

    Kravet p\u00e5 att hantera bakgrundsuppgifter uppst\u00e5r ofta. I anv\u00e4ndarna kan detta vara kontroller av anv\u00e4ndardokument, bearbetning av uppladdad multimedia eller synkronisering av data med sociala n\u00e4tverk. Dessa uppgifter m\u00e5ste f\u00f6rdelas p\u00e5 n\u00e5got s\u00e4tt inom klustret och \u00f6vervakas. D\u00e4rf\u00f6r har vi tv\u00e5 l\u00f6sningar: antingen anv\u00e4nda distributionsmallen fr\u00e5n den tidigare artikeln, eller, om den inte passar, skriva en anpassad uppgiftsplanerare som p\u00e5 det s\u00e4ttet hanterar poolen av bearbetare. <\/p>\n

    <\/p>\n

    Punkt 3 kr\u00e4ver en utvidgning av pub-sub-mallen. F\u00f6r att genomf\u00f6ra detta, efter att ha skapat en pub-sub-b\u00f6rspunkten, beh\u00f6ver vi ocks\u00e5 starta controllern f\u00f6r denna punkt inom v\u00e5r tj\u00e4nst. P\u00e5 s\u00e5 s\u00e4tt flyttar vi logiken f\u00f6r prenumeration och avprenumeration fr\u00e5n meddelandelagret till implementationen av anv\u00e4ndarna.<\/p>\n

    <\/p>\n

    Som ett resultat visade nedbrytningen av uppgiften att f\u00f6r att uppfylla kraven beh\u00f6ver vi k\u00f6ra 5 instanser av tj\u00e4nsten p\u00e5 olika noder och skapa en ytterligare entitet \u2013 en pub-sub-kontroller som ansvarar f\u00f6r prenumerationen.
    \nF\u00f6r att starta 5 bearbetare kr\u00e4vs det inte att \u00e4ndra koden f\u00f6r tj\u00e4nsten. Den enda ytterligare \u00e5tg\u00e4rden \u2013 konfigurera balansregler vid b\u00f6rspunkten, vilket vi kommer att diskutera lite senare.
    \nDet uppstod ocks\u00e5 en ytterligare sv\u00e5righet: pub-sub-kontrollern och den anpassade uppgiftsplaneraren m\u00e5ste arbeta i en enda instans. \u00c5terigen m\u00e5ste meddelandetj\u00e4nsten, som \u00e4r fundamental, ge en mekanism f\u00f6r att v\u00e4lja en ledare.<\/p>\n

    <\/p>\n

    Val av ledare<\/h3>\n

    <\/p>\n

    I distribuerade system \u00e4r valet av ledare \u2013 proceduren att utse en enda process som ansvarar f\u00f6r att planera distribuerad bearbetning av viss belastning. <\/p>\n

    <\/p>\n

    I system som inte \u00e4r ben\u00e4gna till centralisering till\u00e4mpas universella algoritmer och algoritmer baserade p\u00e5 konsensus, s\u00e5som paxos eller raft.
    \nEftersom meddelandetj\u00e4nsten \u00e4r en broker och en central komponent, k\u00e4nner den till alla kontroller av tj\u00e4nsten \u2013 kandidaterna till ledare. Meddelandetj\u00e4nsten kan utse en ledare utan att h\u00e5lla omr\u00f6stning.<\/p>\n

    <\/p>\n

    Alla tj\u00e4nster f\u00e5r efter start och anslutning till b\u00f6rspunkten ett systemmeddelande #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}<\/code>. Om LeaderPid<\/code> \u00f6verensst\u00e4mmer med pid<\/code> den aktuella processen, utses den som ledare, och listan Servers<\/code> inkluderar alla noder och deras parametrar.
    \nVid tillkomsten av en ny och avst\u00e4ngningen av en fungerande nod i klustret, mottar alla tj\u00e4nstkontrollerare #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts}<\/code> och #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts}<\/code> respektive.<\/p>\n

    <\/p>\n

    P\u00e5 s\u00e5 s\u00e4tt k\u00e4nner alla komponenter till alla f\u00f6r\u00e4ndringar, och i klustret garanteras det att en ledare finns vid varje given tidpunkt.<\/p>\n

    <\/p>\n

    Medlare<\/h2>\n

    <\/p>\n

    F\u00f6r att implementera komplexa distribuerade processer f\u00f6r bearbetning samt f\u00f6r att optimera redan befintlig arkitektur \u00e4r det praktiskt att anv\u00e4nda medlare.
    \nF\u00f6r att undvika att \u00e4ndra tj\u00e4nsternas kod och hantera till exempel uppgifter f\u00f6r ytterligare bearbetning, ruttning eller loggning av meddelanden, kan en proxybehandlare inkluderas framf\u00f6r tj\u00e4nsten, som utf\u00f6r hela det ytterligare arbetet.<\/p>\n

    <\/p>\n

    Ett klassiskt exempel p\u00e5 optimering av pub-sub \u00e4r en distribuerad applikation med en aff\u00e4rsk\u00e4rna som genererar uppdateringsh\u00e4ndelser, som f\u00f6r\u00e4ndringar i marknadspriser, och \u00e5tkomstlagret \u2014 N servrar som tillhandah\u00e5ller websocket-API f\u00f6r webklienter.
    \nOm vi l\u00f6ser det \u201drakt p\u00e5\u201d ser kundservicen ut som f\u00f6ljer:<\/p>\n

    <\/p>\n