🥇Taqsimlangan ilovalarning qurilish bloklari. Ikkinchi yaqinlashish

E'lon

Hamkasblar, yoz o'rtalarida men navbat tizimlarini loyihalash bo'yicha yana bir qator maqolalar chiqarishni rejalashtirmoqdaman: "VTrade eksperimenti" - savdo tizimlari uchun asos yozishga urinish. Seriyada birja, auktsion va do'kon qurish nazariyasi va amaliyoti ko'rib chiqiladi. Maqolaning oxirida sizni qiziqtirgan mavzularga ovoz berishga taklif qilaman.

Bu Erlang/Elixir-dagi taqsimlangan reaktiv ilovalar seriyasining yakuniy maqolasi. IN birinchi maqola reaktiv arxitekturaning nazariy asoslarini topishingiz mumkin. Ikkinchi maqola bunday tizimlarni qurishning asosiy naqshlari va mexanizmlarini ko'rsatadi.

Bugun biz kodlar bazasini va umuman loyihalarni rivojlantirish masalalarini ko'taramiz.

Xizmatlarni tashkil etish

Haqiqiy hayotda, xizmatni ishlab chiqishda siz ko'pincha bir kontrollerda bir nechta o'zaro ta'sir modellarini birlashtirishingiz kerak bo'ladi. Misol uchun, loyiha foydalanuvchi profillarini boshqarish muammosini hal qiladigan foydalanuvchilar xizmati req-resp so'rovlariga javob berishi va pub-sub orqali profil yangilanishi haqida xabar berishi kerak. Bu holat juda oddiy: xabar almashishning orqasida xizmat mantig'ini amalga oshiradigan va yangilanishlarni nashr etadigan bitta boshqaruvchi mavjud.

Xatolarga chidamli taqsimlangan xizmatni amalga oshirish kerak bo'lganda, vaziyat yanada murakkablashadi. Tasavvur qilaylik, foydalanuvchilar uchun talablar o'zgargan:

endi xizmat 5 ta klaster tugunlarida so'rovlarni qayta ishlashi kerak,
fonni qayta ishlash vazifalarini bajara olish,
Shuningdek, profil yangilanishlari uchun obuna ro‘yxatlarini dinamik boshqarish imkoniyatiga ega bo‘lish.

Eslatma: Biz izchil saqlash va ma'lumotlarni takrorlash masalasini ko'rib chiqmaymiz. Aytaylik, bu muammolar avvalroq hal qilingan va tizim allaqachon ishonchli va kengaytiriladigan saqlash qatlamiga ega va ishlovchilar u bilan o'zaro ta'sir qilish mexanizmlariga ega.

Foydalanuvchilar xizmatining rasmiy tavsifi yanada murakkablashdi. Dasturchi nuqtai nazaridan, xabar almashishdan foydalanish tufayli o'zgarishlar minimaldir. Birinchi talabni qondirish uchun biz req-resp almashish nuqtasida muvozanatni sozlashimiz kerak.

Fon vazifalarini qayta ishlash talabi tez-tez uchraydi. Foydalanuvchilarda bu foydalanuvchi hujjatlarini tekshirish, yuklab olingan multimediyani qayta ishlash yoki ma'lumotlarni ijtimoiy media bilan sinxronlashtirish bo'lishi mumkin. tarmoqlar. Bu vazifalar qandaydir tarzda klaster ichida taqsimlanishi va bajarilish jarayonini kuzatishi kerak. Shuning uchun bizda ikkita yechim varianti bor: oldingi maqoladagi topshiriqlarni taqsimlash shablonidan foydalaning yoki agar u mos kelmasa, protsessorlar pulini bizga kerak bo'lgan tarzda boshqaradigan maxsus topshiriq rejalashtiruvchisini yozing.

3-band pub-sub shablonini kengaytirishni talab qiladi. Va amalga oshirish uchun, pub-sub almashish nuqtasini yaratgandan so'ng, biz xizmatimiz doirasida ushbu nuqta boshqaruvchisini qo'shimcha ravishda ishga tushirishimiz kerak. Shunday qilib, biz obunalarni qayta ishlash va obunani bekor qilish mantiqini xabarlar qatlamidan foydalanuvchilarni amalga oshirishga o'tkazayotgandek bo'lamiz.

Natijada, muammoning parchalanishi talablarni qondirish uchun turli tugunlarda xizmatning 5 ta nusxasini ishga tushirishimiz va obuna uchun mas'ul bo'lgan qo'shimcha ob'ekt - pub-sub kontrollerni yaratishimiz kerakligini ko'rsatdi.
5 ta ishlov beruvchini ishga tushirish uchun xizmat kodini o'zgartirish shart emas. Faqatgina qo'shimcha harakat - bu almashinuv punktida muvozanat qoidalarini o'rnatish, bu haqda biroz keyinroq gaplashamiz.
Bundan tashqari, qo'shimcha murakkablik mavjud: pub-sub boshqaruvchisi va maxsus topshiriq rejalashtiruvchisi bitta nusxada ishlashi kerak. Shunga qaramay, xabar almashish xizmati asosiy xizmat sifatida rahbarni tanlash mexanizmini ta'minlashi kerak.

Rahbarning tanlovi

Taqsimlangan tizimlarda etakchini tanlash - bu ba'zi yuklarni taqsimlangan qayta ishlashni rejalashtirish uchun mas'ul bo'lgan yagona jarayonni tayinlash tartibi.

Markazlashtirishga moyil bo'lmagan tizimlarda paxos yoki raft kabi universal va konsensusga asoslangan algoritmlar qo'llaniladi.
Xabar almashish broker va markaziy element bo'lganligi sababli, u barcha xizmat boshqaruvchilari - nomzod rahbarlar haqida biladi. Xabarlar ovoz berishsiz rahbarni tayinlashi mumkin.

Ayirboshlash nuqtasini ishga tushirgandan va ulangandan so'ng, barcha xizmatlar tizim xabarini oladi #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. Agar LeaderPid bilan mos keladi pid joriy jarayon, u rahbar sifatida tayinlanadi, va ro'yxati Servers barcha tugunlarni va ularning parametrlarini o'z ichiga oladi.
Ayni paytda yangisi paydo bo'ladi va ishlaydigan klaster tugunlari uziladi, barcha xizmat boshqaruvchilari #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} mos ravishda.

Shunday qilib, barcha komponentlar barcha o'zgarishlardan xabardor bo'ladi va klaster istalgan vaqtda bitta etakchiga ega bo'lishi kafolatlanadi.

Vositachilar

Murakkab taqsimlangan qayta ishlash jarayonlarini amalga oshirish uchun, shuningdek, mavjud arxitekturani optimallashtirish muammolarida vositachilardan foydalanish qulay.
Xizmat kodini o'zgartirmaslik va masalan, qo'shimcha ishlov berish, marshrutlash yoki xabarlarni qayd qilish muammolarini hal qilmaslik uchun siz barcha qo'shimcha ishlarni bajaradigan xizmatdan oldin proksi-serverni yoqishingiz mumkin.

Pub-sub optimallashtirishning klassik namunasi - bozordagi narxlar o'zgarishi kabi yangilanish hodisalarini yaratuvchi biznes yadrosi va veb-mijozlar uchun veb-mijozlar uchun veb-soket API-ni ta'minlovchi kirish qatlami - N serverlari bo'lgan taqsimlangan dastur.
Agar siz to'g'ridan-to'g'ri qaror qilsangiz, mijozlarga xizmat ko'rsatish quyidagicha ko'rinadi:

mijoz platforma bilan aloqa o'rnatadi. Trafikni to'xtatuvchi server tomonida ushbu ulanishga xizmat ko'rsatish jarayoni boshlanadi.
Xizmat ko'rsatish jarayoni kontekstida avtorizatsiya va yangilanishlarga obuna bo'ladi. Jarayon mavzular uchun obuna usulini chaqiradi.
Yadroda hodisa hosil bo'lgach, u ulanishlarga xizmat ko'rsatadigan jarayonlarga yetkaziladi.

Tasavvur qilaylik, bizda "yangiliklar" mavzusiga 50000 5 obunachi bor. Abonentlar 50000 ta serverga teng taqsimlangan. Natijada, almashinuv punktiga kelgan har bir yangilanish 10000 XNUMX marta takrorlanadi: har bir serverda undagi obunachilar soniga qarab XNUMX XNUMX marta. Juda samarali sxema emas, to'g'rimi?
Vaziyatni yaxshilash uchun almashish nuqtasi bilan bir xil nomga ega proksi-serverni joriy qilaylik. Global nom registratori eng yaqin jarayonni nomi bilan qaytarishi kerak, bu muhim.

Keling, ushbu proksi-serverni kirish qatlami serverlarida ishga tushiraylik va bizning websocket api-ga xizmat qiluvchi barcha jarayonlar yadrodagi asl pub-sub almashish nuqtasiga emas, balki unga obuna bo'ladi. Proksi yadroga faqat noyob obuna bo'lgan taqdirda obuna bo'ladi va kiruvchi xabarni barcha obunachilarga takrorlaydi.
Natijada yadro va kirish serverlari o'rtasida 5 50000 ta o'rniga XNUMX ta xabar yuboriladi.

Marshrutlash va muvozanatlash

Talab - Javob

Joriy xabar almashish amaliyotida 7 ta so'rovni tarqatish strategiyasi mavjud:

default. So'rov barcha nazoratchilarga yuboriladi.
round-robin. So'rovlar sanab o'tiladi va nazoratchilar o'rtasida tsiklik taqsimlanadi.
consensus. Xizmatga xizmat qiluvchi nazoratchilar rahbarlar va qullarga bo'linadi. So'rovlar faqat rahbarga yuboriladi.
consensus & round-robin. Guruhning rahbari bor, lekin so'rovlar barcha a'zolar o'rtasida taqsimlanadi.
sticky. Xesh funktsiyasi hisoblab chiqiladi va ma'lum bir ishlov beruvchiga tayinlanadi. Ushbu imzo bilan keyingi so'rovlar xuddi shu ishlov beruvchiga o'tadi.
sticky-fun. Almashtirish nuqtasini ishga tushirganda, uchun hash hisoblash funktsiyasi sticky muvozanatlash.
fun. Yopishqoq-kulgiga o'xshab, faqat siz uni qo'shimcha ravishda qayta yo'naltirishingiz, rad etishingiz yoki oldindan ishlov berishingiz mumkin.

Tarqatish strategiyasi almashinuv nuqtasi ishga tushirilganda o'rnatiladi.

Balanslashdan tashqari, xabar almashish ob'ektlarni belgilash imkonini beradi. Tizimdagi teglar turlarini ko'rib chiqamiz:

Ulanish yorlig'i. Voqealar qaysi aloqa orqali sodir bo'lganligini tushunishga imkon beradi. Tekshirish jarayoni bir xil almashish nuqtasiga ulanganda, lekin turli marshrutlash kalitlari bilan foydalaniladi.
Xizmat belgisi. Ishlovchilarni bitta xizmat uchun guruhlarga birlashtirish va marshrutlash va muvozanatlash imkoniyatlarini kengaytirish imkonini beradi. Req-resp namunasi uchun marshrutlash chiziqli. Biz so'rovni almashinuv punktiga yuboramiz, keyin u uni xizmatga o'tkazadi. Ammo ishlov beruvchilarni mantiqiy guruhlarga bo'lish kerak bo'lsa, u holda bo'linish teglar yordamida amalga oshiriladi. Tegni belgilashda so'rov ma'lum bir nazoratchilar guruhiga yuboriladi.
So'rov yorlig'i. Javoblarni farqlash imkonini beradi. Tizimimiz asinxron bo'lgani uchun xizmat javoblarini qayta ishlash uchun so'rov yuborishda RequestTag ni ko'rsatishimiz kerak. Undan bizga qaysi so'rovga javob kelganini tushunishimiz mumkin bo'ladi.

Pub-sub

Pub-sub uchun hamma narsa biroz sodda. Bizda xabarlar e'lon qilinadigan almashinuv punktimiz bor. Ayirboshlash punkti o'zlariga kerakli marshrutlash kalitlariga obuna bo'lgan abonentlar o'rtasida xabarlarni tarqatadi (bu mavzularga o'xshash deb aytishimiz mumkin).

Masshtablilik va xatolarga chidamlilik

Butun tizimning miqyosliligi tizim qatlamlari va tarkibiy qismlarining miqyoslilik darajasiga bog'liq:

Ushbu xizmat uchun ishlov beruvchilar bilan klasterga qo'shimcha tugunlar qo'shish orqali xizmatlar masshtablanadi. Sinov paytida siz optimal muvozanat siyosatini tanlashingiz mumkin.
Alohida klasterdagi xabar almashish xizmatining o'zi odatda alohida yuklangan almashinuv nuqtalarini alohida klaster tugunlariga ko'chirish yoki proksi-server jarayonlarini klasterning alohida yuklangan joylariga qo'shish orqali kengaytiriladi.
Butun tizimning xarakteristikasi sifatida miqyosi arxitekturaning moslashuvchanligi va alohida klasterlarni umumiy mantiqiy ob'ektga birlashtirish qobiliyatiga bog'liq.

Loyihaning muvaffaqiyati ko'pincha masshtablashning soddaligi va tezligiga bog'liq. Uning joriy versiyasida xabarlar ilova bilan birga o'sib boradi. Bizda 50-60 ta mashinadan iborat klaster yetishmasa ham, federatsiyaga murojaat qilishimiz mumkin. Afsuski, federatsiya mavzusi ushbu maqola doirasidan tashqarida.

Rezervasyon

Yukni muvozanatlashni tahlil qilganda, biz allaqachon xizmat boshqaruvchilarining ortiqchaligini muhokama qildik. Biroq, xabarlar ham zaxiralangan bo'lishi kerak. Tugun yoki mashina ishdan chiqqan taqdirda, xabarlar avtomatik ravishda va eng qisqa vaqt ichida tiklanishi kerak.

Loyihalarimda yiqilib tushganda yukni ko'taradigan qo'shimcha tugunlardan foydalanaman. Erlang OTP ilovalari uchun standart taqsimlangan rejimga ega. Taqsimlangan rejim, avvaldan ishga tushirilgan boshqa tugunda muvaffaqiyatsiz dasturni ishga tushirish orqali muvaffaqiyatsizlikka uchragan taqdirda tiklashni amalga oshiradi. Jarayon shaffof; nosozlikdan so'ng dastur avtomatik ravishda uzilish tuguniga o'tadi. Ushbu funksiya haqida ko'proq o'qishingiz mumkin shu yerda.

unumdorlik

Keling, hech bo'lmaganda rabbitmq va bizning shaxsiy xabar almashishimizni taxminan solishtirishga harakat qilaylik.
Men topdim rasmiy natijalar Openstack jamoasidan rabbitmq testi.

6.14.1.2.1.2.2-bandda. Asl hujjat RPC CAST natijasini ko'rsatadi:

Biz oldindan OS yadrosi yoki erlang VM uchun qo'shimcha sozlamalarni o'tkazmaymiz. Sinov shartlari:

erl opts: +A1 +sbtu.
Bitta erlang tugunidagi test mobil versiyada eski i7 o'rnatilgan noutbukda o'tkaziladi.
Klaster testlari 10G tarmog'iga ega serverlarda o'tkaziladi.
Kod docker konteynerlarida ishlaydi. NAT rejimida tarmoq.

Test kodi:

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.

1-stsenariy: Sinov eski i7 mobil versiyasiga ega noutbukda o'tkaziladi. Sinov, xabar almashish va xizmat bitta Docker konteyneridagi bitta tugunda amalga oshiriladi:

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)

Stsenariy 2: Docker (NAT) ostidagi turli mashinalarda ishlaydigan 3 ta tugun.

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)

Barcha holatlarda protsessordan foydalanish 250% dan oshmadi.

natijalar

Umid qilamanki, bu tsikl aql bovar qilmaydigan narsaga o'xshamaydi va mening tajribam taqsimlangan tizimlar tadqiqotchilari uchun ham, biznes tizimlari uchun taqsimlangan arxitekturani yaratishning boshida turgan va Erlang/Eliksirga qiziqish bilan qaraydigan amaliyotchilar uchun ham haqiqiy foyda keltiradi. , lekin bunga arziydimi, shubhangiz bor ...

foto @chuttersnap

So'rovda faqat ro'yxatdan o'tgan foydalanuvchilar ishtirok etishlari mumkin. tizimga kirishiltimos.

VTrade Experiment seriyasining bir qismi sifatida qanday mavzularni batafsilroq yoritishim kerak?

Nazariya: Bozorlar, buyurtmalar va ularning vaqti: DAY, GTD, GTC, IOC, FOK, MOO, MOC, LOO, LOC
Buyurtmalar kitobi. Guruhlar bilan kitobni amalga oshirish nazariyasi va amaliyoti
Savdoning vizualizatsiyasi: Shomillar, barlar, rezolyutsiyalar. Qanday saqlash va qanday yopishtirish kerak
Backoffice. Rejalashtirish va rivojlantirish. Xodimlarni kuzatish va hodisalarni tekshirish
API. Keling, qanday interfeyslar kerakligini va ularni qanday amalga oshirish kerakligini aniqlaylik
Ma'lumotni saqlash: savdo tizimlarida PostgreSQL, Timescale, Tarantool
Savdo tizimlarida reaktivlik
Boshqa. Izohlarda yozaman

6 nafar foydalanuvchi ovoz berdi. 4 nafar foydalanuvchi betaraf qolgan.

Manba: www.habr.com

Tarqalgan ilovalarning qurilish bloklari. Ikkinchi taxmin