Бәріңе сәлем! Бізде тамаша жаңалық бар, OTUS курсты маусым айында қайтадан бастайды , осыған байланысты біз сіздермен дәстүрлі түрде пайдалы материал бөлісеміз.
Егер сіз осы микросервистердің бүкіл тарихын кез келген контекстсіз кездестірсеңіз, оны сәл оғаш деп ойлағаныңыз үшін кешіресіз. Қолданбаны желі арқылы қосылған фрагменттерге бөлу міндетті түрде нәтижесінде бөлінген жүйеге күрделі ақауларға төзімділік режимдерін қосуды білдіреді.
Бұл тәсіл көптеген тәуелсіз қызметтерге бөлуді қамтыса да, түпкі мақсат сол қызметтерді әртүрлі машиналарда іске қосудан әлдеқайда көп. Бұл жерде біз сыртқы әлеммен өзара әрекеттесу туралы айтып отырмыз, ол да өзінің мәні бойынша таратылады. Техникалық мағынада емес, көптеген адамдардан, командалардан, бағдарламалардан тұратын экожүйе мағынасында және бұл бөліктердің әрқайсысы қандай да бір жолмен өз жұмысын орындауы керек.
Компаниялар, мысалы, белгілі бір мақсатқа жетуге ықпал ететін бөлінген жүйелердің жиынтығы. Біз бұл фактіні ондаған жылдар бойы елемей келеміз, жеке мақсаттарымызға назар аудара отырып, FTP трансферттері немесе кәсіпорынды біріктіру құралдары арқылы біріктіруге тырысамыз. Бірақ қызметтердің пайда болуымен бәрі өзгерді. Қызметтер бізге көкжиектен тыс қарауға және бірге жұмыс істейтін өзара тәуелді бағдарламалар әлемін көруге көмектесті. Дегенмен, табысты жұмыс істеу үшін түбегейлі екі түрлі әлемді тану және жобалау қажет: біз көптеген басқа қызметтердің экожүйесінде өмір сүретін сыртқы әлем және біз жалғыз басқаратын жеке, ішкі әлеміміз.
Мұндай үлестірілген дүние біз өскен және үйренген дүниеден өзгеше. Дәстүрлі монолитті архитектураны құру принциптері сынға төтеп бере алмайды. Осылайша, бұл жүйелерді дұрыс пайдалану әдемі тақта диаграммасын жасау немесе тұжырымдаманың керемет дәлелін жасау ғана емес. Мұндай жүйе ұзақ уақыт табысты жұмыс істейді деген идея. Бақытымызға орай, қызметтер басқаша көрінсе де, біршама уақыт болды. әлі де өзекті, тіпті Докер, Кубернетес және сәл тозған хипстер сақалдарымен дәмдес.
Сондықтан бүгін біз ережелердің қалай өзгергенін, неге біз қызметтерге және олар бір-біріне беретін деректерге деген көзқарасымызды қайта қарастыруымыз керек және ол үшін неліктен мүлдем басқа құралдар жинағы қажет болатынын қарастырамыз.
Инкапсуляция әрқашан сіздің досыңыз бола бермейді
Микросервистер бір-бірінен тәуелсіз жұмыс істей алады. Дәл осы қасиет оларға ең үлкен құндылық береді. Дәл осы қасиет қызметтерді масштабтауға және өсіруге мүмкіндік береді. Квадриллиондаған пайдаланушыларға немесе петабайттарға дейін масштабтау тұрғысынан емес (бірақ олар мұнда да көмектесе алады), бірақ командалар мен ұйымдар үздіксіз өсетіндіктен, адамдар тұрғысынан масштабтау тұрғысынан.
Әйтсе де, тәуелсіздік – екі жүзді қылыш. Яғни, қызметтің өзі оңай және табиғи түрде айнала алады. Бірақ егер функция басқа қызметтің қатысуын талап ететін қызмет ішінде іске асырылса, біз екі қызметке де бір уақытта дерлік өзгерістер енгізуге тура келеді. Монолитте мұны істеу оңай, сіз жай ғана өзгеріс енгізіп, оны шығаруға жібересіз, бірақ тәуелсіз қызметтерді синхрондау жағдайында проблемалар көбірек болады. Командалар мен босату циклдері арасындағы үйлестіру икемділікті бұзады.
Стандартты тәсілдің бөлігі ретінде олар функционалдылықты қызметтер арасында нақты бөле отырып, тітіркендіргіш өзгерістерді болдырмауға тырысады. Мұнда бір рет кіру қызметі жақсы мысал бола алады. Оның басқа қызметтерден ерекшеленетін нақты анықталған рөлі бар. Бұл анық бөліну оның айналасындағы қызметтерге қойылатын талаптардың тез өзгеретін әлемінде SSO-ның өзгеруі екіталай екенін білдіреді. Ол қатаң шектелген контексте бар.
Мәселе мынада, нақты әлемде іскерлік қызметтер рөлдердің бірдей таза бөлінуін үнемі сақтай алмайды. Мысалы, бірдей бизнес қызметтері басқа ұқсас қызметтерден келетін деректермен көбірек жұмыс істейді. Егер сіз онлайн сатушы болсаңыз, тапсырыс ағынын, өнім каталогын немесе пайдаланушы ақпаратын өңдеу көптеген қызметтеріңіз үшін талап болады. Қызметтердің әрқайсысы жұмыс істеуі үшін осы деректерге рұқсат қажет болады.
Іскерлік қызметтердің көпшілігі бірдей деректер ағынын пайдаланады, сондықтан олардың жұмысы үнемі өзара байланысты.
Осылайша, біз әңгімелеуге тұрарлық маңызды мәселеге келдік. Қызметтер негізінен оқшауланған түрде жұмыс істейтін инфрақұрылым құрамдастары үшін жақсы жұмыс істегенімен, бизнес қызметтерінің көпшілігі бір-бірімен тығыз байланыста болады.
Деректер дихотомиясы
Қызметке бағытталған тәсілдер бұрыннан бар болуы мүмкін, бірақ қызметтер арасында деректердің үлкен көлемін алмасу жолы туралы ақпарат әлі де аз.
Басты мәселе деректер мен қызметтерді бір-бірінен ажыратуға болмайды. Бір жағынан, инкапсуляция қызметтерді бір-бірінен ажыратып, олардың өсуі мен одан әрі өзгеруін жеңілдету үшін деректерді жасыруға итермелейді. Екінші жағынан, біз басқалар сияқты ортақ деректерді еркін бөліп, жеңе білуіміз керек. Бұл кез келген басқа ақпараттық жүйедегідей еркін жұмысқа бірден кірісу туралы.
Дегенмен, ақпараттық жүйелердің инкапсуляцияға қатысы жоқ. Шындығында, бұл тіпті керісінше. Деректер базалары сақталатын деректерге қол жеткізу үшін қолдан келгеннің бәрін жасайды. Олар деректерді қалағаныңызша өзгертуге мүмкіндік беретін қуатты декларативті интерфейспен келеді. Мұндай функционалдылық алдын ала зерттеу сатысында маңызды, бірақ үнемі дамып келе жатқан қызметтің өсіп келе жатқан күрделілігін басқару үшін емес.
Және бұл жерде дилемма туындайды. Қарама-қайшылық. Дихотомия. Өйткені, ақпараттық жүйелер деректерді беру, ал қызметтер жасыру болып табылады.
Бұл екі күш негізгі болып табылады. Олар біз жасайтын жүйелерде үнемі үстемдікке ұмтылып, біздің жұмысымыздың көп бөлігін құрайды.
Қызмет көрсету жүйелері өсіп, дамып келе жатқанда, біз деректер дихотомиясының салдарларының әртүрлі көріністерін көреміз. Немесе қызмет интерфейсі барған сайын көбірек функционалдылықты қамтамасыз ету үшін өседі және өте сәнді үйдегі дерекқорға ұқсай бастайды немесе біз ренжіп, бүкіл деректер жиынын қызметтен қызметке жаппай алудың немесе жылжытудың қандай да бір әдісін іске асырамыз.
Өз кезегінде, сәнді homebrew дерекқорына ұқсайтын нәрсені жасау көптеген мәселелерге әкеледі. Біз ненің қауіпті екенін егжей-тегжейлі қарастырмаймыз ортақ деректер базасы, бұл айтарлықтай қымбат инженерлік және пайдалануды білдіреді делік оны пайдалануға тырысатын компания үшін.
Ең сорақысы, деректер көлемі қызмет шекараларымен байланысты мәселелерді көбейтеді. Сервис ішінде неғұрлым кең таралған деректер болса, интерфейс соғұрлым күрделі болады және әртүрлі қызметтерден келетін деректер жиынын біріктіру қиынырақ болады.
Толық деректер жиынын шығару және жылжытудың балама тәсілінің де өз проблемалары бар. Бұл сұраққа жалпы көзқарас бүкіл деректер жинағын жай ғана шығарып алу және сақтау, содан кейін оны әрбір тұтынушы қызметте жергілікті түрде сақтау болып табылады.
Мәселе мынада, әртүрлі қызметтер олар тұтынатын деректерді басқаша түсіндіреді. Бұл деректер әрқашан қол астында. Олар жергілікті деңгейде өзгертіліп, өңделеді. Көп ұзамай олар дереккөздегі деректермен байланысын тоқтатады.
Көшірмелер неғұрлым өзгермелі болса, соғұрлым деректер уақыт өте өзгереді.
Одан да сорақысы, мұндай деректерді ретроспективті түрде түзету қиын ( бұл жерде ол шынымен де пайдалы.) Шындығында, бизнестің кейбір шешілмейтін технологиялық қиындықтары қолданбадан қолданбаға дейін көбейетін гетерогенді деректерден туындайды.
Бұл ортақ деректер мәселесінің шешімін табу үшін басқаша ойлау керек. Олар біз жасайтын архитектуралардағы бірінші сыныпты нысандарға айналуы керек. мұндай деректерді «сыртқы» деп атайды және бұл өте маңызды функция. Бізге қызметтің ішкі бөліктерін ашпау үшін инкапсуляция қажет, бірақ қызметтерді олардың жұмысын дұрыс орындауы үшін ортақ деректерге қол жеткізуді жеңілдету керек.
Мәселе мынада, бірде-бір тәсіл бүгінгі күні өзекті емес, өйткені қызмет интерфейстері де, хабар алмасу да, ортақ дерекқор да сыртқы деректермен жұмыс істеу үшін жақсы шешім ұсынбайды. Қызметтік интерфейстер кез келген масштабта деректер алмасуға жарамсыз. Хабар алмасу деректерді жылжытады, бірақ оның тарихын сақтамайды, сондықтан деректер уақыт өте келе бүлінеді. Ортақ дерекқорлар бір нүктеге тым көп шоғырланған, бұл прогресті тежейді. Біз міндетті түрде деректердің сәтсіздігі циклінде тұрып қаламыз:
Деректер ақауының циклі
Ағындар: деректер мен қызметтерге орталықтандырылмаған тәсіл
Ең дұрысы, қызметтердің ортақ деректермен жұмыс істеу тәсілін өзгертуіміз керек. Қазіргі уақытта кез келген тәсіл жоғарыда айтылған дихотомияға түседі, өйткені оған жомарттықпен себіліп, жойылатын сиқырлы шаң жоқ. Дегенмен, мәселені қайта қарастырып, ымыраға келе аламыз.
Бұл ымыраға келу белгілі бір орталықтандыру деңгейін білдіреді. Біз үлестірілген тіркеу механизмінің артықшылығын пайдалана аламыз, өйткені ол сенімді, масштабталатын ағындарды қамтамасыз етеді. Енді біз қызметтер осы ортақ ағындарға қосылып, жұмыс істей алатынын қалаймыз, бірақ біз бұл өңдеуді жүзеге асыратын күрделі орталықтандырылған Құдай қызметтерінен аулақ болғымыз келеді. Сондықтан, ең жақсы нұсқа - әрбір тұтынушылық қызметке ағынды өңдеуді құру. Бұл қызметтерге әртүрлі көздерден алынған деректер жиынын біріктіруге және олармен қажетті түрде жұмыс істеуге мүмкіндік береді.
Бұл тәсілге жетудің бір жолы ағынды платформаны пайдалану болып табылады. Көптеген нұсқалар бар, бірақ бүгін біз Кафканы қарастырамыз, өйткені оның Stateful Stream Processing пайдалануы ұсынылған мәселені тиімді шешуге мүмкіндік береді.
Бөлінген журналды тіркеу механизмін пайдалану бізге жеңіл жолды ұстануға және жұмыс істеу үшін хабар алмасуды пайдалануға мүмкіндік береді . Бұл тәсіл сұрау-жауап механизміне қарағанда жақсырақ масштабтауды және бөлуді қамтамасыз етеді деп саналады, себебі ол жіберушіге емес, қабылдаушыға ағынды басқаруды береді. Дегенмен, сіз бұл өмірде бәрін төлеуіңіз керек, ал бұл жерде сізге брокер керек. Бірақ үлкен жүйелер үшін бұл ымыраға тұрарлық (бұл сіздің орташа веб-қосымшаларыңыз туралы айта алмайсыз).
Егер брокер дәстүрлі хабар алмасу жүйесі емес, таратылған журналға жауапты болса, сіз қосымша мүмкіндіктерді пайдалана аласыз. Тасымалдалған файлдық жүйе сияқты сызықты дерлік масштабтауға болады. Деректер журналдарда ұзақ уақыт сақталуы мүмкін, сондықтан біз хабар алмасуды ғана емес, сонымен қатар ақпарат репозиторийін де аламыз. Өзгермелі ортақ күйден қорықпай, масштабталатын сақтау.
Содан кейін тұтынушы қызметтеріңізге декларативті дерекқор құралдарын қосу үшін күйді ағынды өңдеу механизмін пайдалануға болады. Бұл өте маңызды ой. Деректер барлық қызметтер қол жеткізе алатын ортақ ағындарда сақталғанша, қызмет жасайтын біріктіру және өңдеу жеке болып табылады. Олар қатаң шектелген контексте оқшауланған.
Өзгермейтін күй ағынын бөлу арқылы деректер дихотомиясынан құтылыңыз. Содан кейін бұл функцияны күйді ағынды өңдеу арқылы әрбір қызметке қосыңыз.
Осылайша, егер сіздің қызметіңіз тапсырыстармен, өнім каталогымен, қоймамен жұмыс істеуі керек болса, ол толық қолжетімділікке ие болады: тек сіз қандай деректерді біріктіру керектігін, оны қайда өңдеу керектігін және уақыт өте келе қалай өзгеретінін шешесіз. Деректер ортақ болғанына қарамастан, онымен жұмыс істеу толығымен орталықсыздандырылған. Ол әр қызметте, барлығы сіздің ережелеріңізге сәйкес жүретін әлемде шығарылады.
Деректердің тұтастығын бұзбай ортақ пайдаланыңыз. Қажетті әрбір қызметте көзді емес, функцияны инкапсуляциялаңыз.
Сондықтан деректерді жаппай жылжыту қажет болады. Кейде қызметке таңдаулы дерекқор механизмінде жергілікті тарихи деректер жинағы қажет. Тапсырма мынада: қажет болған жағдайда таратылған тіркеу механизміне хабарласу арқылы көшірмені көзден қалпына келтіруге болатынына кепілдік беруге болады. Кафкадағы қосқыштар мұны тамаша жасайды.
Сонымен, бүгін талқыланатын әдіс бірнеше артықшылықтарға ие:
- Деректер ұзақ уақыт бойы журналдарда сақталуы мүмкін ортақ ағындар түрінде пайдаланылады және ортақ деректермен жұмыс істеу механизмі әрбір жеке контекстте бекітілген, бұл қызметтердің оңай және жылдам жұмыс істеуіне мүмкіндік береді. Осылайша, деректердің дихотомиясын теңестіруге болады.
- Әртүрлі қызметтерден келетін деректерді жинақтарға оңай біріктіруге болады. Бұл ортақ деректермен өзара әрекеттесуді жеңілдетеді және дерекқордағы жергілікті деректер жиынын сақтау қажеттілігін жояды.
- Stateful Stream Processing тек деректерді кэштейді, ал жалпы журналдар шындықтың көзі болып қалады, сондықтан уақыт өте келе деректердің бүліну мәселесі соншалықты өткір емес.
- Негізінде қызметтер деректерге негізделген, яғни деректер көлемінің тұрақты өсуіне қарамастан, қызметтер әлі де іскерлік оқиғаларға жылдам жауап бере алады.
- Масштабтау мәселелері қызметтерге емес, брокерге түседі. Бұл жазу қызметтерінің күрделілігін айтарлықтай азайтады, өйткені масштабтау туралы ойлаудың қажеті жоқ.
- Жаңа қызметтерді қосу ескілерін өзгертуді қажет етпейді, сондықтан жаңа қызметтерді қосу оңайырақ болады.
Көріп отырғаныңыздай, бұл жай ғана REST емес. Біз орталықтандырылмаған түрде ортақ деректермен жұмыс істеуге мүмкіндік беретін құралдар жиынтығын алдық.
Бүгінгі мақалада барлық аспектілер ашылған жоқ. Біз әлі де сұрау-жауап парадигмасы мен оқиғаға негізделген парадигма арасындағы тепе-теңдікті анықтауымыз керек. Бірақ келесі жолы бұл мәселемен айналысамыз. Сізге жақсырақ білу қажет тақырыптар бар, мысалы, күйді ағынды өңдеу неге соншалықты жақсы. Бұл туралы үшінші мақалада айтатын боламыз. Егер біз оларға жүгінсек, біз пайдалана алатын басқа да күшті конструкциялар бар, мысалы, . Бұл транзакциялық кепілдіктерді қамтамасыз ететіндіктен, таратылған бизнес жүйелері үшін ойынды өзгертуші масштабталатын пішінде. Бұл төртінші мақалада талқыланады. Ақырында, біз осы принциптерді жүзеге асырудың егжей-тегжейлерін қарастыруымыз керек.
Бірақ әзірше мынаны есте сақтаңыз: деректер дихотомиясы - бұл бизнес қызметтерін құру кезінде кездесетін күш. Және біз мұны есте сақтауымыз керек. Бұл трюк барлығын өз бетімен бұрып, ортақ деректерді бірінші дәрежелі нысандар ретінде қарастыруды бастау болып табылады. Stateful Stream Processing бұл үшін бірегей компромиссті қамтамасыз етеді. Ол прогрессті тежейтін орталықтандырылған «Құдай құрамдастарынан» аулақ болады. Сонымен қатар, ол деректер ағыны құбырларының ептілігін, ауқымдылығын және тұрақтылығын қамтамасыз етеді және оларды әрбір қызметке қосады. Сондықтан біз кез келген қызмет оның деректерімен қосылып, жұмыс істей алатын жалпы сана ағынына назар аудара аламыз. Бұл қызметтерді масштабталатын, ауыстырылатын және автономды етеді. Сондықтан олар тақтада және гипотезаларды тексеру кезінде жақсы көрініп қана қоймайды, сонымен қатар ондаған жылдар бойы жұмыс істейді және дамиды.
Ақпарат көзі: www.habr.com