Градежни блокови на дистрибуирани апликации. Нулта приближување

Светот не стои. Напредокот создава нови технолошки предизвици. Во согласност со променливите барања, архитектурата на информациските системи мора да се развива. Денес ќе зборуваме за архитектурата управувана од настани, конкурентност, конкурентност, асинхронија и како можете да живеете мирно со сето ова во Ерланг.

Вовед

Во зависност од големината на дизајнираниот систем и барањата за него, ние, програмерите, го избираме методот на размена на информации во системот. Во повеќето случаи, за организирање на интеракцијата на услугите, работна опција може да биде шема со брокер, на пример, базирана на RabbitMQ или кафка. Но, понекогаш протокот на настани, SLA и нивото на контрола врз системот се такви што готови пораки не ни одговараат. Се разбира, можете малку да го комплицирате системот со преземање одговорност за транспортниот слој и формирањето на кластерот, на пример користејќи ZeroMQ или nanomsg. Но, ако системот има доволно пропусност и можности на стандарден кластер Erlang, тогаш прашањето за воведување дополнителен ентитет бара детално проучување и економска оправданост.

Темата за реактивни дистрибуирани апликации е доста широка. За да се задржи форматот на статијата, тема на денешната дискусија ќе бидат само хомогени средини изградени на Erlang/Elixir. Екосистемот Erlang/OTP ви овозможува да имплементирате реактивна архитектура со најмал напор. Но, во секој случај, ќе ни треба слој за пораки.

Теоретска основа

Дизајнот започнува со дефинирање на цели и ограничувања. Главната цел не е во областа на развојот заради развојот. Треба да добиеме сигурна и скалабилна алатка врз основа на која ќе можеме да креираме и, што е најважно, да развиеме модерни апликации од различни нивоа: почнувајќи од апликации со еден сервер што опслужуваат мала публика, кои подоцна можат да се развијат во кластери до 50 -60 јазли, завршувајќи со кластерски федерации. Така, главната цел е да се максимизира профитот со намалување на трошоците за развој и сопственост на финалниот систем.

Дозволете ни да истакнеме 4 главни барања за финалниот систем:

• Сориентирани кон настани.
  Системот е секогаш подготвен да помине низ текот на настаните и да ги изврши потребните дејства;
• Мприспособливост.
  Поединечните блокови може да се размерат и вертикално и хоризонтално. Целиот систем мора да биде способен за бесконечен хоризонтален раст;
• Отолеранција на грешки.
  Сите нивоа и сите услуги треба да можат автоматски да се опоравуваат од неуспеси;
• Ггарантирано време на одговор.
  Времето е вредно и корисниците не треба да чекаат премногу долго.

Се сеќавате на старата бајка за „Малиот мотор што можеше“? За да може дизајнираниот систем успешно да излезе од фазата на прототип и да биде прогресивен, неговата основа мора да ги исполнува минималните барања СМОГ.

Уште една точка е додадена на пораките како инфраструктурна алатка и основа за сите услуги: леснотија на користење за програмерите.

Ориентиран кон настани

За апликацијата да прерасне од еден сервер во кластер, нејзината архитектура мора да поддржува лабаво спојување. Асинхрониот модел го исполнува ова барање. Во него, испраќачот и примачот се грижат за оптоварувањето со информации на пораката и не се грижат за преносот и рутирањето во системот.

Приспособливост

Приспособливоста и ефикасноста на системот се една до друга. Компонентите на апликацијата мора да бидат способни да ги користат сите достапни ресурси. Колку поефикасно можеме да го искористиме капацитетот и колку е пооптимално нашите методи на обработка, толку помалку пари трошиме на опрема.

Во рамките на една машина, Erlang создава високо конкурентна средина. Рамнотежата помеѓу конкурентноста и паралелизмот може да се постави со избирање на бројот на нишки на оперативниот систем достапни за Erlang VM и бројот на распоредувачи кои ги користат овие нишки.
Erlang процесите не ја делат состојбата и работат во режим на неблокирање. Ова обезбедува релативно мала латентност и поголема пропусност од традиционалните апликации базирани на блокирање. Распоредувачот на Erlang обезбедува правична распределба на процесорот и IO, а отсуството на блокирање овозможува апликацијата да реагира дури и при максимални оптоварувања или дефекти.

На ниво на кластери, постои и проблемот со депонирањето. Важно е сите машини во кластерот да бидат рамномерно оптоварени и мрежата да не е преоптоварена. Ајде да замислиме ситуација: корисничкиот сообраќај се спушта на дојдовните балансери (хапрокси, nginx, итн.), тие ги дистрибуираат барањата за обработка што е можно порамномерно помеѓу множеството достапни задни делови. Во рамките на апликациската инфраструктура, услугата што го имплементира бараниот интерфејс е само последната милја и ќе треба да побара голем број други услуги за да одговори на првичното барање. Внатрешните барања бараат и рутирање и балансирање.
За ефикасно управување со протокот на податоци, пораките мора да им обезбедат на програмерите интерфејс за управување со рутирање и балансирање на оптоварување. Благодарение на ова, програмерите ќе можат, користејќи шеми на микросервис (агрегатор, прокси, синџир, гранка итн.), да ги решат стандардните проблеми и оние што ретко се појавуваат.

Од деловна гледна точка, приспособливоста е една од алатките за управување со ризик. Главната работа е да се задоволат барањата на клиентите со оптимално користење на опремата:

• Кога моќта на опремата се зголемува како резултат на напредок. Нема да биде во мирување поради несовршениот софтвер. Erlang добро се скали вертикално и секогаш ќе може да ги користи сите јадра на процесорот и достапна меморија;
• Во облак околини, можеме да управуваме со количината на опрема во зависност од тековното или предвиденото оптоварување и да гарантираме SLA.

толеранција на грешки

Да разгледаме две аксиоми: „Неуспесите се неприфатливи“ и „Секогаш ќе има неуспеси“. За бизнис, неуспехот на софтверот значи губење на пари, а што е уште полошо, губење на угледот. Балансирање помеѓу можните загуби и трошоците за развој на софтвер толерантен за грешки, често може да се најде компромис.

Краткорочно, архитектурата што вклучува толеранција на грешки заштедува пари за купување решенија за кластерирање кои не се достапни на полица. Скапи се и имаат и бубачки.
Долгорочно, архитектурата толерантна за грешки се плаќа многукратно во сите фази на развој.
Пораки во рамките на базата на код ви овозможува детално да ја разработите интеракцијата на компонентите во системот во фазата на развој. Ова ја поедноставува задачата за одговарање и управување со неуспесите, бидејќи сите критични компоненти се справуваат со дефекти, а добиениот систем знае како автоматски да се врати во нормала по дефект по дизајн.

Одговорност

Без оглед на неуспесите, апликацијата мора да одговори на барањата и да ги исполни SLA. Реалноста е дека луѓето не сакаат да чекаат, па затоа бизнисите мора соодветно да се прилагодат. Се очекува дека сè повеќе апликации ќе имаат голема реакција.
Респонзивните апликации работат речиси во реално време. Erlang VM работи во мек режим во реално време. За некои области, како што се тргувањето со акции, медицината и контролата на индустриската опрема, важен е режимот во реално време.
Одговорните системи го подобруваат UX и имаат корист за бизнисот.

Прелиминарно резиме

Кога го планирав овој напис, сакав да го споделам моето искуство за создавање брокер за пораки и градење комплексни системи врз основа на него. Но, теоретскиот и мотивациониот дел се покажа доста обемен.
Во вториот дел од статијата, ќе зборувам за нијансите на имплементација на точки за размена, обрасци за пораки и нивната примена.
Во третиот дел ќе разгледаме општи прашања за организирање услуги, рутирање и балансирање. Ајде да зборуваме за практичната страна на приспособливоста и толеранцијата на грешки на системите.

Крај на првиот дел.

Фото @lucabravo.

Извор: www.habr.com