26. фебруара одржали смо састанак Апацхе Игните ГреенСоурце, на којем су говорили сарадници пројекта отвореног кода . Важан догађај у животу ове заједнице било је реструктурирање компоненте , што вам омогућава да примените прилагођене микросервисе директно у Игните кластер. Он је на скупу говорио о овом тешком процесу , софтверски инжењер и Апацхе Игните сарадник више од две године.
Почнимо од тога шта је Апацхе Игните уопште. Ово је база података која је дистрибуирано складиште кључева/вредности са подршком за СКЛ, трансакције и кеширање. Поред тога, Игните вам омогућава да примените прилагођене услуге директно у Игните кластер. Програмер има приступ свим алатима које Игните пружа - дистрибуираним структурама података, размјени порука, стримовању, рачунању и мрежи података. На пример, када се користи Дата Грид, проблем администрирања засебне инфраструктуре за складиштење података и, као последица тога, резултујући режијски трошкови нестају.
Користећи Сервице Грид АПИ, можете да примените услугу једноставним навођењем шеме примене и, сходно томе, саме услуге у конфигурацији.
Типично, шема примене је индикација броја инстанци које треба да буду распоређене на чворовима кластера. Постоје две типичне шеме примене. Први је Цлустер Синглетон: у било ком тренутку гарантовано је да ће једна инстанца корисничке услуге бити доступна у кластеру. Други је Ноде Синглетон: једна инстанца услуге је распоређена на сваком чвору кластера.
Корисник такође може одредити број инстанци услуге у целом кластеру и дефинисати предикат за филтрирање одговарајућих чворова. У овом сценарију, сервисна мрежа ће сама израчунати оптималну дистрибуцију за примену услуга.
Поред тога, постоји таква карактеристика као што је Аффинити Сервице. Афинитет је функција која дефинише однос кључева према партицијама и однос страна према чворовима у топологији. Користећи кључ, можете одредити примарни чвор на коме се чувају подаци. На овај начин можете да повежете сопствену услугу са кешом функција кључа и афинитета. Ако се функција афинитета промени, доћи ће до аутоматског прераспоређивања. На овај начин, услуга ће увек бити лоцирана близу података којима треба да манипулише, и, сходно томе, смањиће трошкове приступа информацијама. Ова шема се може назвати неком врстом заједничког рачунарства.
Сада када смо схватили у чему је лепота Сервице Грид-а, хајде да причамо о историји његовог развоја.
Оно што се десило раније
Претходна имплементација Сервице Грид-а била је заснована на Игните-овом трансакционом реплицираном системском кешу. Реч "кеш" у Игните-у се односи на складиштење. Односно, ово није нешто привремено, као што мислите. Упркос чињеници да се кеш реплицира и да сваки чвор садржи цео скуп података, унутар кеша има партиционисану репрезентацију. Ово је због оптимизације складиштења.
Шта се догодило када је корисник желео да примени услугу?
- Сви чворови у кластеру су се претплатили на ажурирање података у складишту користећи уграђени механизам континуираног упита.
- Иницијални чвор, у оквиру трансакције која је извршена за читање, направио је запис у бази података који је садржао конфигурацију услуге, укључујући серијализовану инстанцу.
- Када је обавештен о новом уносу, координатор је израчунао дистрибуцију на основу конфигурације. Добијени објекат је записан назад у базу података.
- Ако је чвор био део дистрибуције, координатор је морао да га примени.
Шта нам није одговарало
У једном тренутку смо дошли до закључка: ово није начин рада са услугама. Било је неколико разлога.
Ако је дошло до грешке током имплементације, онда се то могло сазнати само из логова чвора где се све догодило. Постојала је само асинхрона имплементација, тако да је након враћања контроле кориснику из методе имплементације било потребно неко додатно време за покретање услуге – и за то време корисник није могао ништа да контролише. Да бисмо даље развијали Сервисну мрежу, креирали нове функције, привукли нове кориснике и свима олакшали живот, нешто треба да се промени.
Када смо дизајнирали нову мрежу услуга, пре свега смо желели да обезбедимо гаранцију за синхрону примену: чим би корисник вратио контролу из АПИ-ја, могао је одмах да користи услуге. Такође сам желео да иницијатору дам могућност да се бави грешкама при постављању.
Поред тога, желео сам да поједноставим имплементацију, односно да се удаљим од трансакција и ребаланса. Упркос чињеници да се кеш реплицира и да нема балансирања, проблеми су се појавили током велике имплементације са много чворова. Када се топологија промени, чворови морају да размењују информације, а са великом применом, ови подаци могу имати велику тежину.
Када је топологија била нестабилна, координатор је морао да прерачуна дистрибуцију услуга. И уопште, када морате да радите са трансакцијама на нестабилној топологији, то може довести до грешака које је тешко предвидети.
Проблеми
Шта су то глобалне промене без пратећих проблема? Прва од њих била је промена топологије. Морате схватити да у било ком тренутку, чак иу тренутку постављања услуге, чвор може ући или напустити кластер. Штавише, ако се у тренутку постављања чвор придружи кластеру, биће потребно доследно преносити све информације о услугама на нови чвор. И не говоримо само о ономе што је већ распоређено, већ и о садашњим и будућим распоређивањима.
Ово је само један од проблема који се могу сакупити у посебну листу:
- Како применити статички конфигурисане услуге при покретању чвора?
- Напуштање чвора из кластера - шта учинити ако је чвор хостовао услуге?
- Шта учинити ако се променио координатор?
- Шта учинити ако се клијент поново повеже са кластером?
- Да ли и како треба да се обрађују захтеви за активацију/деактивацију?
- Шта ако су позвали на уништавање кеша, а ми имамо услуге афинитета везане за то?
И то није све.
одлука
Као циљ, одабрали смо Евент Дривен приступ са имплементацијом процесне комуникације помоћу порука. Игните већ имплементира две компоненте које омогућавају чворовима да прослеђују поруке између себе - цоммуницатион-спи и дисцовери-спи.
Цоммуницатион-спи омогућава чворовима да директно комуницирају и прослеђују поруке. Погодан је за слање великих количина података. Дисцовери-спи вам омогућава да пошаљете поруку свим чворовима у кластеру. У стандардној имплементацији, ово се ради помоћу топологије прстена. Постоји и интеграција са Зоокеепер-ом, у овом случају се користи топологија звезда. Још једна важна ствар коју вреди напоменути је да дисцовери-спи даје гаранције да ће порука дефинитивно бити испоручена у исправном редоследу свим чворовима.
Хајде да погледамо протокол распоређивања. Сви кориснички захтеви за примену и поништење се шаљу преко дисцовери-спи. Ово даје следеће гаранције:
- Захтев ће примити сви чворови у кластеру. Ово ће омогућити наставак обраде захтева када се промени координатор. Ово такође значи да ће у једној поруци сваки чвор имати све потребне метаподатке, као што су конфигурација услуге и њена серијализована инстанца.
- Строго редослед испоруке порука помаже у решавању конфигурационих сукоба и конкурентских захтева.
- Пошто се улазак чвора у топологију такође обрађује преко дисцовери-спи, нови чвор ће добити све податке неопходне за рад са сервисима.
Када се прими захтев, чворови у кластеру га потврђују и креирају задатке обраде. Ови задаци се стављају у ред чекања, а затим их обрађује у другој нити од стране засебног радника. Имплементира се на овај начин јер имплементација може потрајати значајно вријеме и неподношљиво одложити скупи ток откривања.
Све захтеве из реда обрађује менаџер распоређивања. Има специјалног радника који извлачи задатак из овог реда и иницијализује га да започне примену. Након тога се дешавају следеће радње:
- Сваки чвор независно израчунава дистрибуцију захваљујући новој детерминистичкој функцији доделе.
- Чворови генеришу поруку са резултатима распоређивања и шаљу је координатору.
- Координатор обједињује све поруке и генерише резултат целог процеса примене, који се шаље преко дисцовери-спи свим чворовима у кластеру.
- Када се добије резултат, процес имплементације се завршава, након чега се задатак уклања из реда.
Нови дизајн вођен догађајима: орг.апацхе.игните.интернал.процессорс.сервице.ИгнитеСервицеПроцессор.јава
Ако дође до грешке током постављања, чвор одмах укључује ову грешку у поруку коју шаље координатору. Након агрегације порука, координатор ће имати информације о свим грешкама током имплементације и послаће ову поруку преко дисцовери-спи. Информације о грешци ће бити доступне на било ком чвору у кластеру.
Сви важни догађаји у Сервисној мрежи се обрађују овим алгоритмом. На пример, промена топологије је такође порука преко дисцовери-спи. И генерално, у поређењу са оним што је било раније, протокол се показао прилично лаганим и поузданим. Довољно да се носи са било којом ситуацијом током распоређивања.
Шта ће се даље дешавати
Сада о плановима. Свака већа промена у пројекту Игните је завршена као иницијатива за побољшање Игните, која се зове ИЕП. Редизајн сервисне мреже такође има ИЕП - са подругљивим насловом „Промена уља у сервисној мрежи”. Али у ствари, нисмо променили моторно уље, већ цео мотор.
Задатке у ИОП-у поделили смо у 2 фазе. Прва је велика фаза, која се састоји од прераде протокола за имплементацију. Већ је укључен у мастер, можете испробати нову мрежу услуга, која ће се појавити у верзији 2.8. Друга фаза укључује многе друге задатке:
- Хот редеплои
- Верзија сервиса
- Повећана толеранција грешака
- Танки клијент
- Алати за праћење и израчунавање различитих метрика
Коначно, можемо да вас посаветујемо о сервисној мрежи за изградњу система високе доступности отпорних на грешке. Такође вас позивамо да нас посетите на и поделите своје искуство. Ваше искуство је заиста важно за заједницу, оно ће вам помоћи да разумете где да се крећете даље, како да развијете компоненту у будућности.
Извор: ввв.хабр.цом