Свет не стаіць на месцы. Прагрэс стварае новыя тэхналагічныя выклікі. У адпаведнасці з якія змяніліся патрабаваннямі, павінна эвалюцыянаваць і архітэктура інфармацыйных сістэм. Сёння мы будзем казаць пра падзейна-арыентаваную архітэктуру, канкурэнтнасць, паралельнасць, асінхроннасць і пра тое, як у Erlang можна з усім гэтым жыць мірна.
Увядзенне
У залежнасці ад памераў праектаванай сістэмы і патрабаванняў да яе, мы, распрацоўшчыкі, выбіраемы спосаб абмену інфармацыяй у сістэме. У большасці выпадкаў, для арганізацыі ўзаемадзеяння сэрвісаў працоўным варыянтам можа быць схема з брокерам, напрыклад на аснове RabbitMQ ці kafka. Але часам паток падзей, SLA і ўзровень кантролю над сістэмай такія, што гатовы messaging нам не падыходзіць. Вядома, можна крыху ўскладніць сістэму, узяўшы адказнасць за транспартны ўзровень і фарміраванне кластара, напрыклад выкарыстоўваючы ZeroMQ або nanomsg. Але калі сістэме хапае прапускной здольнасці і магчымасцяў стандартнага Erlang кластара, тое пытанне занясення дадатковай сутнасці патрабуе падрабязнага вывучэння і эканамічнага абгрунтавання.
Тэма рэактыўных размеркаваных дадаткаў даволі шырокая. Каб укласціся ў фармат артыкула, прадметам сённяшняга абмеркавання будуць толькі гамагенныя асяроддзі, пабудаваныя на аснове Erlang/Elixir. Экасістэма Erlang/OTP дазваляе рэалізаваць рэактыўную архітэктуру з найменшымі працавыдаткамі. Але ў любым выпадку нам спатрэбіцца пласт абмену паведамленнямі.
Тэарэтычны базіс
Праектаванне пачынаецца з вызначэння мэт і абмежаванняў. Асноўная мэта не знаходзіцца ў галіне распрацоўкі дзеля распрацоўкі. Нам неабходна атрымаць бяспечную і якая маштабуецца прылада, на аснове якога можна ствараць, а самае галоўнае – развіваць сучасныя прыкладанні рознага ўзроўня: пачынальна ад аднасерверных, якія абслугоўваюць невялікую аўдыторыю, якія ў далейшым могуць развіцца ў кластары да 50-60 вузлоў, сканчаючы федэрацыямі кластараў. Такім чынам асноўная мэта - максімізацыя прыбытку шляхам скарачэння кошту распрацоўкі і валодання выніковай сістэмай.
Вылучым 4 галоўныя патрабаванні да выніковай сістэмы:
- Сабыццёвая арыентаванасць.
Сістэма заўсёды гатова прапускаць праз сябе паток падзей і рабіць неабходныя дзеянні; - Масштабавальнасць.
Асобныя блокі могуць маштабавацца як вертыкальна, так і гарызантальна. Уся сістэма павінна мець магчымасць бясконцага гарызантальнага росту; - Отканінаўстойлівасць.
Усе ўзроўні і ўсе сэрвісы павінны мець магчымасць аўтаматычнага аднаўлення пры збоях; - Гарантаваны час водгуку.
Час каштоўна і карыстачы не павінны чакаць занадта доўга.
Памятаеце старую казку пра “The little engine that could”, ён жа – “Паравозік, які здолеў”? Каб праектаваная сістэма паспяхова выйшла са стадыі прататыпа і была прагрэсіўнай, яе падмурак павінен задавальняць мінімальным патрабаванням. ЗМОГ.
Да messaging як да інфраструктурнай прылады і базісу для ўсіх сэрвісаў дадаецца яшчэ адзін пункт: выгода выкарыстання для праграмістаў.
Арыентаванасць на падзеі
Каб прыкладанне магло вырасці з аднаго сервера да кластара, яго архітэктура павінна забяспечваць слабую злучанасць. Гэтаму патрабаванню адказвае асінхронная мадэль. У ёй адпраўнік і атрымальнік клапоцяцца аб інфармацыйнай нагрузцы паведамлення і не турбуюцца за перадачу і маршрутызацыю ўнутры сістэмы.
маштабаванасць
Маштабаванасць і эфектыўнасць сістэмы стаяць побач. Кампаненты прыкладання павінны ўмець утылізаваць усе даступныя рэсурсы. Чым больш эфектыўна мы можам утылізаваць магутнасці і чым аптымальней нашы метады апрацоўкі, тым менш мы трацім грошай на абсталяванне.
У рамках адной машыны Erlang стварае высокаканкурэнтнае асяроддзе. Баланс паміж канкурэнтнасцю і раўналежнасцю можна задаць выбарам колькасці струменяў аперацыйнай сістэмы даступных для Erlang VM і лікам планавальнікаў утылізуюць гэтыя струмені.
Erlang працэсы не маюць агульнага стану і працуюць у неблакіруючым рэжыме. Гэта забяспечвае параўнальна нізкую латэнтнасць і больш высокую прапускную здольнасць, чым у традыцыйных прыкладанняў пабудаваных на блакіруючай сінхранізацыі. Планавальнік Erlang клапоціцца аб справядлівым размеркаванні CPU і IO, а адсутнасць блакіровак дазваляе з дадаткам адказваць нават у рэжыме пікавых нагрузак або збояў.
На ўзроўні кластара праблема з утылізацыяй таксама існуе. Важна, каб усе машыны ў кластары былі раўнамерна нагружаны, а сетка не перагружана. Прадстаўляльны сітуацыю: карыстацкі трафік прызямляецца на ўваходныя балансавальнікі (haproxy, nginx, etc), яны максімальна раўнамерна размяркоўваюць запыты на апрацоўку паміж наборам даступных бэкэндаў. У рамках інфраструктуры прыкладання сэрвіс, які рэалізуе патрабаваны інтэрфейс, - гэта толькі апошняя міля, і яму трэба будзе запытаць шэраг іншых сэрвісаў, каб адказаць на першапачатковы запыт. Унутраныя запыты таксама патрабуюць маршрутызацыі і балансаванні.
Каб эфектыўна кіраваць струменямі дадзеных, messaging павінен падаваць распрацоўнікам інтэрфейс для кіравання маршрутызацыяй і размеркаваннем нагрузкі. Дзякуючы гэтаму, распрацоўнікі змогуць, выкарыстаючы мікрасэрвісныя патэрны (aggregator, proxy, chain, branch, etc), вырашаць як стандартныя задачы, так і рэдка якія ўзнікаюць.
З пункту гледжання бізнесу, маштабаванасць - адзін з інструментаў кіравання рызыкамі. Галоўнае задаволіць запыты кліентаў, аптымальна выкарыстоўваючы абсталяванне:
- Пры павелічэнні магутнасці абсталявання ў выніку прагрэсу. Яно не будзе прастойваць з-за недасканаласці ПЗ. Erlang выдатна маштабуецца вертыкальна і заўсёды зможа ўтылізаваць усе ядры CPU і даступную памяць;
- Ва ўмовах хмарных асяроддзяў, мы можам кіраваць колькасцю абсталявання ў залежнасці ад бягучай або прагназуемай нагрузкі і гарантаваць SLA.
адмоваўстойлівасць
Разгледзім дзве аксіёмы: "Адмовы недапушчальныя" і "Адмовы будуць заўсёды". Для бізнесу адмова ПЗ - страта грошай, а што горш - рэпутацыі. Балансуючы паміж магчымымі стратамі і коштам распрацоўкі адмоваўстойлівага ПЗ, часта можна знайсці кампраміс.
У кароткатэрміновай перспектыве архітэктура, у якой закладзена адмоваўстойлівасць, эканоміць грошы на куплі гатовых рашэнняў кластарызацыі. Яны каштуюць дорага, і ў іх таксама ёсць памылкі.
У доўгатэрміновай, адмоваўстойлівая архітэктура шматразова акупляе выдаткі на яе прымяненне на ўсіх этапах распрацоўкі.
Messaging усярэдзіне кодавай базы яшчэ на этапе распрацоўкі дазваляе дэталёва прапрацаваць узаемадзеянне кампанентаў усярэдзіне сістэм. Гэтым спрашчаецца задача рэагавання і кіраванні збоямі, бо ўсе адказныя кампаненты апрацоўваюць збоі, а выніковая сістэма ведае, як аўтаматычна вярнуцца ў штатны стан пасля збою by design.
Спагадлівасць
Незалежна ад збояў, прыкладанне павінна адказваць на запыты і задавальняць SLA. Рэальнасць такая, што людзі не жадаюць чакаць, адпаведна бізнэс павінен падстроіцца. Ад усё большай колькасці прыкладанняў чакаюць высокай спагадлівасці.
Спагадлівыя прыкладанні працуюць у рэжыме, набліжаным да рэальнага часу. Erlang VM функцыянуе ў рэжыме мяккага рэальнага часу. Для некаторых абласцей, такіх як біржавы гандаль, медыцына, кіраванне прамысловым абсталяваннем, важны рэжым жорсткага рэальнага часу.
Спагадлівыя сістэмы паляпшаюць UX і карысныя бізнэсу.
папярэдні вынік
Плануючы дадзены артыкул, я жадаў падзяліцца досведам стварэння брокера абмену паведамленнямі і пабудовай на яго аснове складаных сістэм. Але тэарэтычная і матывацыйная частка атрымалася даволі шырокай.
У другой частцы артыкула я раскажу пра нюансы рэалізацыі пунктаў абмену, шаблоны абмену паведамленнямі і іх ужыванне.
У трэцяй частцы разгледзім агульныя пытанні арганізацыі сэрвісаў, маршрутызацыі і балансаванні. Пагаворым аб практычным баку маштабаванасці і адмоваўстойлівасці сістэм.
Канец першай часткі.
Фота .
Крыніца: habr.com