Blok wangunan aplikasi disebarkeun. Kira-kira kadua

Bewara

Kolega, dina pertengahan usum panas kuring rencanana ngaleupaskeun runtuyan sejen tina artikel dina desain sistem antrian: "The VTrade Experiment" - usaha nulis kerangka pikeun sistem dagang. Séri bakal nalungtik téori sareng prakték ngeunaan ngawangun bursa, lelang sareng toko. Dina ahir tulisan, kuring ngajak anjeun milih topik anu paling dipikaresep ku anjeun.

Ieu artikel ahir dina séri ngeunaan aplikasi réaktif disebarkeun di Erlang / Elixir. DI artikel munggaran Anjeun tiasa manggihan yayasan téoritis arsitektur réaktif. Artikel kadua ngagambarkeun pola dasar sareng mékanisme pikeun ngawangun sistem sapertos kitu.

Dinten ieu kami baris ngangkat isu ngembangkeun kodeu base jeung proyék sacara umum.

Organisasi jasa

Dina kahirupan nyata, nalika ngembangkeun jasa, anjeun sering kedah ngagabungkeun sababaraha pola interaksi dina hiji controller. Contona, layanan pamaké, nu solves masalah ngatur propil pamaké proyék, kudu ngabales requests req-resp sarta ngalaporkeun apdet profil via pub-sub. Kasus ieu cukup basajan: di tukangeun olahtalatah aya hiji controller nu implements logika jasa jeung publishes apdet.

Kaayaan janten langkung pajeulit nalika urang kedah nerapkeun jasa disebarkeun toleran lepat. Hayu urang ngabayangkeun yén sarat pikeun pamaké geus robah:

1. ayeuna jasa kedah ngolah pamundut dina 5 titik kluster,
2. tiasa ngalaksanakeun tugas ngolah latar tukang,
3. sarta ogé bisa dinamis ngatur daptar langganan pikeun apdet profil.

Catetan: Kami henteu nganggap masalah neundeun konsisten sareng réplikasi data. Hayu urang nganggap yén masalah ieu parantos direngsekeun sateuacana sareng sistemna parantos ngagaduhan lapisan panyimpen anu tiasa dipercaya sareng skalabel, sareng pawang gaduh mékanisme pikeun berinteraksi sareng éta.

Katerangan resmi ngeunaan jasa pangguna parantos langkung rumit. Tina sudut pandang programer, parobahan minimal kusabab panggunaan olahtalatah. Pikeun nyugemakeun sarat munggaran, urang kudu ngonpigurasikeun balancing dina titik bursa req-resp.

Sarat pikeun ngolah tugas tukang sering lumangsung. Dina pangguna, ieu tiasa mariksa dokumén pangguna, ngolah multimedia anu diunduh, atanapi nyinkronkeun data sareng média sosial. jaringan. Tugas-tugas ieu kedah disebarkeun kumaha waé dina kluster sareng kamajuan palaksanaan diawaskeun. Kituna, urang boga dua pilihan solusi: boh ngagunakeun template distribution tugas ti artikel saméméhna, atawa, lamun teu cocog, nulis scheduler tugas custom anu bakal ngatur kolam renang tina prosesor dina cara urang kudu.

Titik 3 merlukeun extension template pub-sub. Sareng pikeun palaksanaan, saatos nyiptakeun titik bursa pub-sub, urang ogé kedah ngaluncurkeun pangendali titik ieu dina jasa kami. Ku kituna, saolah-olah urang mindahkeun logika pikeun ngolah langganan sareng unsubscribe tina lapisan olahtalatah kana palaksanaan pangguna.

Hasilna, dékomposisi masalah nunjukkeun yén pikeun nyumponan sarat, urang kedah ngaluncurkeun 5 instansi jasa dina titik anu béda sareng nyiptakeun éntitas tambahan - controller pub-sub, tanggung jawab langganan.
Pikeun ngajalankeun 5 pawang, anjeun teu kudu ngarobah kodeu jasa. Hiji-hijina tindakan tambahan nyaéta nyetél aturan balancing dina titik bursa, anu bakal urang bahas engké.
Aya ogé pajeulitna tambahan: pub-sub controller sareng penjadwal tugas khusus kedah dianggo dina salinan tunggal. Sakali deui, ladenan olahtalatah, salaku dasar, kedah nyayogikeun mékanisme pikeun milih pamimpin.

Pilihan Pamimpin

Dina sistem anu disebarkeun, pamilihan pamimpin mangrupikeun prosedur pikeun nunjuk prosés tunggal anu tanggung jawab pikeun ngajadwalkeun pamrosésan anu disebarkeun tina sababaraha beban.

Dina sistem anu henteu rawan sentralisasi, algoritma universal sareng dumasar konsensus, sapertos paxos atanapi rakit, dianggo.
Kusabab olahtalatah mangrupikeun calo sareng unsur sentral, éta terang ngeunaan sadaya pengontrol jasa - pamimpin calon. Olahtalatah bisa nunjuk pamingpin tanpa voting.

Saatos ngamimitian sareng nyambung ka titik bursa, sadaya jasa nampi pesen sistem #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. Lamun LeaderPid coincides jeung pid prosés ayeuna, eta diangkat jadi pamingpin, jeung daptar Servers ngawengku sakabéh titik jeung parameter maranéhanana.
Di momen anu anyar muncul sareng titik kluster anu dianggo dipegatkeun, sadaya pangendali jasa nampi #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} sasuai.

Ku cara ieu, sadaya komponén sadar kana sagala parobihan, sareng klaster dijamin gaduh hiji pamimpin iraha waé.

Perantara

Pikeun nerapkeun prosés pamrosésan anu disebarkeun rumit, ogé dina masalah ngaoptimalkeun arsitéktur anu tos aya, langkung saé ngagunakeun perantara.
Dina raraga teu ngarobah kodeu jasa jeung ngajawab, contona, masalah processing tambahan, routing atawa logging talatah, Anjeun bisa ngaktipkeun pawang proxy saméméh layanan, nu bakal ngalakukeun sagala karya tambahan.

Conto klasik tina optimasi pub-sub nyaéta aplikasi anu disebarkeun sareng inti bisnis anu ngahasilkeun acara update, sapertos parobahan harga di pasar, sareng lapisan aksés - server N anu nyayogikeun API websocket pikeun klien wéb.
Upami anjeun mutuskeun langsung, maka layanan palanggan sapertos kieu:

• klien ngadegkeun sambungan kalawan platform nu. Di sisi server anu ngeureunkeun lalu lintas, prosés diluncurkeun pikeun ngalayanan sambungan ieu.
• Dina kontéks prosés jasa, otorisasi sareng langganan apdet lumangsung. Prosésna nyauran metode langganan pikeun topik.
• Sakali kajadian dihasilkeun dina kernel, éta dikirimkeun ka prosés ngalayanan sambungan.

Hayu urang ngabayangkeun yén urang gaduh 50000 palanggan kana topik "warta". Palanggan disebarkeun merata dina 5 server. Hasilna, unggal update, anjog ka titik bursa, bakal replicated 50000 kali: 10000 kali dina unggal server, nurutkeun jumlah palanggan dina eta. Teu skéma pohara efektif, katuhu?
Pikeun ningkatkeun kaayaan, hayu urang ngenalkeun proxy anu gaduh nami anu sami sareng titik bursa. Nu registrar ngaran global kudu bisa mulangkeun prosés pangdeukeutna ku ngaran, ieu penting.

Hayu urang ngaluncurkeun proxy ieu dina server lapisan aksés, sareng sadaya prosés urang ngalayanan websocket api bakal ngalanggan éta, sareng sanés kana titik bursa pub-sub asli dina kernel. Proxy ngalanggan inti ngan dina kasus langganan unik tur réplikasi pesen asup ka sadaya palanggan na.
Hasilna, 5 pesen bakal dikirim antara kernel jeung aksés server, tinimbang 50000.

Routing sarta balancing

Req-Resp

Dina palaksanaan olahtalatah ayeuna, aya 7 strategi distribusi pamundut:

• default. Paménta dikirim ka sadaya pangendali.
• round-robin. Requests anu enumerated na cyclically disebarkeun antara controller.
• consensus. Controllers anu ngawula jasa dibagi kana pamingpin jeung budak. Requests ngan dikirim ka pamingpin.
• consensus & round-robin. grup ngabogaan pamimpin, tapi requests disebarkeun diantara sakabeh anggota.
• sticky. Fungsi hash diitung sareng ditugaskeun ka pawang khusus. Paménta salajengna sareng tandatangan ieu angkat ka pawang anu sami.
• sticky-fun. Nalika initializing titik bursa, fungsi itungan Hash pikeun sticky ngimbangan.
• fun. Sarupa sareng caket-senang, ngan anjeun tiasa ogé alihan, nolak atanapi tos ngolahna.

Strategi distribusi diatur nalika titik bursa ieu initialized.

Salian balancing, olahtalatah ngidinan Anjeun pikeun méré tag entitas. Hayu urang tingali jinis tag dina sistem:

• Tag sambungan. Ngidinan anjeun ngartos kana sambungan anu mana kajadian éta. Dipaké nalika prosés controller nyambung ka titik bursa sarua, tapi kalawan kenop routing béda.
• Tag jasa. Ngidinan anjeun ngagabungkeun pawang kana grup pikeun hiji layanan sareng dilegakeun kamampuan rute sareng kasaimbangan. Pikeun pola req-resp, routing linier. Kami ngirimkeun pamenta ka titik tukeur, teras dikirimkeun kana jasa. Tapi upami urang kedah ngabagi pawang kana kelompok logis, maka pamisahan dilakukeun nganggo tag. Nalika nangtukeun tag, pamundut bakal dikirim ka grup husus controller.
• Ménta tag. Ngidinan anjeun ngabédakeun antara jawaban. Kusabab sistem kami henteu sinkron, pikeun ngolah réspon jasa kami kedah tiasa nangtukeun RequestTag nalika ngirim pamundut. Ti dinya urang bakal tiasa ngartos jawaban kana pamundut nu sumping ka urang.

Pub-sub

Pikeun pub-sub sagalana nyaéta saeutik basajan. Simkuring boga titik bursa nu pesen diterbitkeun. Titik bursa ngadistribusikaeun pesen diantara palanggan anu geus ngalanggan kana konci routing maranéhna butuh (urang bisa disebutkeun yen ieu analog jeung jejer).

Skalabilitas sareng kasabaran kasalahan

Skalabilitas sistem sacara gembleng gumantung kana darajat skalabilitas lapisan sareng komponén sistem:

• Jasa diskalakeun ku nambahkeun titik tambahan kana klaster jeung pawang pikeun layanan ieu. Salila operasi percobaan, Anjeun bisa milih kawijakan kasaimbangan optimal.
• Ladenan olahtalatah sorangan dina klaster misah umumna diskalakeun boh ku mindahkeun titik bursa utamana dimuat kana titik klaster misah, atawa ku nambahkeun prosés proxy ka wewengkon utamana dimuat klaster.
• Skalabilitas sakabéh sistem salaku ciri gumantung kana kalenturan arsitektur jeung kamampuhan pikeun ngagabungkeun klaster individu kana hiji éntitas logis umum.

Kasuksésan proyék sering gumantung kana kesederhanaan sareng laju skala. Olahtalatah dina versi na ayeuna tumuwuh babarengan jeung aplikasi. Malah lamun urang kakurangan klaster 50-60 mesin, urang tiasa Resort ka federasi. Hanjakalna, topik federasi di luar ruang lingkup tulisan ieu.

Reservasi

Nalika nganalisis beban balancing, kami parantos ngabahas redundansi pangendali jasa. Sanajan kitu, olahtalatah ogé kudu ditangtayungan. Upami aya kacilakaan titik atanapi mesin, olahtalatah kedah otomatis pulih, sareng dina waktos anu paling pondok.

Dina proyék-proyék kuring ngagunakeun titik tambahan anu ngangkat beban upami aya ragrag. Erlang ngabogaan palaksanaan mode disebarkeun baku pikeun aplikasi OTP. Modeu disebarkeun ngalakukeun pamulihan upami gagal ku ngaluncurkeun aplikasi anu gagal dina node anu sanés diluncurkeun sateuacana. Prosésna transparan; saatos gagal, aplikasi sacara otomatis pindah ka titik failover. Anjeun tiasa maca langkung seueur ngeunaan fungsionalitas ieu di dieu.

kakuwatan keur ngasilkeun

Hayu urang cobian sahenteuna kasarna ngabandingkeun kinerja rabbitmq sareng olahtalatah khusus urang.
Abdi mendakan hasil resmi nguji rabbitmq ti tim openstack.

Dina paragraf 6.14.1.2.1.2.2. Dokumén asli nunjukkeun hasil tina RPC CAST:

Kami moal ngadamel setélan tambahan kana kernel OS atanapi erlang VM sateuacanna. Kaayaan pikeun nguji:

• erl opts: +A1 +sbtu.
• Tes dina hiji titik erlang tunggal dijalankeun dina laptop sareng i7 heubeul dina versi mobile.
• Tés klaster dilaksanakeun dina server sareng jaringan 10G.
• Kodeu dijalankeun dina wadah docker. Jaringan dina modeu NAT.

Kode tés:

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.

Skénario 1: Tés ieu dijalankeun dina laptop nganggo versi mobile i7 lami. Tes, olahtalatah sareng jasa dieksekusi dina hiji titik dina hiji wadah 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)

Skénario 2: 3 titik ngajalankeun on mesin béda handapeun 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)

Dina sadaya kasus, pamakean CPU henteu langkung ti 250%

hasil

Kuring miharep siklus ieu teu kasampak kawas dump pikiran jeung pangalaman kuring bakal mangpaat nyata duanana peneliti sistem disebarkeun sarta praktisi anu di pisan awal ngawangun arsitéktur disebarkeun pikeun sistem bisnis maranéhanana sarta ningali Erlang / Elixir kalawan dipikaresep. , tapi boga mamang naha éta patut ...

poto @chuttersnap

Ngan pamaké nu kadaptar bisa ilubiung dina survey. Daptar, Punten.

Topik naon anu kuring kedah nutupan langkung rinci salaku bagian tina séri Percobaan VTrade?

• Téori: Pasar, pesenan sareng waktosna: DAY, GTD, GTC, IOC, FOK, MOO, MOC, LOO, LOC

• Buku pesenan. Téori jeung prakték ngalaksanakeun buku kalawan groupings

• Visualisasi dagang: Ticks, bar, resolusi. Kumaha nyimpen jeung kumaha lem

• Kantor tukang. Perencanaan sareng pamekaran. Ngawaskeun pagawe sarta panalungtikan kajadian

• API. Hayu urang terangkeun naon antarmuka anu diperyogikeun sareng kumaha nerapkeunana

• Panyimpen inpormasi: PostgreSQL, Timescale, Tarantool dina sistem perdagangan

• Réaktivitas dina sistem dagang

• Lain. Kuring gé nulis dina komentar

6 pamaké milih. 4 pamaké abstained.

sumber: www.habr.com