🥇Pagtukod mga bloke sa gipang-apod-apod nga mga aplikasyon. Ikaduha nga gibanabana

Pagpahibalo

Mga kauban, sa tunga-tunga sa ting-init nagplano ako nga buhian ang laing serye sa mga artikulo sa disenyo sa mga sistema sa pagpila: "Ang Eksperimento sa VTrade" - usa ka pagsulay sa pagsulat sa usa ka balangkas alang sa mga sistema sa pamatigayon. Susihon sa serye ang teorya ug praktis sa pagtukod og exchange, subasta ug tindahan. Sa katapusan sa artikulo, gidapit ko ikaw sa pagboto alang sa mga hilisgutan nga labing nakapainteres kanimo.

Kini ang katapusang artikulo sa serye sa gipang-apod-apod nga mga reaktibo nga aplikasyon sa Erlang/Elixir. SA unang artikulo makit-an nimo ang teoretikal nga pundasyon sa reaktibo nga arkitektura. Ikaduhang artikulo nag-ilustrar sa sukaranang mga sumbanan ug mekanismo sa paghimo sa maong mga sistema.

Karon atong ipataas ang mga isyu sa pagpalambo sa code base ug mga proyekto sa kinatibuk-an.

Organisasyon sa mga serbisyo

Sa tinuud nga kinabuhi, kung nagpalambo ka usa ka serbisyo, kanunay nimo kinahanglan nga maghiusa sa daghang mga pattern sa interaksyon sa usa ka controller. Pananglitan, ang serbisyo sa mga tiggamit, nga nagsulbad sa problema sa pagdumala sa mga profile sa tiggamit sa proyekto, kinahanglan nga motubag sa mga hangyo sa req-resp ug magreport sa mga update sa profile pinaagi sa pub-sub. Kini nga kaso yano ra: luyo sa pagmemensahe adunay usa ka controller nga nagpatuman sa lohika sa serbisyo ug nagpatik sa mga update.

Ang sitwasyon mahimong mas komplikado kung kinahanglan namon nga ipatuman ang usa ka fault-tolerant nga gipang-apod-apod nga serbisyo. Hunahunaa nga ang mga kinahanglanon alang sa mga tiggamit nausab:

karon ang serbisyo kinahanglan nga magproseso sa mga hangyo sa 5 cluster nodes,
makahimo sa paghimo sa mga buluhaton sa pagproseso sa background,
ug mahimo usab nga dinamikong pagdumala sa mga lista sa suskrisyon alang sa mga update sa profile.

Komento: Wala namo tagda ang isyu sa makanunayon nga pagtipig ug pagkopya sa datos. Atong isipon nga kini nga mga isyu nasulbad na sa sayo pa ug ang sistema aduna nay kasaligan ug scalable nga storage layer, ug ang mga tigdumala adunay mga mekanismo sa pagpakig-uban niini.

Ang pormal nga paghulagway sa serbisyo sa tiggamit nahimong mas komplikado. Gikan sa punto sa panglantaw sa programmer, ang mga pagbag-o gamay ra tungod sa paggamit sa pagmemensahe. Aron matagbaw ang unang kinahanglanon, kinahanglan natong i-configure ang pagbalanse sa req-resp exchange point.

Ang kinahanglanon sa pagproseso sa mga buluhaton sa background kanunay mahitabo. Sa mga tiggamit, kini mahimong pagsusi sa mga dokumento sa tiggamit, pagproseso sa na-download nga multimedia, o pag-synchronize sa datos sa social media. mga network. Kini nga mga buluhaton kinahanglan nga ipang-apod-apod sa sulod sa cluster ug ang pag-uswag sa pagpatuman gibantayan. Busa, kami adunay duha ka mga kapilian sa solusyon: bisan ang paggamit sa template sa pag-apod-apod sa buluhaton gikan sa miaging artikulo, o, kung dili kini angay, pagsulat usa ka naandan nga scheduler sa buluhaton nga magdumala sa pool sa mga processor sa paagi nga kinahanglan namon.

Ang punto 3 nagkinahanglan sa pub-sub template extension. Ug alang sa pagpatuman, pagkahuman sa paghimo sa usa ka pub-sub exchange point, kinahanglan namon nga dugang nga ilunsad ang controller sa kini nga punto sa sulod sa among serbisyo. Sa ingon, ingon nga gibalhin namon ang lohika alang sa pagproseso sa mga suskrisyon ug pag-unsubscribe gikan sa layer sa pagmemensahe ngadto sa pagpatuman sa mga tiggamit.

Ingon usa ka sangputanan, ang pagkadunot sa problema nagpakita nga aron matubag ang mga kinahanglanon, kinahanglan namon nga ilunsad ang 5 nga mga higayon sa serbisyo sa lainlaing mga node ug maghimo usa ka dugang nga entidad - usa ka pub-sub controller, nga responsable sa suskrisyon.
Aron makadagan ang 5 nga tigdumala, dili nimo kinahanglan usbon ang code sa serbisyo. Ang bugtong dugang nga aksyon mao ang pagpahimutang sa mga lagda sa pagbalanse sa exchange point, nga atong hisgutan sa ulahi.
Adunay usab usa ka dugang nga pagkakomplikado: ang pub-sub controller ug custom task scheduler kinahanglan nga magtrabaho sa usa ka kopya. Sa makausa pa, ang serbisyo sa pagmemensahe, isip usa ka sukaranan, kinahanglan maghatag usa ka mekanismo sa pagpili sa usa ka lider.

Pagpili sa lider

Sa mga sistema nga gipang-apod-apod, ang pagpili sa lider mao ang pamaagi sa pagtudlo sa usa ka proseso nga responsable sa pag-iskedyul sa giapod-apod nga pagproseso sa pipila ka load.

Sa mga sistema nga dili hilig sa sentralisasyon, ang universal ug consensus-based nga mga algorithm, sama sa paxos o raft, gigamit.
Tungod kay ang pagmemensahe usa ka broker ug sentro nga elemento, nahibal-an niini ang bahin sa tanan nga tigkontrol sa serbisyo - mga lider sa kandidato. Ang pagmemensahe makatudlo ug lider nga walay pagbotar.

Human magsugod ug magkonektar sa exchange point, ang tanang serbisyo makadawat og mensahe sa sistema #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. Kung LeaderPid dungan sa pid kasamtangan nga proseso, kini gitudlo ingon nga lider, ug ang listahan Servers naglakip sa tanan nga mga node ug sa ilang mga parameter.
Sa higayon nga adunay usa ka bag-o nga makita ug ang usa ka nagtrabaho nga cluster node nadiskonekta, ang tanan nga mga tigdumala sa serbisyo makadawat #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} sumala niana.

Niining paagiha, ang tanan nga mga sangkap nahibal-an sa tanan nga mga pagbag-o, ug ang cluster gigarantiyahan nga adunay usa ka lider sa bisan unsang oras.

Mga tigpataliwala

Aron ipatuman ang komplikado nga gipang-apod-apod nga mga proseso sa pagproseso, maingon man sa mga problema sa pag-optimize sa usa ka kasamtangan nga arkitektura, sayon nga gamiton ang mga tigpataliwala.
Aron dili mabag-o ang code sa serbisyo ug masulbad, pananglitan, ang mga problema sa dugang nga pagproseso, pag-ruta o pag-log sa mga mensahe, mahimo nimong mapalihok ang usa ka proxy handler sa wala pa ang serbisyo, nga maghimo sa tanan nga dugang nga trabaho.

Usa ka klasiko nga pananglitan sa pag-optimize sa pub-sub mao ang usa ka giapod-apod nga aplikasyon nga adunay usa ka kinauyokan sa negosyo nga nagpatunghag mga panghitabo sa pag-update, sama sa mga pagbag-o sa presyo sa merkado, ug usa ka layer sa pag-access - N nga mga server nga naghatag usa ka websocket API alang sa mga kliyente sa web.
Kung magdesisyon ka nga direkta, nan ang serbisyo sa kostumer ingon niini:

ang kliyente nagtukod og mga koneksyon sa plataporma. Sa kilid sa server nga nagtapos sa trapiko, usa ka proseso ang gilunsad aron maserbisyohan kini nga koneksyon.
Sa konteksto sa proseso sa serbisyo, ang pagtugot ug pag-subscribe sa mga update mahitabo. Ang proseso nagtawag sa pamaagi sa pag-subscribe alang sa mga hilisgutan.
Sa higayon nga mabuhat ang usa ka panghitabo sa kernel, ihatud kini sa mga proseso nga nagserbisyo sa mga koneksyon.

Hunahunaa nga kita adunay 50000 nga mga subscriber sa "balita" nga hilisgutan. Ang mga subscriber giapod-apod nga parehas sa 5 nga mga server. Ingon usa ka sangputanan, ang matag pag-update, nga moabut sa exchange point, pagasundon sa 50000 ka beses: 10000 ka beses sa matag server, sumala sa gidaghanon sa mga subscriber niini. Dili kaayo epektibo nga pamaagi, di ba?
Aron mapaayo ang sitwasyon, atong ipaila ang usa ka proxy nga adunay parehas nga ngalan sa exchange point. Ang global name registrar kinahanglan nga makabalik sa pinakaduol nga proseso pinaagi sa ngalan, kini importante.

Atong ilunsad kini nga proxy sa mga access layer server, ug ang tanan natong mga proseso nga nagserbisyo sa websocket api mo-subscribe niini, ug dili sa orihinal nga pub-sub exchange point sa kernel. Ang proxy nag-subscribe sa kinauyokan lamang sa kaso sa usa ka talagsaon nga suskrisyon ug gikopya ang umaabot nga mensahe sa tanan nga mga subscriber niini.
Isip resulta, 5 ka mensahe ang ipadala tali sa kernel ug access server, imbes 50000.

Pag-ruta ug pagbalanse

Req-Resp

Sa kasamtangan nga pagpatuman sa mensahe, adunay 7 nga mga pamaagi sa pag-apod-apod sa hangyo:

default. Ang hangyo gipadala sa tanan nga mga controller.
round-robin. Ang mga hangyo gi-enumerate ug cyclically-apod-apod tali sa mga controllers.
consensus. Ang mga tigkontrol nga nagserbisyo sa serbisyo gibahin sa mga lider ug mga ulipon. Ang mga hangyo ipadala lamang sa lider.
consensus & round-robin. Ang grupo adunay usa ka lider, apan ang mga hangyo giapod-apod sa tanan nga mga miyembro.
sticky. Ang hash function gikalkulo ug gi-assign sa usa ka piho nga handler. Ang sunod nga mga hangyo nga adunay kini nga pirma moadto sa parehas nga tigdumala.
sticky-fun. Sa pagsugod sa exchange point, ang hash kalkulasyon function alang sa sticky pagbalanse.
fun. Sama sa sticky-fun, mahimo ra nimo nga dugang nga i-redirect, isalikway o iproseso kini.

Ang estratehiya sa pag-apod-apod gitakda kung ang exchange point gisugdan.

Dugang sa pagbalanse, ang pagmemensahe nagtugot kanimo sa pag-tag sa mga entidad. Atong tan-awon ang mga tipo sa mga tag sa sistema:

Tag sa koneksyon. Nagtugot kanimo nga masabtan kung diin ang koneksyon miabut. Gigamit kung ang usa ka proseso sa controller magkonektar sa parehas nga punto sa pagbinayloay, apan adunay lainlaing mga yawe sa ruta.
Tag sa serbisyo. Nagtugot kanimo sa paghiusa sa mga tigdumala ngadto sa mga grupo alang sa usa ka serbisyo ug pagpalapad sa routing ug pagbalanse nga kapabilidad. Alang sa req-resp pattern, ang routing kay linear. Nagpadala kami usa ka hangyo sa exchange point, dayon kini ipasa sa serbisyo. Apan kung kinahanglan naton bahinon ang mga tigdumala sa mga lohikal nga grupo, nan ang pagbulag gihimo gamit ang mga tag. Kung nagpiho sa usa ka tag, ang hangyo ipadala sa usa ka piho nga grupo sa mga tigkontrol.
Nangayo tag. Nagtugot kanimo sa pag-ila tali sa mga tubag. Tungod kay ang among sistema kay asynchronous, aron maproseso ang mga tubag sa serbisyo kinahanglan namon nga matino ang usa ka RequestTag kung magpadala usa ka hangyo. Gikan niini atong masabtan ang tubag kung unsang hangyo ang miabut kanato.

Pub-sub

Alang sa pub-sub ang tanan mas simple. Kami adunay usa ka exchange point diin ang mga mensahe gipatik. Ang exchange point nag-apod-apod sa mga mensahe sa mga subscriber nga nag-subscribe sa mga routing key nga ilang gikinahanglan (mahimo natong isulti nga kini susama sa mga hilisgutan).

Scalability ug fault tolerance

Ang scalability sa sistema sa kinatibuk-an nagdepende sa lebel sa scalability sa mga layer ug mga sangkap sa sistema:

Ang mga serbisyo gi-scale pinaagi sa pagdugang og dugang nga mga node sa cluster nga adunay mga tigdumala niini nga serbisyo. Atol sa pagsulay nga operasyon, mahimo nimong pilion ang kamalaumon nga palisiya sa pagbalanse.
Ang serbisyo sa pagmemensahe mismo sulod sa usa ka bulag nga cluster kasagarang gi-scale pinaagi sa pagbalhin sa partikular nga loaded exchange point ngadto sa pagbulag sa cluster nodes, o pinaagi sa pagdugang sa proxy nga mga proseso ngadto sa partikular nga loaded nga mga lugar sa cluster.
Ang scalability sa tibuok sistema isip usa ka kinaiya nagdepende sa pagka-flexible sa arkitektura ug ang abilidad sa paghiusa sa indibidwal nga mga cluster ngadto sa usa ka komon nga lohikal nga entidad.

Ang kalampusan sa usa ka proyekto kanunay nagdepende sa kayano ug katulin sa pag-scale. Ang pagmemensahe sa kasamtangang bersyon niini motubo uban sa aplikasyon. Bisag kuwang ta og cluster nga 50-60 ka mga makina, makadangop ta sa federation. Ikasubo, ang hilisgutan sa pederasyon lapas sa sakup niini nga artikulo.

Pagpareserba

Kung nag-analisar sa pagbalanse sa load, nahisgutan na namo ang redundancy sa mga service controller. Bisan pa, ang pagmemensahe kinahanglan usab nga ireserba. Sa panghitabo sa usa ka node o machine crash, messaging kinahanglan nga awtomatikong mabawi, ug sa pinakamubo nga posible nga panahon.

Sa akong mga proyekto naggamit ko og dugang nga mga node nga mokuha sa load kung matumba. Ang Erlang adunay usa ka standard distributed mode nga pagpatuman alang sa mga aplikasyon sa OTP. Ang gi-apod-apod nga mode naghimo sa pagbawi kung adunay kapakyasan pinaagi sa paglansad sa napakyas nga aplikasyon sa lain nga gilusad kaniadto nga node. Ang proseso mao ang transparent; human sa usa ka kapakyasan, ang aplikasyon awtomatikong mobalhin ngadto sa failover node. Mahimo nimong mabasa ang dugang bahin sa kini nga pag-andar dinhi.

Pag-uswag

Atong sulayan nga ikumpara ang performance sa rabbitmq ug ang atong naandan nga pagmemensahe.
Nakit-an nako opisyal nga mga resulta rabbitmq testing gikan sa openstack team.

Sa parapo 6.14.1.2.1.2.2. Ang orihinal nga dokumento nagpakita sa resulta sa RPC CAST:

Dili kami maghimo ug bisan unsang dugang nga mga setting sa OS kernel o erlang VM nga abante. Mga kondisyon sa pagsulay:

erl nagpili: +A1 +sbtu.
Ang pagsulay sulod sa usa ka erlang node gipadagan sa usa ka laptop nga adunay daan nga i7 sa mobile nga bersyon.
Ang mga pagsulay sa kumpol gihimo sa mga server nga adunay 10G network.
Ang code nagdagan sa mga sudlanan sa docker. Network sa NAT mode.

Test code:

req_resp_bench(_) ->
  W = perftest:comprehensive(10000,
    fun() ->
      messaging:request(?EXCHANGE, default, ping, self()),
      receive
        #'$msg'{message = pong} -> ok
      after 5000 ->
        throw(timeout)
      end
    end
  ),
  true = lists:any(fun(E) -> E >= 30000 end, W),
  ok.

Sitwasyon 1: Ang pagsulay gipadagan sa usa ka laptop nga adunay daan nga i7 nga mobile nga bersyon. Ang pagsulay, pagmemensahe ug serbisyo gipatuman sa usa ka node sa usa ka sudlanan sa Docker:

Sequential 10000 cycles in ~0 seconds (26987 cycles/s)
Sequential 20000 cycles in ~1 seconds (26915 cycles/s)
Sequential 100000 cycles in ~4 seconds (26957 cycles/s)
Parallel 2 100000 cycles in ~2 seconds (44240 cycles/s)
Parallel 4 100000 cycles in ~2 seconds (53459 cycles/s)
Parallel 10 100000 cycles in ~2 seconds (52283 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (49317 cycles/s)

Scenario 2: 3 nodes nga nagdagan sa lain-laing mga makina ubos sa docker (NAT).

Sequential 10000 cycles in ~1 seconds (8684 cycles/s)
Sequential 20000 cycles in ~2 seconds (8424 cycles/s)
Sequential 100000 cycles in ~12 seconds (8655 cycles/s)
Parallel 2 100000 cycles in ~7 seconds (15160 cycles/s)
Parallel 4 100000 cycles in ~5 seconds (19133 cycles/s)
Parallel 10 100000 cycles in ~4 seconds (24399 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (34517 cycles/s)

Sa tanan nga mga kaso, ang paggamit sa CPU dili molapas sa 250%

Mga resulta

Nanghinaut ko nga kini nga siklo dili sama sa usa ka hunahuna nga dump ug ang akong kasinatian mahimong tinuod nga kaayohan sa mga tigdukiduki sa gipang-apod-apod nga mga sistema ug mga practitioner nga anaa sa sinugdanan sa pagtukod sa gipang-apod-apod nga mga arkitektura alang sa ilang mga sistema sa negosyo ug nagtan-aw sa Erlang/Elixir uban ang interes. , apan adunay mga pagduha-duha kung kini ba angay ...

litrato @chuttersnap

Ang mga rehistradong tiggamit lamang ang makaapil sa survey. Sign in, walay sapayan.

Unsa nga mga hilisgutan ang kinahanglan nakong tabonan sa mas detalyado isip bahin sa serye sa Eksperimento sa VTrade?

Teorya: Mga merkado, mga order ug ilang timing: DAY, GTD, GTC, IOC, FOK, MOO, MOC, LOO, LOC
Libro sa mga mando. Teorya ug praktis sa pagpatuman sa usa ka libro nga adunay mga grupo
Visualization sa trading: Ticks, bar, resolusyon. Sa unsa nga paagi sa pagtipig ug sa unsa nga paagi sa papilit
Backoffice. Pagplano ug kalamboan. Pag-monitor sa empleyado ug imbestigasyon sa insidente
API. Atong mahibal-an kung unsa nga mga interface ang gikinahanglan ug kung giunsa kini ipatuman
Pagtipig sa impormasyon: PostgreSQL, Timescale, Tarantool sa mga sistema sa pamatigayon
Reaktibidad sa mga sistema sa pamatigayon
Ang uban. Isulat ko sa mga komento

6 ka tiggamit ang miboto. 4 ka tiggamit ang nag- abstain.

Source: www.habr.com

Mga bloke sa pagtukod sa gipang-apod-apod nga mga aplikasyon. Ikaduha nga pagbanabana