26 ақпанда біз ашық бастапқы жобаға қатысушылар сөйлеген Apache Ignite GreenSource кездесуін өткіздік. . Бұл қауымдастықтың өміріндегі маңызды оқиға құрамдас бөліктің қайта құрылуы болды , бұл реттелетін микросервистерді тікелей Ignite кластеріне орналастыруға мүмкіндік береді. Кездесуде ол осы күрделі процесс туралы айтты , бағдарламалық қамтамасыз ету инженері және екі жылдан астам Apache Ignite салымшысы.
Жалпы Apache Ignite дегеніміз не екенін бастайық. Бұл SQL, транзакциялық және кэштеу қолдауымен бөлінген кілт/мән қоймасы болып табылатын дерекқор. Сонымен қатар, Ignite теңшелетін қызметтерді тікелей Ignite кластеріне орналастыруға мүмкіндік береді. Әзірлеуші Ignite ұсынатын барлық құралдарға қол жеткізе алады - таратылған деректер құрылымдары, хабар алмасу, ағынмен алмасу, есептеу және деректер торы. Мысалы, Деректер торын пайдаланған кезде деректерді сақтау үшін бөлек инфрақұрылымды басқару мәселесі және нәтижесінде пайда болатын үстеме шығындар жойылады.
Service Grid API пайдалана отырып, жай ғана орналастыру схемасын және сәйкесінше конфигурацияда қызметтің өзін көрсету арқылы қызметті орналастыруға болады.
Әдетте, орналастыру схемасы кластер түйіндерінде орналастыру керек даналар санының көрсеткіші болып табылады. Екі типтік орналастыру схемасы бар. Біріншісі - Cluster Singleton: кез келген уақытта пайдаланушы қызметінің бір данасы кластерде қолжетімді болатынына кепілдік беріледі. Екіншісі - Node Singleton: қызметтің бір данасы әрбір кластер түйінінде орналастырылған.
Пайдаланушы сонымен қатар бүкіл кластердегі қызмет даналарының санын көрсете алады және сәйкес түйіндерді сүзу үшін предикатты анықтай алады. Бұл сценарийде Service Grid өзі қызметтерді орналастыру үшін оңтайлы таратуды есептейді.
Сонымен қатар, Affinity Service сияқты мүмкіндік бар. Аффинділік – кілттердің бөлімдерге қатынасын және топологиядағы түйіндерге тараптардың қатынасын анықтайтын функция. Кілтті пайдаланып, деректер сақталатын негізгі түйінді анықтауға болады. Осылайша сіз өзіңіздің қызметіңізді кілт пен жақындық функциясының кэшімен байланыстыра аласыз. Егер жақындық функциясы өзгерсе, автоматты қайта орналастыру орын алады. Осылайша, қызмет әрқашан манипуляциялау қажет деректерге жақын орналасады және сәйкесінше ақпаратқа қол жеткізудің үстеме шығындарын азайтады. Бұл схеманы біріктірілген есептеулердің бір түрі деп атауға болады.
Енді біз Service Grid сұлулығының не екенін түсінгеннен кейін, оның даму тарихы туралы сөйлесейік.
Бұрын не болды
Қызметтер торының алдыңғы орындалуы Ignite транзакциялық қайталанатын жүйе кэшіне негізделген. Ignite ішіндегі «кэш» сөзі сақтауды білдіреді. Яғни, бұл сіз ойлағандай уақытша нәрсе емес. Кэш репликацияланғанына және әрбір түйінде барлық деректер жиыны бар екеніне қарамастан, кэш ішінде оның бөлінген көрінісі бар. Бұл сақтауды оңтайландыруға байланысты.
Пайдаланушы қызметті қолданғысы келгенде не болды?
- Кластердегі барлық түйіндер кірістірілген Үздіксіз сұрау механизмі арқылы жадтағы деректерді жаңартуға жазылды.
- Бастау түйіні оқылған транзакция бойынша, серияланған дананы қоса, қызмет конфигурациясын қамтитын дерекқорда жазба жасады.
- Жаңа жазба туралы хабарланғанда, үйлестіруші конфигурацияға негізделген таратуды есептеді. Алынған нысан дерекқорға қайта жазылды.
- Егер түйін таратудың бөлігі болса, үйлестіруші оны орналастыруы керек болды.
Бізге не ұнамады
Бір сәтте біз мынадай қорытындыға келдік: бұл қызметтермен жұмыс істеу тәсілі емес. Бірнеше себеп болды.
Орналастыру кезінде қандай да бір қателік орын алса, оны тек барлығы болған түйіннің журналдарынан білуге болады. Тек асинхронды орналастыру болды, сондықтан қолдану әдісінен басқаруды пайдаланушыға қайтарғаннан кейін қызметті бастау үшін біраз қосымша уақыт қажет болды - және осы уақыт ішінде пайдаланушы ештеңені басқара алмады. Қызметтер торын одан әрі дамыту, жаңа мүмкіндіктерді жасау, жаңа пайдаланушыларды тарту және барлығының өмірін жеңілдету үшін бір нәрсені өзгерту керек.
Жаңа Service Grid құрастыру кезінде біз ең алдымен синхронды орналастыру кепілдігін ұсынғымыз келді: пайдаланушы API-дан басқаруды қайтарған бойда ол қызметтерді бірден пайдалана алады. Мен сондай-ақ бастамашыға орналастыру қателерін өңдеу мүмкіндігін бергім келді.
Сонымен қатар, мен жүзеге асыруды жеңілдеткім келді, атап айтқанда, транзакциялардан және теңгерімдеуден аулақ болғым келеді. Кэштің қайталанатынына және теңгерімсіздігіне қарамастан, көптеген түйіндері бар үлкен орналастыру кезінде мәселелер туындады. Топология өзгерген кезде түйіндер ақпарат алмасуы қажет және үлкен орналастыру кезінде бұл деректер көп салмақ түсіруі мүмкін.
Топология тұрақсыз болған кезде үйлестіруші қызметтерді бөлуді қайта есептеу қажет болды. Ал жалпы алғанда, тұрақсыз топология бойынша транзакциялармен жұмыс істеуге тура келгенде, бұл болжау қиын қателерге әкелуі мүмкін.
проблемалар
Ілеспе проблемаларсыз жаһандық өзгерістер қандай? Олардың біріншісі топологияның өзгеруі болды. Кез келген сәтте, тіпті қызметті орналастыру сәтінде де түйін кластерге кіруі немесе шығуы мүмкін екенін түсінуіңіз керек. Сонымен қатар, егер орналастыру кезінде түйін кластерге қосылса, қызметтер туралы барлық ақпаратты жаңа түйінге жүйелі түрде тасымалдау қажет болады. Біз қазірдің өзінде орналастырылған нәрселер туралы ғана емес, сонымен қатар ағымдағы және болашақ орналастырулар туралы айтып отырмыз.
Бұл бөлек тізімде жинақталатын мәселелердің бірі ғана:
- Түйінді іске қосу кезінде статикалық конфигурацияланған қызметтерді қалай орналастыруға болады?
- Кластерден түйінді қалдыру - түйінде қызметтер болған жағдайда не істеу керек?
- Үйлестіруші өзгерсе не істеу керек?
- Клиент кластерге қайта қосылса не істеу керек?
- Іске қосу/өшіру сұрауларын өңдеу керек пе және қалай?
- Егер олар кэшті жоюға шақырса ше?
Бұл бәрі емес.
шешім
Мақсат ретінде біз хабарламаларды пайдалана отырып, процесті байланыстыруды жүзеге асыратын оқиғаға негізделген тәсілді таңдадық. Ignite қазірдің өзінде түйіндерге хабарламаларды жіберуге мүмкіндік беретін екі құрамдас бөлікті жүзеге асырады - коммуникация-spi және Discovery-spi.
Communication-spi түйіндерге тікелей байланысуға және хабарламаларды жіберуге мүмкіндік береді. Ол үлкен көлемдегі деректерді жіберу үшін өте қолайлы. Discovery-spi кластердегі барлық түйіндерге хабарлама жіберуге мүмкіндік береді. Стандартты іске асыруда бұл сақина топологиясы арқылы жүзеге асырылады. Сондай-ақ Zookeeper-пен интеграция бар, бұл жағдайда жұлдыз топологиясы қолданылады. Тағы бір айта кететін маңызды жайт, discovery-spi хабарламаның барлық түйіндерге міндетті түрде дұрыс ретпен жеткізілетініне кепілдік береді.
Орналастыру протоколын қарастырайық. Орналастыруға және қолданбауға арналған барлық пайдаланушы сұраулары discovery-spi арқылы жіберіледі. Бұл келесіні береді кепілдік:
- Сұрауды кластердегі барлық түйіндер қабылдайды. Бұл үйлестіруші өзгерген кезде сұрауды өңдеуді жалғастыруға мүмкіндік береді. Бұл сонымен қатар бір хабарламада әрбір түйінде қызмет конфигурациясы және оның серияланған данасы сияқты барлық қажетті метадеректер болады дегенді білдіреді.
- Хабарламаны жеткізудің қатаң реті конфигурация қайшылықтары мен бәсекелес сұрауларды шешуге көмектеседі.
- Түйіннің топологияға кіруі Discovery-spi арқылы да өңделетіндіктен, жаңа түйін қызметтермен жұмыс істеуге қажетті барлық деректерді алады.
Сұрау қабылданған кезде, кластердегі түйіндер оны тексереді және өңдеу тапсырмаларын жасайды. Бұл тапсырмалар кезекке қойылады, содан кейін бөлек жұмысшы басқа ағында өңделеді. Ол осылай жүзеге асырылады, себебі орналастыру айтарлықтай уақытты алуы және қымбат табу ағынын төзгісіз кешіктіруі мүмкін.
Кезектен келген барлық сұрауларды орналастыру менеджері өңдейді. Оның осы кезектен тапсырманы шығаратын және орналастыруды бастау үшін инициализациялайтын арнайы жұмысшысы бар. Осыдан кейін келесі әрекеттер орындалады:
- Әрбір түйін жаңа детерминирленген тағайындау функциясының арқасында үлестіруді дербес есептейді.
- Түйіндер орналастыру нәтижелерімен хабарлама жасайды және оны үйлестірушіге жібереді.
- Үйлестіруші барлық хабарламаларды біріктіреді және табу-spi арқылы кластердегі барлық түйіндерге жіберілетін бүкіл орналастыру процесінің нәтижесін жасайды.
- Нәтиже алынғанда, орналастыру процесі аяқталады, содан кейін тапсырма кезектен жойылады.
Оқиғаға негізделген жаңа дизайн: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Орналастыру кезінде қате орын алса, түйін бұл қатені үйлестірушіге жіберетін хабарламаға дереу қосады. Хабарламаларды біріктіргеннен кейін үйлестіруші орналастыру кезіндегі барлық қателер туралы ақпаратқа ие болады және бұл хабарламаны discovery-spi арқылы жібереді. Қате туралы ақпарат кластердегі кез келген түйінде қолжетімді болады.
Қызметтер торындағы барлық маңызды оқиғалар осы операциялық алгоритм арқылы өңделеді. Мысалы, топологияны өзгерту Discovery-spi арқылы да хабар болып табылады. Жалпы алғанда, бұрынғымен салыстырғанда, протокол өте жеңіл және сенімді болып шықты. Орналастыру кезінде кез келген жағдайды шешуге жеткілікті.
Келесіде не болады?
Енді жоспарлар туралы. Ignite жобасына кез келген негізгі өзгерту IEP деп аталатын Ignite жақсарту бастамасы ретінде аяқталады. Service Grid қайта дизайнында сонымен қатар IEP бар - «Қызмет көрсету торындағы майды ауыстыру» деген келеке атауымен. Бірақ іс жүзінде біз қозғалтқыш майын емес, бүкіл қозғалтқышты ауыстырдық.
БӨБ тапсырмаларын 2 кезеңге бөлдік. Біріншісі - орналастыру протоколын қайта өңдеуден тұратын негізгі кезең. Ол қазірдің өзінде мастерге қосылған, сіз 2.8 нұсқасында пайда болатын жаңа Service Grid қолданып көруге болады. Екінші кезең көптеген басқа тапсырмаларды қамтиды:
- Ыстық қайта орналастыру
- Сервис нұсқасы
- Ақауларға төзімділіктің жоғарылауы
- Жұқа клиент
- Әртүрлі көрсеткіштерді бақылау және есептеу құралдары
Соңында, ақауларға төзімді, қолжетімділігі жоғары жүйелерді құру үшін сізге қызмет көрсету торы туралы кеңес бере аламыз. Сізді де бізге қонаққа шақырамыз и тәжірибеңізбен бөлісіңіз. Сіздің тәжірибеңіз қоғамдастық үшін өте маңызды; ол сізге әрі қарай қайда өту керектігін, болашақта компонентті қалай дамыту керектігін түсінуге көмектеседі.
Ақпарат көзі: www.habr.com