На 26 февруари проведохме среща на Apache Ignite GreenSource, на която участниците в проекта с отворен код говориха . Важно събитие в живота на тази общност беше преструктурирането на компонента , което ви позволява да разположите персонализирани микроуслуги директно в Ignite клъстер. Той говори за този труден процес на срещата , софтуерен инженер и сътрудник на Apache Ignite повече от две години.
Нека започнем с това какво е Apache Ignite като цяло. Това е база данни, която е разпределено хранилище за ключ/стойност с поддръжка на SQL, транзакционност и кеширане. Освен това Ignite ви позволява да разположите персонализирани услуги директно в Ignite клъстер. Разработчикът има достъп до всички инструменти, които Ignite предоставя – разпределени структури от данни, съобщения, стрийминг, изчисления и мрежа от данни. Например, когато използвате Data Grid, проблемът с администрирането на отделна инфраструктура за съхранение на данни и, като следствие, произтичащите от това режийни разходи изчезват.
С помощта на API на Service Grid можете да разгърнете услуга, като просто посочите схемата за разгръщане и съответно самата услуга в конфигурацията.
Обикновено схемата за разполагане е индикация за броя на екземплярите, които трябва да бъдат внедрени на клъстерни възли. Има две типични схеми за разгръщане. Първият е Cluster Singleton: по всяко време едно копие на потребителска услуга е гарантирано налично в клъстера. Вторият е Node Singleton: един екземпляр на услугата се разполага на всеки клъстерен възел.
Потребителят може също да посочи броя на екземплярите на услугата в целия клъстер и да дефинира предикат за филтриране на подходящи възли. В този сценарий самата Service Grid ще изчисли оптималното разпределение за внедряване на услуги.
Освен това има такава функция като Affinity Service. Афинитетът е функция, която определя връзката на ключовете към дяловете и връзката на страните към възлите в топологията. С помощта на ключа можете да определите основния възел, на който се съхраняват данните. По този начин можете да асоциирате собствената си услуга с кеш на ключ и функция за афинитет. Ако функцията за афинитет се промени, ще се извърши автоматично пренасочване. По този начин услугата винаги ще бъде разположена близо до данните, които трябва да манипулира, и съответно ще намали разходите за достъп до информация. Тази схема може да се нарече вид съвместно изчисление.
Сега, след като разбрахме каква е красотата на Service Grid, нека поговорим за историята на нейното развитие.
Какво се случи преди
Предишното внедряване на Service Grid се основаваше на транзакционния репликиран системен кеш на Ignite. Думата "кеш" в Ignite се отнася до съхранение. Тоест това не е нещо временно, както си мислите. Въпреки факта, че кешът е репликиран и всеки възел съдържа целия набор от данни, вътре в кеша той има разделено представяне. Това се дължи на оптимизацията на съхранението.
Какво се случи, когато потребителят поиска да внедри услугата?
- Всички възли в клъстера са абонирани за актуализиране на данни в хранилището с помощта на вградения механизъм за непрекъснато запитване.
- Иницииращият възел, при транзакция с ангажимент за четене, направи запис в базата данни, който съдържа конфигурацията на услугата, включително сериализирания екземпляр.
- Когато бъде уведомен за нов запис, координаторът изчислява разпределението въз основа на конфигурацията. Полученият обект беше записан обратно в базата данни.
- Ако даден възел беше част от разпространението, координаторът трябваше да го разположи.
Какво не ни устройваше
В един момент стигнахме до извода, че така не се работи с услуги. Имаше няколко причини.
Ако възникне някаква грешка по време на внедряването, тя може да бъде открита само от регистрационните файлове на възела, където се е случило всичко. Имаше само асинхронно внедряване, така че след връщане на контрола на потребителя от метода за внедряване, беше необходимо известно време за стартиране на услугата - и през това време потребителят не можеше да контролира нищо. За да доразвием Service Grid, да създадем нови функции, да привлечем нови потребители и да улесним живота на всички, нещо трябва да се промени.
Когато проектирахме новата Service Grid, на първо място искахме да осигурим гаранция за синхронно внедряване: веднага щом потребителят върне контрола от API, той може незабавно да използва услугите. Също така исках да дам на инициатора способността да се справя с грешки при внедряването.
Освен това исках да опростя внедряването, а именно да избягам от транзакциите и ребалансирането. Въпреки факта, че кешът се репликира и няма балансиране, възникнаха проблеми по време на голямо внедряване с много възли. Когато топологията се промени, възлите трябва да обменят информация и при голямо внедряване тези данни могат да тежат много.
Когато топологията беше нестабилна, координаторът трябваше да преизчисли разпределението на услугите. И като цяло, когато трябва да работите с транзакции на нестабилна топология, това може да доведе до трудни за предвиждане грешки.
Проблеми
Какво представляват глобалните промени без съпътстващи проблеми? Първият от тях беше промяна в топологията. Трябва да разберете, че във всеки момент, дори в момента на внедряване на услугата, възел може да влезе или да напусне клъстера. Освен това, ако по време на внедряването възелът се присъедини към клъстера, ще е необходимо последователно да се прехвърля цялата информация за услугите към новия възел. И ние говорим не само за това, което вече е внедрено, но и за настоящи и бъдещи внедрявания.
Това е само един от проблемите, които могат да бъдат събрани в отделен списък:
- Как да разположа статично конфигурирани услуги при стартиране на възел?
- Напускане на възел от клъстера - какво да направите, ако възелът хоства услуги?
- Какво да направите, ако координаторът е сменен?
- Какво да направите, ако клиентът се свърже отново с клъстера?
- Трябва ли заявките за активиране/деактивиране да се обработват и как?
- Какво ще стане, ако извикат унищожаване на кеша и ние имаме услуги за афинитет, свързани с това?
И това не е всичко.
Решение
Като цел избрахме подхода, управляван от събития, с внедряване на процесна комуникация чрез съобщения. Ignite вече прилага два компонента, които позволяват на възлите да препращат съобщения помежду си - communication-spi и discovery-spi.
Communication-spi позволява на възлите да комуникират директно и да препращат съобщения. Той е много подходящ за изпращане на големи количества данни. Discovery-spi ви позволява да изпратите съобщение до всички възли в клъстера. В стандартната реализация това се прави с помощта на пръстеновидна топология. Има и интеграция със Zookeeper, в този случай се използва звездна топология. Друг важен момент, който си струва да се отбележи, е, че discovery-spi предоставя гаранции, че съобщението определено ще бъде доставено в правилния ред до всички възли.
Нека да разгледаме протокола за разполагане. Всички потребителски заявки за внедряване и премахване се изпращат чрез discovery-spi. Това дава следното Гаранция:
- Заявката ще бъде получена от всички възли в клъстера. Това ще позволи заявката да продължи да се обработва, когато координаторът се промени. Това също означава, че в едно съобщение всеки възел ще има всички необходими метаданни, като например конфигурацията на услугата и нейния сериализиран екземпляр.
- Стриктното подреждане на доставката на съобщения помага за разрешаване на конфликти в конфигурацията и конкуриращи се заявки.
- Тъй като влизането на възела в топологията също се обработва чрез discovery-spi, новият възел ще получи всички данни, необходими за работа с услуги.
Когато се получи заявка, възлите в клъстера я валидират и създават задачи за обработка. Тези задачи се поставят на опашка и след това се обработват в друга нишка от отделен работник. Прилага се по този начин, защото внедряването може да отнеме значително време и да забави непоносимо скъпия поток откривания.
Всички заявки от опашката се обработват от мениджъра за внедряване. Той има специален работник, който изтегля задача от тази опашка и я инициализира, за да започне внедряването. След това се извършват следните действия:
- Всеки възел независимо изчислява разпределението благодарение на нова детерминистична функция за присвояване.
- Възлите генерират съобщение с резултатите от внедряването и го изпращат на координатора.
- Координаторът събира всички съобщения и генерира резултата от целия процес на внедряване, който се изпраща чрез discovery-spi до всички възли в клъстера.
- Когато резултатът бъде получен, процесът на внедряване приключва, след което задачата се премахва от опашката.
Нов дизайн, управляван от събития: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Ако възникне грешка по време на внедряването, възелът незабавно включва тази грешка в съобщение, което изпраща на координатора. След агрегирането на съобщенията координаторът ще има информация за всички грешки по време на внедряването и ще изпрати това съобщение чрез discovery-spi. Информацията за грешка ще бъде налична на всеки възел в клъстера.
Всички важни събития в Service Grid се обработват с помощта на този оперативен алгоритъм. Например, промяната на топологията също е съобщение чрез discovery-spi. И като цяло, в сравнение с това, което беше преди, протоколът се оказа доста лек и надежден. Достатъчно за справяне с всяка ситуация по време на разгръщане.
Какво ще стане по-нататък
Сега за плановете. Всяка голяма промяна в проекта Ignite се завършва като инициатива за подобряване на Ignite, наречена IEP. Редизайнът на Service Grid също има IEP - с подигравателно заглавие „Смяна на масло в сервизната решетка”. Но всъщност сменихме не маслото на двигателя, а целия двигател.
Разделихме задачите в IEP на 2 фази. Първата е основна фаза, която се състои от преработка на протокола за внедряване. Той вече е включен в master, можете да опитате новата Service Grid, която ще се появи във версия 2.8. Втората фаза включва много други задачи:
- Горещо пренасочване
- Версиониране на услугата
- Повишена отказоустойчивост
- Тънък клиент
- Инструменти за наблюдение и изчисляване на различни показатели
И накрая, можем да ви посъветваме относно Service Grid за изграждане на устойчиви на грешки системи с висока достъпност. Също така ви каним да ни посетите на и споделете опита си. Вашият опит е наистина важен за общността; той ще ви помогне да разберете накъде да продължите, как да развиете компонента в бъдеще.
Източник: www.habr.com