Տվյալների երկատվածություն. տվյալների և ծառայությունների միջև փոխհարաբերությունների վերաիմաստավորում

Բարեւ բոլորին! Մենք հիանալի նորություն ունենք, OTUS-ը նորից սկսում է դասընթացը հունիսին «Ծրագրային ճարտարապետ», ինչի կապակցությամբ ավանդաբար ձեզ հետ կիսվում ենք օգտակար նյութերով։

Եթե ​​դուք հանդիպել եք միկրոսերվիսների այս ամբողջ խնդրին՝ առանց որևէ համատեքստի, ձեզ կներեն, որ դա մի փոքր տարօրինակ է մտածել: Հավելվածը ցանցով միացված բեկորների բաժանելն անպայման նշանակում է արդյունքում բաշխված համակարգին սխալների հանդուրժողականության բարդ ռեժիմներ ավելացնել:

Չնայած այս մոտեցումը ներառում է այն բաժանել բազմաթիվ անկախ ծառայությունների, վերջնական նպատակը շատ ավելին է, քան պարզապես այդ ծառայություններն աշխատելը տարբեր մեքենաների վրա: Խոսքն այստեղ արտաքին աշխարհի հետ փոխգործակցության մասին է, որը նույնպես բաշխված է իր էությամբ։ Ոչ թե տեխնիկական իմաստով, այլ ավելի շուտ էկոհամակարգի իմաստով, որը բաղկացած է բազմաթիվ մարդկանցից, թիմերից, ծրագրերից, և այս մասերից յուրաքանչյուրն ինչ-որ կերպ պետք է կատարի իր աշխատանքը:

Ընկերությունները, օրինակ, բաշխված համակարգերի հավաքածու են, որոնք միասին նպաստում են ինչ-որ նպատակի իրականացմանը: Մենք անտեսել ենք այս փաստը տասնամյակներ շարունակ՝ փորձելով հասնել միավորման FTP ֆայլերի միջոցով կամ օգտագործելով ձեռնարկությունների ինտեգրման գործիքներ՝ միաժամանակ կենտրոնանալով մեր մեկուսացված նպատակների վրա: Սակայն ծառայությունների գալուստով ամեն ինչ փոխվեց: Ծառայություններն օգնել են մեզ նայել հորիզոնից այն կողմ և տեսնել փոխկապակցված ծրագրերի աշխարհը, որոնք աշխատում են միասին: Այնուամենայնիվ, հաջող աշխատելու համար անհրաժեշտ է ճանաչել և նախագծել երկու սկզբունքորեն տարբեր աշխարհներ՝ արտաքին աշխարհը, որտեղ մենք ապրում ենք բազմաթիվ այլ ծառայությունների էկոհամակարգում, և մեր անձնական, ներքին աշխարհը, որտեղ մենք միայնակ ենք կառավարում:

Այս բաշխված աշխարհը տարբերվում է նրանից, որտեղ մենք մեծացել և սովոր ենք: Ավանդական միաձույլ ճարտարապետության կառուցման սկզբունքները չեն դիմանում քննադատությանը։ Այսպիսով, այս համակարգերը ճիշտ ձեռք բերելն ավելին է, քան գրատախտակի հիանալի գծապատկեր կամ հայեցակարգի հիանալի ապացույց ստեղծելը: Խնդիրն այն է, որ երաշխավորվի, որ նման համակարգը հաջողությամբ գործի երկար ժամանակ: Բարեբախտաբար, ծառայությունները գոյություն ունեն բավականին երկար ժամանակ, չնայած նրանք տարբեր տեսք ունեն: SOA դասեր դեռևս արդիական են՝ նույնիսկ համեմված Docker-ով, Kubernetes-ով և մի փոքր մաշված հիփստեր մորուքներով:

Այսպիսով, այսօր մենք կանդրադառնանք, թե ինչպես են փոխվել կանոնները, ինչու պետք է վերանայենք ծառայությունների մոտեցումը և այն տվյալները, որոնք նրանք փոխանցում են միմյանց, և ինչու մեզ անհրաժեշտ կլինեն բոլորովին այլ գործիքներ դա անելու համար:

Էկապսուլյացիան միշտ չէ, որ ձեր ընկերը կլինի

Միկրոծառայությունները կարող են գործել միմյանցից անկախ: Հենց այս հատկությունն է նրանց տալիս ամենամեծ արժեքը։ Այս նույն հատկությունը թույլ է տալիս ծառայությունները մասշտաբավորվել և աճել: Ոչ այնքան մեծացման իմաստով մինչև կվադրիլիոն օգտատերերի կամ պետաբայթ տվյալների (չնայած դրանք կարող են օգնել այնտեղ նույնպես), որքան այն իմաստով, որ մասշտաբի չափվի մարդկանց առումով, քանի որ թիմերն ու կազմակերպությունները անընդհատ աճում են:

Այնուամենայնիվ, անկախությունը երկսայրի սուր է: Այսինքն, ծառայությունն ինքնին կարող է հեշտությամբ և բնականաբար աշխատել: Բայց եթե ծառայությունում իրականացվում է գործառույթ, որը պահանջում է օգտագործել մեկ այլ ծառայություն, ապա մենք ստիպված ենք լինում փոփոխություններ կատարել երկու ծառայություններում գրեթե միաժամանակ: Մոնոլիտում դա հեշտ է անել, դուք պարզապես փոփոխություն եք կատարում և ուղարկում այն ​​թողարկելու, բայց անկախ ծառայությունների համաժամացման դեպքում ավելի շատ խնդիրներ կլինեն: Թիմերի միջև համակարգումը և թողարկման ցիկլերը ոչնչացնում են շարժունությունը:

Որպես ստանդարտ մոտեցման մաս՝ նրանք պարզապես փորձում են խուսափել ծայրից ծայր նյարդայնացնող փոփոխություններից՝ հստակորեն բաժանելով ֆունկցիոնալությունը ծառայությունների միջև: Միանգամյա մուտքի ծառայությունը կարող է լավ օրինակ լինել այստեղ: Այն ունի հստակ սահմանված դեր, որն այն տարբերում է այլ ծառայություններից: Այս հստակ տարանջատումը նշանակում է, որ իրեն շրջապատող ծառայությունների նկատմամբ արագ փոփոխվող պահանջների աշխարհում, մուտքի միասնական ծառայությունը դժվար թե փոխվի: Այն գոյություն ունի խիստ սահմանափակ համատեքստում:

Խնդիրն այն է, որ իրական աշխարհում բիզնես ծառայությունները չեն կարող մշտապես պահպանել դերերի նույն մաքուր տարանջատումը: Օրինակ, նույն բիզնես ծառայություններն ավելի մեծ չափով են աշխատում այլ նմանատիպ ծառայություններից ստացվող տվյալների հետ: Եթե ​​դուք զբաղվում եք առցանց մանրածախ առևտրով, ապա պատվերի հոսքի, ապրանքների կատալոգի կամ օգտատերերի տեղեկատվության մշակումը պարտադիր կդառնա ձեր ծառայությունների շատերի համար: Ծառայություններից յուրաքանչյուրին անհրաժեշտ կլինի մուտք գործել այս տվյալներին գործելու համար:

Բիզնես ծառայությունների մեծ մասը կիսում է տվյալների նույն հոսքը, ուստի նրանց աշխատանքը մշտապես փոխկապակցված է:

Այսպիսով, մենք գալիս ենք մի կարևոր կետի, որի մասին արժե խոսել. Թեև ծառայությունները լավ են աշխատում ենթակառուցվածքային բաղադրիչների համար, որոնք հիմնականում գործում են մեկուսացված, բիզնես ծառայությունների մեծ մասն ավարտվում է շատ ավելի սերտորեն փոխկապակցված:

Տվյալների երկատվածություն

Ծառայությունների վրա հիմնված մոտեցումներ կարող են արդեն գոյություն ունենալ, բայց դրանք դեռևս չունեն պատկերացում այն ​​մասին, թե ինչպես կարելի է մեծ քանակությամբ տվյալներ կիսել ծառայությունների միջև:

Հիմնական խնդիրն այն է, որ տվյալներն ու ծառայություններն անբաժանելի են։ Մի կողմից, encapsulation-ը մեզ խրախուսում է թաքցնել տվյալները, որպեսզի ծառայությունները կարողանան բաժանվել միմյանցից և նպաստել դրանց աճին և հետագա փոփոխություններին: Մյուս կողմից, մենք պետք է կարողանանք ազատորեն բաժանել և նվաճել ընդհանուր տվյալները, ինչպես ցանկացած այլ տվյալ: Խնդիրն այն է, որ կարողանանք անմիջապես սկսել աշխատել այնպես, ինչպես ցանկացած այլ տեղեկատվական համակարգում։

Այնուամենայնիվ, տեղեկատվական համակարգերը քիչ առնչություն ունեն ինկապսուլյացիայի հետ: Իրականում լրիվ հակառակն է։ Տվյալների շտեմարաններն անում են ամեն ինչ՝ իրենց պահած տվյալներին հասանելիություն ապահովելու համար: Նրանք գալիս են հզոր դեկլարատիվ ինտերֆեյսով, որը թույլ է տալիս փոփոխել տվյալները ըստ անհրաժեշտության: Նման ֆունկցիոնալությունը կարևոր է նախնական հետազոտության փուլում, բայց ոչ անընդհատ զարգացող ծառայության աճող բարդությունը կառավարելու համար:

Եվ այստեղ երկընտրանք է առաջանում. Հակասություն. Դիխոտոմիա. Ի վերջո, տեղեկատվական համակարգերը վերաբերում են տվյալների տրամադրմանը, իսկ ծառայությունները՝ թաքցնելու:

Այս երկու ուժերը հիմնարար են։ Նրանք հիմնված են մեր աշխատանքի մեծ մասի վրա՝ մշտապես պայքարելով գերազանցության համար մեր կառուցած համակարգերում:

Քանի որ սպասարկման համակարգերը աճում և զարգանում են, մենք տեսնում ենք տվյալների երկփեղկման հետևանքները շատ առումներով: Կամ ծառայության ինտերֆեյսը կաճի՝ ապահովելու ֆունկցիոնալության ավելի լայն շրջանակ և կսկսի նմանվել շատ շքեղ տնային տվյալների բազայի, կամ մենք կհիասթափվենք և կկիրառենք տվյալների զանգվածային հավաքածուներ ծառայությունից ծառայություն առբերելու կամ տեղափոխելու որևէ միջոց:

Իր հերթին, ինչ-որ բան ստեղծելը, որը նման է շքեղ տնային տվյալների բազայի, կհանգեցնի բազմաթիվ խնդիրների: Թե ինչու է դա վտանգավոր, մենք չենք մանրամասնի ընդհանուր տվյալների բազա, միայն ասենք, որ այն ներկայացնում է զգալի ծախսատար ինժեներական և գործառնական դժվարություններ ընկերության համար, որը փորձում է օգտագործել այն:

Ամենավատն այն է, որ տվյալների ծավալները մեծացնում են ծառայության սահմանային խնդիրները: Որքան ավելի շատ ընդհանուր տվյալներ լինեն ծառայության ներսում, այնքան ավելի բարդ կդառնա ինտերֆեյսը և այնքան ավելի դժվար կլինի միավորել տարբեր ծառայություններից ստացվող տվյալների հավաքածուները:

Ամբողջական տվյալների հավաքածուների արդյունահանման և տեղափոխման այլընտրանքային մոտեցումը նույնպես ունի իր խնդիրները: Այս հարցի ընդհանուր մոտեցումը նման է ամբողջ տվյալների հավաքագրմանը և պահպանմանը, այնուհետև յուրաքանչյուր սպառող ծառայության մեջ այն տեղական պահեստավորմանը:

Խնդիրն այն է, որ տարբեր ծառայություններ տարբեր կերպ են մեկնաբանում իրենց սպառած տվյալները: Այս տվյալները միշտ ձեռքի տակ են: Դրանք փոփոխվում և մշակվում են տեղում: Շատ արագ նրանք դադարում են որևէ ընդհանուր բան ունենալ աղբյուրի տվյալների հետ:

Որքան շատ փոփոխական լինեն պատճենները, այնքան տվյալները ժամանակի ընթացքում կտարբերվեն:

Իրավիճակն ավելի վատթարացնելու համար, նման տվյալները հետադարձ հայացքով դժվար է ուղղել (MDM Սա այն է, որտեղ այն իսկապես կարող է օգնության հասնել): Իրականում, որոշ անլուծելի տեխնոլոգիական խնդիրներ, որոնց բախվում են բիզնեսները, առաջանում են անհամապատասխան տվյալներից, որոնք բազմապատկվում են դիմումից դիմում:

Այս խնդրի լուծումը գտնելու համար մենք պետք է այլ կերպ մտածենք ընդհանուր տվյալների մասին: Նրանք պետք է դառնան առաջին կարգի օբյեկտներ մեր կառուցած ճարտարապետություններում: Փեթ Հելլանդ նման տվյալներն անվանում է «արտաքին», և սա շատ կարևոր հատկություն է։ Մեզ պետք է ինկապսուլյացիա, որպեսզի չբացահայտենք ծառայության ներքին աշխատանքը, բայց մենք պետք է հեշտացնենք ծառայությունների հասանելիությունը ընդհանուր տվյալներին, որպեսզի նրանք կարողանան ճիշտ կատարել իրենց աշխատանքը:

Խնդիրն այն է, որ ոչ մի մոտեցում այսօր տեղին չէ, քանի որ ոչ ծառայության միջերեսները, ոչ հաղորդագրությունները, ոչ էլ Համօգտագործվող տվյալների բազան լավ լուծում չեն առաջարկում արտաքին տվյալների հետ աշխատելու համար: Ծառայությունների ինտերֆեյսները վատ են պիտանի ցանկացած մասշտաբով տվյալների փոխանակման համար: Հաղորդագրությունները տեղափոխում են տվյալները, բայց չեն պահում դրանց պատմությունը, ուստի տվյալները ժամանակի ընթացքում փչանում են: Համօգտագործվող տվյալների շտեմարանները չափազանց շատ են կենտրոնանում մեկ կետի վրա, ինչը հետ է պահում առաջընթացը: Մենք անխուսափելիորեն խրվում ենք տվյալների ձախողման ցիկլի մեջ.

Տվյալների ձախողման ցիկլը

հոսքեր. տվյալների և ծառայությունների ապակենտրոնացված մոտեցում

Իդեալում, մենք պետք է փոխենք ծառայությունների աշխատանքի եղանակը ընդհանուր տվյալների հետ: Այս պահին ցանկացած մոտեցում բախվում է վերոհիշյալ երկփեղկվածությանը, քանի որ չկա կախարդական փոշի, որը կարելի է ցողել դրա վրա, որպեսզի այն անհետանա: Այնուամենայնիվ, մենք կարող ենք վերանայել խնդիրը և հասնել փոխզիջման։

Այս փոխզիջումը ներառում է կենտրոնացվածության որոշակի աստիճան: Մենք կարող ենք օգտագործել բաշխված մատյան մեխանիզմը, քանի որ այն ապահովում է հուսալի, մասշտաբային հոսքեր: Այժմ մենք ցանկանում ենք, որ ծառայությունները կարողանան միանալ և գործել այս ընդհանուր շղթաների վրա, բայց մենք ցանկանում ենք խուսափել բարդ կենտրոնացված Աստծո ծառայություններից, որոնք կատարում են այս մշակումը: Հետևաբար, լավագույն տարբերակը յուրաքանչյուր սպառողական ծառայության մեջ հոսքի մշակումն է: Այս կերպ ծառայությունները կկարողանան միավորել տարբեր աղբյուրներից ստացված տվյալների հավաքածուները և աշխատել դրանց հետ այնպես, ինչպես անհրաժեշտ է:

Այս մոտեցմանը հասնելու ուղիներից մեկը հոսքային հարթակի օգտագործումն է: Կան բազմաթիվ տարբերակներ, բայց այսօր մենք կանդրադառնանք Կաֆկային, քանի որ նրա Stateful Stream Processing-ի օգտագործումը թույլ է տալիս արդյունավետորեն լուծել ներկայացված խնդիրը:

Բաշխված գրանցման մեխանիզմի կիրառումը մեզ թույլ է տալիս հետևել լավ ոտնահարված ճանապարհին և օգտագործել հաղորդագրություններ՝ աշխատելու համար իրադարձությունների վրա հիմնված ճարտարապետություն. Համարվում է, որ այս մոտեցումը ապահովում է ավելի լավ մասշտաբավորում և բաժանում, քան հարցում-պատասխան մեխանիզմը, քանի որ այն ապահովում է հոսքի վերահսկում ոչ թե ուղարկողին, այլ ստացողին: Այնուամենայնիվ, այս կյանքում ամեն ինչի համար դուք պետք է վճարեք, և այստեղ ձեզ անհրաժեշտ է բրոքեր: Բայց մեծ համակարգերի համար փոխզիջումն արժե այն (ինչը չի կարող լինել ձեր միջին վեբ հավելվածի դեպքում):

Եթե ​​բրոքերը պատասխանատու է բաշխված անտառահատումների համար, այլ ոչ թե ավանդական հաղորդագրությունների համակարգը, դուք կարող եք օգտվել լրացուցիչ հնարավորություններից: Տրանսպորտը կարող է գծային մասշտաբավորվել գրեթե նույնքան լավ, որքան բաշխված ֆայլային համակարգը: Տվյալները կարող են բավականին երկար պահվել տեղեկամատյաններում, այնպես որ մենք ստանում ենք ոչ միայն հաղորդագրությունների փոխանակում, այլև տեղեկատվության պահպանում: Սանդղելի պահեստավորում՝ առանց փոփոխական ընդհանուր վիճակի վախի:

Այնուհետև կարող եք օգտագործել պետական ​​հոսքի մշակում` սպառող ծառայություններին դեկլարատիվ տվյալների բազայի գործիքներ ավելացնելու համար: Սա շատ կարևոր գաղափար է։ Թեև տվյալները պահվում են ընդհանուր հոսքերում, որոնց հասանելի են բոլոր ծառայությունները, ծառայության կողմից իրականացվող միավորումն ու մշակումը մասնավոր են: Նրանք հայտնվում են մեկուսացված խիստ սահմանափակ համատեքստում:

Վերացնել տվյալների երկատվածությունը՝ առանձնացնելով անփոփոխ վիճակի հոսքը: Այնուհետև ավելացրեք այս գործառույթը յուրաքանչյուր ծառայության մեջ՝ օգտագործելով Stateful Stream Processing-ը:

Այսպիսով, եթե ձեր ծառայությունը պետք է աշխատի պատվերների, ապրանքների կատալոգի, պահեստի հետ, այն կունենա լիարժեք մուտք. միայն դուք կորոշեք, թե ինչ տվյալներ համատեղել, որտեղ մշակել դրանք և ինչպես պետք է փոխվեն ժամանակի ընթացքում: Չնայած այն հանգամանքին, որ տվյալները կիսվում են, դրա հետ աշխատանքը լիովին ապակենտրոնացված է: Այն արտադրվում է յուրաքանչյուր ծառայության շրջանակներում, մի աշխարհում, որտեղ ամեն ինչ ընթանում է ձեր կանոններով:

Համօգտագործեք տվյալները՝ չխախտելով դրանց ամբողջականությունը: Ներառեք գործառույթը, այլ ոչ թե աղբյուրը, յուրաքանչյուր ծառայության մեջ, որը դրա կարիքն ունի:

Պատահում է, որ տվյալները զանգվածաբար պետք է տեղափոխվեն։ Երբեմն ծառայությունը պահանջում է տեղական պատմական տվյալների բազա ընտրված տվյալների շտեմարանում: Խաբեությունն այն է, որ դուք կարող եք երաշխավորել, որ անհրաժեշտության դեպքում պատճենը կարող է վերականգնվել աղբյուրից՝ մուտք գործելով բաշխված գրանցման մեխանիզմ: Կաֆկայի միակցիչները մեծ աշխատանք են կատարում այս հարցում:

Այսպիսով, այսօր քննարկված մոտեցումն ունի մի քանի առավելություններ.

• Տվյալներն օգտագործվում են ընդհանուր հոսքերի տեսքով, որոնք կարող են երկար ժամանակ պահվել տեղեկամատյաններում, իսկ ընդհանուր տվյալների հետ աշխատելու մեխանիզմը ներդաշնակված է յուրաքանչյուր առանձին համատեքստում, ինչը թույլ է տալիս ծառայություններին հեշտությամբ և արագ աշխատել: Այս կերպ տվյալների երկատվածությունը կարող է հավասարակշռվել։
• Տարբեր ծառայություններից ստացվող տվյալները հեշտությամբ կարելի է միավորել հավաքածուների մեջ: Սա հեշտացնում է փոխգործակցությունը ընդհանուր տվյալների հետ և վերացնում է տվյալների բազայում տեղական տվյալների շտեմարանների պահպանման անհրաժեշտությունը:
• Stateful Stream Processing-ը միայն պահում է տվյալները, իսկ ճշմարտության աղբյուրը մնում է ընդհանուր տեղեկամատյանները, ուստի ժամանակի ընթացքում տվյալների կոռուպցիայի խնդիրն այնքան էլ սուր չէ:
• Իրենց հիմքում ծառայությունները հիմնված են տվյալների վրա, ինչը նշանակում է, որ չնայած տվյալների անընդհատ աճող ծավալներին, ծառայությունները դեռ կարող են արագ արձագանքել բիզնես իրադարձություններին:
• Մասշտաբայնության խնդիրները ընկնում են բրոքերի վրա, ոչ թե ծառայությունների: Սա զգալիորեն նվազեցնում է գրելու ծառայությունների բարդությունը, քանի որ կարիք չկա մտածել մասշտաբայնության մասին:
• Նոր ծառայությունների ավելացումը չի պահանջում փոխել հինը, ուստի նոր ծառայությունների միացումն ավելի հեշտ է դառնում:

Ինչպես տեսնում եք, սա ավելին է, քան պարզապես ՀԱՆԳՍՏՈՒՄ: Մենք ստացել ենք մի շարք գործիքներ, որոնք թույլ են տալիս ապակենտրոնացված կերպով աշխատել ընդհանուր տվյալների հետ:

Այսօրվա հոդվածում ոչ բոլոր ասպեկտներն են լուսաբանվել: Մենք դեռ պետք է պարզենք, թե ինչպես հավասարակշռել հարցում-պատասխան պարադիգմը և իրադարձությունների վրա հիմնված պարադիգմը: Բայց մենք հաջորդ անգամ կզբաղվենք սրա հետ: Կան թեմաներ, որոնք դուք պետք է ավելի լավ ճանաչեք, օրինակ, թե ինչու է Stateful Stream Processing-ը այդքան լավ: Այս մասին կխոսենք երրորդ հոդվածում։ Եվ կան այլ հզոր կառուցվածքներ, որոնցից մենք կարող ենք օգտվել, եթե դիմենք դրանց, օրինակ. Հենց մեկ անգամ վերամշակում. Այն խաղափոխիչ է բաշխված բիզնես համակարգերի համար, քանի որ այն ապահովում է գործարքների երաշխիքներ XA մասշտաբային ձևով: Սա կքննարկվի չորրորդ հոդվածում։ Վերջապես, մենք պետք է անդրադառնանք այս սկզբունքների իրականացման մանրամասներին:

Բայց առայժմ, պարզապես հիշեք սա. տվյալների երկատվածությունը ուժ է, որի հետ մենք առնչվում ենք բիզնես ծառայություններ կառուցելիս: Եվ մենք պետք է հիշենք սա. Հնարքն այն է, որ ամեն ինչ շրջվի գլխի վրա և սկսենք ընդհանուր տվյալներին վերաբերվել որպես առաջին կարգի օբյեկտների: Stateful Stream Processing-ը դրա համար եզակի փոխզիջում է ապահովում: Այն խուսափում է կենտրոնացված «Աստծո բաղադրիչներից», որոնք հետ են պահում առաջընթացը: Ավելին, այն ապահովում է տվյալների հոսքային խողովակաշարերի շարժունությունը, մասշտաբայնությունը և ճկունությունը և ավելացնում դրանք յուրաքանչյուր ծառայության մեջ: Հետևաբար, մենք կարող ենք կենտրոնանալ գիտակցության ընդհանուր հոսքի վրա, որին ցանկացած ծառայություն կարող է կապվել և աշխատել իր տվյալների հետ: Սա ծառայությունները դարձնում է ավելի լայնածավալ, փոխանակելի և ինքնավար: Այսպիսով, դրանք ոչ միայն լավ տեսք կունենան գրատախտակների և հիպոթեզների թեստերի վրա, այլև կաշխատեն և կզարգանան տասնամյակներ շարունակ:

Իմացեք ավելին դասընթացի մասին:

Source: www.habr.com