Փետրվարի 26-ին մենք անցկացրինք Apache Ignite GreenSource-ի հանդիպում, որտեղ խոսեցին բաց կոդով նախագծի մասնակիցները . Այս համայնքի կյանքում կարևոր իրադարձություն էր բաղադրիչի վերակազմավորումը , որը թույլ է տալիս տեղակայել հատուկ միկրոծառայություններ անմիջապես Ignite կլաստերի մեջ: Հանդիպմանը նա խոսեց այս բարդ գործընթացի մասին , ծրագրային ապահովման ինժեներ և Apache Ignite-ի ներդրող ավելի քան երկու տարի:
Սկսենք նրանից, թե ինչ է Apache Ignite-ն ընդհանրապես։ Սա տվյալների բազա է, որը բաշխված բանալի/արժեքի պահեստ է՝ SQL-ի, գործարքների և քեշավորման աջակցությամբ: Բացի այդ, Ignite-ը թույլ է տալիս տեղակայել հատուկ ծառայություններ անմիջապես Ignite կլաստերի մեջ: Մշակողը հասանելի է բոլոր այն գործիքներին, որոնք տրամադրում է Ignite-ը` բաշխված տվյալների կառուցվածքները, հաղորդագրությունների փոխանակումը, հոսքը, հաշվարկը և տվյալների ցանցը: Օրինակ՝ Տվյալների Ցանցից օգտվելիս վերանում է տվյալների պահպանման համար առանձին ենթակառուցվածքի կառավարման խնդիրը և, որպես հետևանք, առաջացած ընդհանուր ծախսերը:
Օգտագործելով Service Grid API-ն, դուք կարող եք տեղակայել ծառայություն՝ պարզապես նշելով տեղակայման սխեման և, համապատասխանաբար, ինքնին ծառայությունը կազմաձևում:
Սովորաբար, տեղակայման սխեման ցույց է տալիս այն դեպքերի քանակը, որոնք պետք է տեղակայվեն կլաստերային հանգույցների վրա: Կան երկու բնորոշ տեղակայման սխեմաներ. Առաջինը Cluster Singleton-ն է. ցանկացած պահի օգտատերերի ծառայության մեկ օրինակ հասանելի կլինի կլաստերում: Երկրորդը Node Singleton-ն է՝ ծառայության մեկ օրինակը տեղակայվում է յուրաքանչյուր կլաստերային հանգույցի վրա:
Օգտատերը կարող է նաև նշել ամբողջ կլաստերի սպասարկման դեպքերի քանակը և սահմանել համապատասխան հանգույցների զտման նախադրյալ: Այս սցենարում Service Grid-ն ինքն է հաշվարկելու ծառայությունների տեղակայման օպտիմալ բաշխումը:
Բացի այդ, կա այնպիսի գործառույթ, ինչպիսին է Affinity Service-ը: Affinity-ը ֆունկցիա է, որը սահմանում է ստեղների կապը միջնորմների հետ և կողմերի հարաբերությունները տոպոլոգիայում հանգույցների հետ: Օգտագործելով բանալին, դուք կարող եք որոշել հիմնական հանգույցը, որի վրա պահվում են տվյալները: Այս կերպ դուք կարող եք կապել ձեր սեփական ծառայությունը հիմնական և հարակից ֆունկցիաների քեշի հետ: Եթե փոխհարաբերությունների ֆունկցիան փոխվի, տեղի կունենա ավտոմատ վերաբաշխում: Այսպիսով, ծառայությունը միշտ կտեղակայվի այն տվյալներին մոտ, որոնք անհրաժեշտ են մանիպուլյացիայի համար, և, համապատասխանաբար, կնվազեցնի տեղեկատվության մուտքի ծախսերը: Այս սխեման կարելի է անվանել մի տեսակ համակցված հաշվարկ:
Այժմ, երբ մենք հասկացանք, թե որն է Service Grid-ի գեղեցկությունը, եկեք խոսենք դրա զարգացման պատմության մասին:
Ինչ է եղել նախկինում
Service Grid-ի նախորդ ներդրումը հիմնված էր Ignite-ի գործարքային վերարտադրվող համակարգի քեշի վրա: Ignite-ում «քեշ» բառը վերաբերում է պահեստավորմանը: Այսինքն՝ սա ժամանակավոր բան չէ, ինչպես դուք կարող եք մտածել։ Չնայած այն հանգամանքին, որ քեշը կրկնօրինակվում է և յուրաքանչյուր հանգույց պարունակում է տվյալների ամբողջ հավաքածուն, քեշի ներսում այն ունի բաժանված ներկայացում: Դա պայմանավորված է պահեստավորման օպտիմալացումով:
Ի՞նչ պատահեց, երբ օգտատերը ցանկացավ տեղակայել ծառայությունը:
- Կլաստերի բոլոր հանգույցները բաժանորդագրվել են պահեստում տվյալների թարմացման համար՝ օգտագործելով ներկառուցված Continuous Query մեխանիզմը:
- Նախաձեռնող հանգույցը, կարդալով պարտավորված գործարքի ներքո, տվյալների բազայում գրառում է կատարել, որը պարունակում է ծառայության կոնֆիգուրացիան, ներառյալ սերիականացված օրինակը:
- Երբ ծանուցվում էր նոր մուտքի մասին, համակարգողը հաշվարկում էր բաշխումը` հիմնվելով կազմաձևման վրա: Ստացված օբյեկտը հետ գրվեց տվյալների բազա:
- Եթե հանգույցը բաշխման մաս էր, համակարգողը պետք է տեղակայեր այն:
Ինչը մեզ չէր սազում
Ինչ-որ պահի մենք եկանք եզրակացության՝ այսպես չի կարելի աշխատել ծառայությունների հետ։ Մի քանի պատճառ կար.
Եթե տեղակայման ժամանակ ինչ-որ սխալ է տեղի ունեցել, ապա դա կարելի էր պարզել միայն այն հանգույցի տեղեկամատյաններից, որտեղ ամեն ինչ տեղի է ունեցել: Կար միայն ասինխրոն տեղակայում, այնպես որ տեղակայման մեթոդից օգտվողին հսկողությունը վերադարձնելուց հետո որոշ լրացուցիչ ժամանակ պահանջվեց ծառայությունը սկսելու համար, և այս ընթացքում օգտատերը ոչինչ չէր կարող վերահսկել: Ծառայությունների ցանցը հետագայում զարգացնելու, նոր հնարավորություններ ստեղծելու, նոր օգտվողներ ներգրավելու և բոլորի կյանքը հեշտացնելու համար ինչ-որ բան պետք է փոխվի:
Նոր Service Grid-ը նախագծելիս մենք առաջին հերթին ցանկանում էինք ապահովել համաժամանակյա տեղաբաշխման երաշխիք. հենց որ օգտատերը API-ից վերադարձնի կառավարումը, նա կարող էր անմիջապես օգտվել ծառայություններից: Ես նաև ցանկանում էի նախաձեռնողին տալ տեղակայման սխալները կարգավորելու հնարավորություն:
Բացի այդ, ես ուզում էի պարզեցնել իրականացումը, այն է` կտրվել գործարքներից և վերաբալանսավորումից: Չնայած այն հանգամանքին, որ քեշը կրկնօրինակվում է և չկա հավասարակշռում, խնդիրներ առաջացան բազմաթիվ հանգույցներով մեծ տեղակայման ժամանակ: Երբ տոպոլոգիան փոխվում է, հանգույցները պետք է փոխանակեն տեղեկատվություն, և մեծ տեղակայման դեպքում այս տվյալները կարող են շատ կշռել:
Երբ տոպոլոգիան անկայուն էր, համակարգողին անհրաժեշտ էր վերահաշվարկել ծառայությունների բաշխումը: Եվ ընդհանրապես, երբ դուք պետք է աշխատեք անկայուն տոպոլոգիայի վրա գործարքների հետ, դա կարող է հանգեցնել դժվար կանխատեսելի սխալների։
Problems
Որո՞նք են գլոբալ փոփոխություններն առանց ուղեկցող խնդիրների: Դրանցից առաջինը տոպոլոգիայի փոփոխությունն էր: Դուք պետք է հասկանաք, որ ցանկացած պահի, նույնիսկ ծառայության տեղակայման պահին, հանգույցը կարող է մտնել կամ դուրս գալ կլաստերից: Ավելին, եթե տեղակայման պահին հանգույցը միանա կլաստերին, ապա անհրաժեշտ կլինի հետևողականորեն փոխանցել ծառայությունների մասին բոլոր տեղեկությունները նոր հանգույցին: Եվ խոսքը ոչ միայն արդեն տեղակայվածի մասին է, այլ նաև ներկա և ապագա տեղակայումների։
Սա միայն այն խնդիրներից մեկն է, որը կարելի է հավաքել առանձին ցանկում.
- Ինչպե՞ս տեղակայել ստատիկորեն կազմաձևված ծառայություններ հանգույցի գործարկման ժամանակ:
- Կլաստերից հանգույց թողնելը. ի՞նչ անել, եթե հանգույցը հյուրընկալել է ծառայություններ:
- Ի՞նչ անել, եթե համակարգողը փոխվել է:
- Ի՞նչ անել, եթե հաճախորդը նորից միանա կլաստերին:
- Արդյո՞ք ակտիվացման/անջատման հարցումները պետք է մշակվեն և ինչպե՞ս:
- Իսկ եթե նրանք կոչ են արել քեշը ոչնչացնել, և մենք դրա հետ կապված ունենք մերձավոր ծառայություններ:
Եվ սա դեռ ամենը չէ:
որոշում
Որպես թիրախ՝ մենք ընտրեցինք Իրադարձությունների վրա հիմնված մոտեցումը՝ հաղորդագրությունների միջոցով գործընթացային հաղորդակցության ներդրմամբ: Ignite-ն արդեն ներդնում է երկու բաղադրիչ, որոնք թույլ են տալիս հանգույցներին միմյանց միջև հաղորդագրություններ փոխանցել՝ communication-spi և Discovery-spi:
Communication-spi-ն թույլ է տալիս հանգույցներին ուղղակիորեն հաղորդակցվել և փոխանցել հաղորդագրությունները: Այն լավ հարմար է մեծ քանակությամբ տվյալներ ուղարկելու համար: Discovery-spi-ն թույլ է տալիս հաղորդագրություն ուղարկել կլաստերի բոլոր հանգույցներին: Ստանդարտ իրականացման դեպքում դա արվում է օղակի տոպոլոգիայի միջոցով: Կա նաև Zookeeper-ի հետ ինտեգրում, այս դեպքում օգտագործվում է աստղային տոպոլոգիա։ Մեկ այլ կարևոր կետ, որը արժե ուշադրություն դարձնել, այն է, որ Discovery-spi-ն երաշխիքներ է տալիս, որ հաղորդագրությունն անպայման կհասցվի ճիշտ հերթականությամբ բոլոր հանգույցներին:
Եկեք նայենք տեղակայման արձանագրությանը: Օգտագործողի բոլոր հարցումները տեղակայման և չտեղակայման համար ուղարկվում են Discovery-spi-ի միջոցով: Սա տալիս է հետևյալը երաշխիքներ:
- Հարցումը կստացվի կլաստերի բոլոր հանգույցների կողմից: Սա թույլ կտա հարցումը շարունակել մշակումը, երբ համակարգողը փոխվի: Սա նաև նշանակում է, որ մեկ հաղորդագրության մեջ յուրաքանչյուր հանգույց կունենա բոլոր անհրաժեշտ մետատվյալները, ինչպիսիք են ծառայության կոնֆիգուրացիան և դրա սերիականացված օրինակը:
- Հաղորդագրությունների առաքման խիստ կարգը օգնում է լուծել կոնֆիգուրացիայի կոնֆլիկտները և մրցակցային հարցումները:
- Քանի որ հանգույցի մուտքը տոպոլոգիա նույնպես մշակվում է Discovery-spi-ի միջոցով, նոր հանգույցը կստանա ծառայությունների հետ աշխատելու համար անհրաժեշտ բոլոր տվյալները։
Երբ հարցում է ստացվում, կլաստերի հանգույցները վավերացնում են այն և ստեղծում մշակման առաջադրանքներ: Այս առաջադրանքները հերթագրվում են և հետո մշակվում մեկ այլ թեմայում առանձին աշխատողի կողմից: Այն իրականացվում է այս կերպ, քանի որ տեղակայումը կարող է զգալի ժամանակ խլել և անտանելի կերպով հետաձգել թանկարժեք հայտնաբերման հոսքը:
Հերթի բոլոր հարցումները մշակվում են տեղակայման մենեջերի կողմից: Այն ունի հատուկ աշխատող, որն առաջադրանքը հանում է այս հերթից և սկզբնավորում է այն՝ սկսելու տեղակայումը: Դրանից հետո տեղի են ունենում հետևյալ գործողությունները.
- Յուրաքանչյուր հանգույց ինքնուրույն հաշվարկում է բաշխումը նոր դետերմինիստական նշանակման ֆունկցիայի շնորհիվ:
- Հանգույցները ստեղծում են հաղորդագրություն տեղակայման արդյունքներով և ուղարկում համակարգողին:
- Համակարգողը համախմբում է բոլոր հաղորդագրությունները և առաջացնում է տեղակայման ողջ գործընթացի արդյունքը, որն ուղարկվում է detecty-spi-ի միջոցով կլաստերի բոլոր հանգույցներին:
- Արդյունքը ստանալուց հետո տեղակայման գործընթացը ավարտվում է, որից հետո առաջադրանքը հանվում է հերթից:
Իրադարձությունների վրա հիմնված նոր դիզայն՝ org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Եթե տեղակայման ժամանակ սխալ է տեղի ունենում, հանգույցն անմիջապես ներառում է այս սխալը հաղորդագրության մեջ, որն ուղարկում է համակարգողին: Հաղորդագրությունների համախմբումից հետո համակարգողը տեղեկատվություն կունենա տեղակայման ժամանակ բոլոր սխալների մասին և կուղարկի այս հաղորդագրությունը Discovery-spi-ի միջոցով: Սխալի մասին տեղեկատվությունը հասանելի կլինի կլաստերի ցանկացած հանգույցի վրա:
Ծառայությունների ցանցի բոլոր կարևոր իրադարձությունները մշակվում են այս գործող ալգորիթմի միջոցով: Օրինակ, տոպոլոգիան փոխելը նույնպես հաղորդագրություն է discovery-spi-ի միջոցով: Եվ ընդհանրապես, համեմատելով նախկինի հետ, արձանագրությունը բավականին թեթև և հուսալի է ստացվել։ Բավական է տեղակայման ընթացքում ցանկացած իրավիճակ կարգավորելու համար:
Ինչ կլինի հաջորդ:
Հիմա պլանների մասին. Ignite նախագծի ցանկացած լուրջ փոփոխություն ավարտվում է որպես Ignite բարելավման նախաձեռնություն, որը կոչվում է IEP: Ծառայությունների ցանցի վերանախագծումն ունի նաև IEP. «Յուղի փոփոխություն սպասարկման ցանցում» ծաղրական վերնագրով։ Բայց իրականում մենք չենք փոխել շարժիչի յուղը, այլ ամբողջ շարժիչը:
Մենք IEP-ում առաջադրանքները բաժանեցինք 2 փուլի. Առաջինը հիմնական փուլն է, որը բաղկացած է տեղակայման արձանագրության վերամշակումից: Այն արդեն ներառված է վարպետության մեջ, կարող եք փորձել նոր Service Grid-ը, որը կհայտնվի 2.8 տարբերակում։ Երկրորդ փուլը ներառում է բազմաթիվ այլ առաջադրանքներ.
- Թեժ վերաբաշխում
- Ծառայության տարբերակավորում
- Սխալների հանդուրժողականության բարձրացում
- Նիհար հաճախորդ
- Տարբեր չափումների մոնիտորինգի և հաշվարկման գործիքներ
Վերջապես, մենք կարող ենք ձեզ խորհուրդ տալ «Service Grid»-ի վերաբերյալ՝ անսարքությունների հանդուրժող, բարձր հասանելիության համակարգեր կառուցելու համար: Մենք նաև հրավիրում ենք ձեզ այցելել մեզ и կիսվեք ձեր փորձով: Ձեր փորձն իսկապես կարևոր է համայնքի համար, այն կօգնի ձեզ հասկանալ, թե ուր շարժվել հաջորդը, ինչպես զարգացնել բաղադրիչը ապագայում:
Source: www.habr.com