Грађевински блокови дистрибуираних апликација. Нулта апроксимација

Свет не стоји мирно. Напредак ствара нове технолошке изазове. У складу са променљивим захтевима, архитектура информационих система мора да се развија. Данас ћемо причати о архитектури вођеној догађајима, истовремености, истовремености, асинхронији и о томе како можете мирно да живите са свим овим у Ерлангу.

Увод

У зависности од величине пројектованог система и захтева за њега, ми, програмери, бирамо начин размене информација у систему. У већини случајева, за организовање интеракције услуга, радна опција може бити шема са брокером, на пример, заснована на РаббитМК или кафки. Али понекад су ток догађаја, СЛА и ниво контроле над системом такви да нам готове поруке не одговарају. Наравно, можете мало искомпликовати систем преузимањем одговорности за транспортни слој и формирање кластера, на пример коришћењем ЗероМК или наномсг. Али ако систем има довољну пропусност и могућности стандардног Ерланг кластера, онда питање увођења додатног ентитета захтева детаљну студију и економско оправдање.

Тема реактивних дистрибуираних апликација је прилично широка. Да би се одржао у оквиру формата чланка, предмет данашње расправе биће само хомогена окружења изграђена на Ерланг/Еликир-у. Ерланг/ОТП екосистем вам омогућава да имплементирате реактивну архитектуру уз најмање напора. Али у сваком случају, биће нам потребан слој за размену порука.

Теоријска основа

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

Дозволите да истакнемо 4 главна захтева за коначни систем:

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

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

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

Оријентисан на догађаје

Да би апликација прерасла из једног сервера у кластер, њена архитектура мора да подржава лабаво повезивање. Асинхрони модел испуњава овај захтев. У њему, пошиљалац и прималац брину о информационом оптерећењу поруке и не брину о преносу и рутирању унутар система.

Прилагодљивост

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

Унутар једне машине, Ерланг ствара високо конкурентно окружење. Равнотежа између конкурентности и паралелизма се може поставити избором броја нити оперативног система доступних Ерланг ВМ-у и броја планера који користе ове нити.
Ерланг процеси не деле стање и раде у неблокирајућем режиму. Ово обезбеђује релативно ниско кашњење и већу пропусност од традиционалних апликација заснованих на блокирању. Ерлангов планер обезбеђује поштену алокацију ЦПУ-а и ИО-а, а одсуство блокирања омогућава апликацији да реагује чак и током вршног оптерећења или кварова.

На нивоу кластера такође постоји проблем са одлагањем. Важно је да све машине у кластеру буду равномерно оптерећене и да мрежа није преоптерећена. Замислимо ситуацију: кориснички саобраћај пада на долазне балансере (хапроки, нгинк, итд.), они дистрибуирају захтеве за обраду што је равномерније могуће између скупа доступних позадина. Унутар инфраструктуре апликације, услуга која имплементира захтевани интерфејс је само последња миља и мораће да захтева низ других услуга да одговори на почетни захтев. Интерни захтеви такође захтевају рутирање и балансирање.
Да би се ефикасно управљало токовима података, размена порука мора да обезбеди програмерима интерфејс за управљање рутирањем и балансирањем оптерећења. Захваљујући томе, програмери ће моћи да, користећи микросервисне обрасце (агрегатор, проки, ланац, грана, итд.), решавају и стандардне проблеме и оне који се ретко јављају.

Са пословне тачке гледишта, скалабилност је један од алата за управљање ризиком. Главна ствар је задовољити захтеве купаца оптималним коришћењем опреме:

• Када се снага опреме повећа као резултат напретка. Неће бити у стању мировања због несавршеног софтвера. Ерланг добро скалира вертикално и увек ће моћи да искористи сва ЦПУ језгра и доступну меморију;
• У Цлоуд окружењима можемо управљати количином опреме у зависности од тренутног или предвиђеног оптерећења и гарантовати СЛА.

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

Размотримо два аксиома: „Неуспеси су неприхватљиви“ и „Увек ће бити неуспеха“. За посао, неуспјех софтвера значи губитак новца, и што је још горе, губитак репутације. Балансирајући између могућих губитака и трошкова развоја софтвера отпорног на грешке, често се може наћи компромис.

Краткорочно гледано, архитектура која укључује толеранцију грешака штеди новац на куповини готових решења за кластерисање. Они су скупи и такође имају грешке.
Дугорочно гледано, архитектура отпорна на грешке се вишеструко исплати у свим фазама развоја.
Размена порука унутар базе кода вам омогућава да детаљно разрадите интеракцију компоненти унутар система у фази развоја. Ово поједностављује задатак реаговања и управљања кваровима, пошто све критичне компоненте рукују кваровима, а резултујући систем зна како да се аутоматски врати у нормалу након квара по дизајну.

Респонсивенесс

Без обзира на неуспјехе, апликација мора одговорити на захтјеве и испунити СЛА. Реалност је да људи не желе да чекају, па се предузећа морају прилагодити томе. Очекује се да ће све више апликација имати висок одзив.
Прилагодљиве апликације раде у скоро реалном времену. Ерланг ВМ ради у меком режиму у реалном времену. За неке области, као што су трговина акцијама, медицина и контрола индустријске опреме, важан је режим рада у реалном времену.
Респонзивни системи побољшавају УКС и користе послу.

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

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

Крај првог дела.

Фотографија @луцабраво.

Извор: ввв.хабр.цом