JavaRush /Java блогы /Random-KK /Микросервис архитектурасы: оң және теріс жақтары
Roman Beekeeper
Деңгей

Микросервис архитектурасы: оң және теріс жақтары

Топта жарияланған
Микросервистер үлкен қолданбаны қарапайым API арқылы бір-бірімен байланысатын еркін байланысқан модульдерге бөлу тәсілі болып табылады.
Микросервис архитектурасы: оң және теріс жақтары - 1
Соңғы кездері тек мылқаулар ғана микросервис туралы айтпайды. Бұл барған сайын танымал болып келеді. Модульдік сәулет стилі бұлтқа негізделген орталарға өте қолайлы болып көрінеді және танымалдығы артып келеді. Егжей-тегжейлерге тоқталмас бұрын, бәріне құс көзімен қарайық . Сондықтан: Микросервистер үлкен жобаны шағын, тәуелсіз және еркін байланысқан модульдерге бөлу тәсілі болып табылады. Тәуелсіз модульдер нақты анықталған және дискретті тапсырмаларға жауап береді және қарапайым және қолжетімді API арқылы бір-бірімен байланысады. Басқаша айтқанда, микросервистер күрделі, негізінен веб-қосымшаларды жобалауға арналған басқа архитектуралық стиль болып табылады. Бірақ SOA (қызметке бағытталған архитектура) сияқты қолданыстағы архитектуралық шешімдердің несі жаман? SOA көмегімен жазылған заманауи кәсіпорын шешімдерінің көпшілігі өте жақсы жұмыс істейтін сияқты. Бұл саланың қазіргі кездегі кейбір қиындықтары туралы айтудың тамаша уақыты болуы мүмкін... Қарапайым мысалдан бастайық. Маған Java тілінде жазылған классикалық қолданбаны іске қосу керек делік. Алдымен мен пайдаланушы интерфейсін, содан кейін UI-мен өзара әрекеттесетін бірнеше компоненттері бар бизнес-логикалық деңгейді және ең соңында тұрақты дерекқорға қол жетімді болатын дерекқор қабатын дамытамын. Енді қолданбаны іске қосқым келетіні бойынша мен WAR/EAR/JAR жасап, оны serverге (мысалы, JBoss, Tomcat немесе WebLogic) орнатамын. Мұның бәрі бір жерде жасалғандықтан, мен монолитті қосымшаны аламын, яғни барлық компоненттер бір жерде... Суреттегі мысал:
Микросервис архитектурасы: оң және теріс жақтары - 2
Сірә, сіз бұл тәсілмен бұрыннан таныссыз және оны пайдаланғансыз, бірақ идея осы архитектуралық шешімді қолдану арқылы әзірлеушілер қандай қиындықтарға тап болатынын көрсету үшін осы мысалды пайдалану болып табылады. Монолитті қолдану: қиындықтарға қарсы
  • Қолданба өскен сайын жазылған code көлемі де артады, бұл оны ашу қажет болған сайын әзірлеу ортасын шамадан тыс жүктеуі мүмкін. Бұл әзірлеушінің тиімділігін төмендететіні сөзсіз.
  • Барлығы бір жерде орнатылуы керек болғандықтан, бұл басқа бағдарламалау тіліне ауысу немесе басқа технологияларға ауысу үлкен мәселе болып табылады. Мысалы, сіз Java тілінде қосымша жаздыңыз, ал біраз уақыттан кейін Котлин шықты және сіз оны қайта жазуға құлшындыңыз, өйткені ол салқынырақ , жақсырақ, жылдамырақ болды. Монолитті қолдану арқылы тіпті рефакторинг туралы ойлау процестің өзін айтпағанда, нақты ауырсынуды тудырады. Қазіргі уақытта осы жолмен жасалған көптеген қосымшалар бар және code жолдарының саны керемет.
  • Құрамдастардың кез келгені қандай да бір себептермен жұмысын тоқтатса , бүкіл қолданба да бұзылады. Authorизация, төлем, тарих және т.б. сияқты модульдері бар веб-қосымшаның бар екенін елестетіп көріңіз. Ал олардың біреуі қандай да бір себептермен бұзылады. Бұл бизнес үшін және нәтижесінде әзірлеушілер үшін жай ғана соққы.
  • Монолитті қолданбаны масштабтауға тек сол түрдегі басқа қолданбаны көтеру арқылы қол жеткізуге болады. Бірақ бүкіл қолданбаны емес, тек бір компонентті масштабтау қажет болса ше? Қанша ресурстар босқа кетеді?...
  • Бұл қолданбаның әзірлеу процесіне және орнату процесіне үлкен әсер етуі мүмкін. Қолданба неғұрлым үлкен болса, әзірлеушілер қолданбаны кішірек жұмыс бөліктеріне бөле алатындығы соншалықты маңызды. Монолитті қолданбадағы барлық модульдер бір-біріне қосылғандықтан, әзірлеушілер бұл модульдерді бір-бірінен тәуелсіз жұмыс істей/монтаждай алмайды. Әзірлеушілер бір-біріне тәуелді болғандықтан, әзірлеу уақыты артады.
Сонымен бірге біз микросервистердің мағынасын, атап айтқанда, SOA стилінде жоғалған икемділікті қалпына келтіру үшін оларды қалай пайдалануға болатынын қарастыруға және түсінуге дайынбыз. Құтқаруға арналған микросервистер Кез келген архитектуралық шешімдегі ең маңызды сипаттамалардың бірі - масштабтау. Мен микросервистерді алғаш рет үйреніп жатқанда, мен барлығының «Масштабтық өнері» кітабынан алынған дәйексөздерге ұқсас екенін көрдім. Бұл тамаша бастау және талқылау үшін орын. Бұл кітап үш өлшемді масштабтау жүйесін сипаттайтын "Масштабтау текшесі" деп аталатын үлгіні анықтайды:
Микросервис архитектурасы: оң және теріс жақтары - 3
Көріп отырғаныңыздай, X осі «көлденең масштабтауды» сипаттайды (бұл монолитті архитектуралар үшін де қол жетімді екенін көрдік), Y осі әртүрлі қызмет компоненттерін бөлу мағынасында масштабтауды білдіреді . Z осінің идеясы деректер бөлінген кезде түсініледі және қолданба деректердің нақты орналасқан жеріне сұрауларды жібереді. Яғни, олардың барлығы бір жерде емес. Y осінің идеясы - біз толығырақ тоқталамыз. Бұл ось функционалдық ыдырауды білдіреді . Бұл стратегияда әртүрлі функцияларды тәуелсіз қызметтер ретінде қарастыруға болады. Сондықтан, барлық қолданбаны тек барлығы орындалғанда ғана орнату арқылы әзірлеушілер жеке қызметтерді бір-бірінен тәуелсіз орната алады және басқалардың модульдерімен жұмысты аяқтауын күтпейді. Бұл әзірлеу уақытын жақсартып қана қоймайды, сонымен қатар қолданбаның қалған құрамдас бөліктері туралы алаңдамай, өзгерту және қайта қосу икемділігін ұсынады. Бұл диаграмманы алдыңғы монолитті диаграммамен салыстырайық:
Микросервис архитектурасы: оң және теріс жақтары - 4
Микросервистер: Артықшылықтар Микросервистердің артықшылықтары Amazon, Netflix, Ebay сияқты кәсіпорын әзірлеушілерін осы тәсілді қолдана бастауға сендіру үшін жеткілікті сияқты. Монолитті архитектуралық қосымшалардан айырмашылығы, микросервистер:
  • Құрамдас ақауларды оқшаулауды жақсартады: үлкен қолданбалар тіпті бір модуль сәтсіз болса да тиімді жұмыс істей береді.
  • Қолданбаның бір технологиялық стекке деген міндеттемесін жояды: қандай да бір қызметте жаңа технология стегін қолданып көргіңіз келсе, жалғастырыңыз. Тәуелділіктер монолиттіге қарағанда әлдеқайда жеңіл болады, сонымен қатар бәрін кері айналдыру оңайырақ болады. Бір қолданбадағы code неғұрлым аз болса, соғұрлым оның жұмыс істеуі оңайырақ.
  • Жаңа қызметкерлерге қызметтің функционалдығын түсінуді жеңілдетеді.
Микросервистер: монтаждау және виртуалдандыру ерекшеліктері Енді біз микросервистердің не екенін түсінеміз. Ең үлкен артықшылығы - оның бірнеше WAR/EAR/JAR мұрағаты арқылы орнатылғандығы. Бірақ ол қалай орнатылған? Микросервистерді контейнерлердің ішіне орнатудың ең жақсы жолы. Контейнер – конфигурацияланған қажетті ортасы бар толық конфигурацияланған виртуалды операциялық жүйе, ол контейнер орнатылған аппараттық жүйенің ресурстарына қол жеткізуді оқшаулауға көмектеседі. Нарықтағы ең танымал шешім, әрине, Docker . AWS сияқты IaaS (қызмет ретіндегі инфрақұрылым) виртуалды машиналары да микросервистерді орнату үшін жақсы жұмыс істей алады, бірақ салыстырмалы түрде жеңіл микросервистер виртуалды машинадағы барлық ресурстарды пайдаланбауы мүмкін, бұл пайдалану кірістілігін төмендетуі мүмкін. Сондай-ақ OSGI (Open Service Gateway Initiative) бумасын пайдаланып микросервистерді орнатуға болады . Бұл жағдайда барлық микросервистер бір JVM жүйесінде іске қосылады, бірақ бұл басқару мен оқшаулау арасындағы айырбастау мәселелерін қамтиды. Микросервистер: кемшіліктер «бәрі керемет» және «біз мұны бұрын көрмедік» дегені ешқандай кемшіліктер жоқ дегенді білдірмейді. Төменде микросервис архитектурасы өзімен бірге әкелетін ауырсынудың ықтимал аймақтарының тізімі берілген:
  • Бөлінген жүйелерді әзірлеу қиын болуы мүмкін. Бұл арқылы мен барлық құрамдастардың енді тәуелсіз қызметтер екенін айтқым келеді - модульдер арасында өтетін сұрауларды өте мұқият өңдеу керек. Бір модуль жауап бермей, жүйені бұзбау үшін қосымша code жазуға мәжбүр ететін сценарий болуы мүмкін. Қашықтағы қоңыраулар кешігуге сезімтал болса, бұл қиынырақ болуы мүмкін .
  • Көптеген дерекқорлар мен транзакцияларды басқару нағыз азап болуы мүмкін.
  • микросервис қолданбаларын сынау қиын болуы мүмкін. Монолитті қолданбаны пайдаланып, serverде WAR/EAR/JAR мұрағатын іске қосып, оның дерекқорға қосылғанына көз жеткізу керек. Ал микросервистерде тестілеуді бастамас бұрын әрбір жеке қызметті бастау керек.
  • Қолданбаларды орнату қиын болуы мүмкін. Олар WAR контейнері сияқты орнату оңай болмауы мүмкін бірнеше қызметтерді үйлестіруді қажет етуі мүмкін.
.... Әрине, дұрыс құралдар мен тәсілдер арқылы бұл кемшіліктерді болдырмауға болады. Бірақ олардың өздері қолдауды қажет етеді және барлық мәселелерді толығымен шеше алмайды. Мақала CloudAcademy веб- сайтынан аударылған . Еркін аударма. Пікірде әркім өз ойын еркін жеткізе алады. Олар міндетті түрде оқылады. Түпнұсқа мақала Менің Github тіркелгісі
Пікірлер
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION