19 қыркүйекте Мәскеуде микросервистерге арналған HUG (Highload++ User Group) бірінші тақырыптық кездесуі. «Микросервистерді пайдалану: сізде Kubernetes болса да өлшем маңызды» презентациясы болды, онда біз Flant компаниясының микросервис архитектурасы бар жобаларды басқарудағы үлкен тәжірибесімен бөлістік. Ең алдымен, бұл әдісті ағымдағы немесе болашақ жобасында қолдануды ойлайтын барлық әзірлеушілерге пайдалы болады.
Таныстыру (50 минут, мақаладан әлдеқайда мазмұнды), сондай-ақ одан негізгі үзінді мәтін түрінде.
Ескертпе: Бейне және презентация осы посттың соңында да бар.
Кіріспе
Әдетте жақсы әңгіменің басы, негізгі сюжеті және шешімі болады. Бұл репортаж прелюдия сияқты, әрі трагедиялық. Сондай-ақ, ол микросервистерге бөгде көзқарасты қамтамасыз ететінін атап өткен жөн. қанау.
Мен осы графиктен бастайын, оның авторы (2015 ж.) Мартин Фаулер:
Ол белгілі бір мәнге жеткен монолитті қолдану жағдайында өнімділіктің қалай төмендей бастайтынын көрсетеді. Микросервистердің айырмашылығы олармен бастапқы өнімділік төмен, бірақ күрделілік артқан сайын тиімділіктің төмендеуі олар үшін соншалықты байқалмайды.
Мен осы графикке Kubernetes пайдалану жағдайы үшін қосамын:
Микросервистері бар қолданба неге жақсы? Өйткені мұндай архитектура сәулетке күрделі талаптар қояды, олар өз кезегінде Кубернетес мүмкіндіктерімен тамаша қамтылған. Екінші жағынан, бұл функционалдылықтың кейбіреулері монолит үшін пайдалы болады, әсіресе типтік монолит бүгінгі күні дәл монолит емес болғандықтан (толық мәліметтер кейінірек есепте болады).
Көріп отырғаныңыздай, соңғы график (монолитті де, микросервис қосымшалары да Kubernetes инфрақұрылымында болған кезде) бастапқыдан айтарлықтай ерекшеленбейді. Әрі қарай Kubernetes көмегімен басқарылатын қолданбалар туралы айтатын боламыз.
Пайдалы және зиянды микросервистер
Міне, негізгі идея:
Бұл дегеніміз не? қалыпты жағдай микросервис архитектурасы? Ол сізге нақты пайда әкеліп, жұмыс тиімділігін арттыруы керек. Графикке қайта оралсақ, мінекей:
Егер сіз оған қоңырау шалсаңыз пайдалы, содан кейін графиктің екінші жағында болады зиянды микросервистер (жұмысқа кедергі жасайды):
«Негізгі идеяға» оралу: мен өз тәжірибеме сену керек пе? Осы жылдың басынан бері қарадым 85 жоба. Олардың барлығы микросервис емес (шамамен олардың үштен жартысында мұндай архитектура болды), бірақ бұл әлі де үлкен сан. Біз (Flant компаниясы) аутсорсинг ретінде шағын компанияларда да (5 әзірлеушімен) және ірі компанияларда (~500 әзірлеуші) әзірленген қосымшалардың кең ауқымын көреміз. Қосымша артықшылығы - біз бұл қолданбалардың өмір сүретінін және жылдар бойы дамып жатқанын көреміз.
Неліктен микросервистер?
Микросервистердің артықшылықтары туралы сұрақ туындайды жоғарыда аталған Мартин Фаулерден:
- модульдіктің нақты шекаралары;
- тәуелсіз орналастыру;
- технологияларды таңдау еркіндігі.
Мен бағдарламалық жасақтаманың сәулетшілерімен және әзірлеушілерімен көп сөйлесіп, микросервистердің не үшін қажет екенін сұрадым. Мен олардың үміттерін тізімдедім. Міне, оқиға:
Егер біз «сезімдегі» кейбір нүктелерді сипаттайтын болсақ, онда:
- модульдердің айқын шекаралары: мұнда бізде қорқынышты монолит бар, енді барлығы Git репозиторийлерінде ұқыпты орналастырылады, онда бәрі «сөрелерде», жылы және жұмсақ араласпаған;
- орналастырудың тәуелсіздігі: әзірлеу тезірек жүруі үшін қызметтерді дербес шығара аламыз (жаңа мүмкіндіктерді қатар жариялау);
- даму тәуелсіздігі: біз бұл микросервисті бір командаға/әзірлеушіге, ал екіншісін екіншісіне бере аламыз, соның арқасында біз тезірек дами аламыз;
- боүлкен сенімділік: егер ішінара деградация орын алса (20 микросервистің біреуі түсіп кетсе), онда тек бір түйме жұмысын тоқтатады, ал жүйе тұтастай жұмысын жалғастырады.
Микросервистің типтік (зиянды) архитектурасы
Неліктен шындық біз күткендей емес екенін түсіндіру үшін мен ұсынамын ұжымдық көптеген әртүрлі жобалардың тәжірибесіне негізделген микросервис архитектурасының бейнесі.
Мысал ретінде Amazon немесе кем дегенде OZON-пен бәсекелесетін дерексіз интернет-дүкен болуы мүмкін. Оның микросервис архитектурасы келесідей:
Себептердің тіркесімі бойынша бұл микросервистер әртүрлі платформаларда жазылған:
Әрбір микросервистің автономиясы болуы керек болғандықтан, олардың көпшілігіне жеке дерекқор мен кэш қажет. Соңғы архитектура келесідей:
Оның салдары қандай?
Бұл Фаулерде де бар — микросервистерді пайдаланғаны үшін «төлем» туралы:
Біздің үмітіміз ақталды ма, соны көреміз.
Модульдердің шекараларын тазалау...
бірақ қанша микросервисті түзетуіміз керек?өзгертуді енгізу керек пе? Біз тіпті таратылған тресерсіз бәрі қалай жұмыс істейтінін анықтай аламыз ба (ақырында, кез келген сұрау микросервистердің жартысы өңдейді)?
Үлгі бар»«, және бұл жерде ол бөлінген кір кесек болып шықты. Мұны растау үшін сұраулардың қалай жүретінін шамамен суреттеңіз:
Орналастыру тәуелсіздігі...
Техникалық тұрғыдан оған қол жеткізілді: біз әрбір микросервисті бөлек шығара аламыз. Бірақ іс жүзінде сіз оның үнемі шығып тұратынын ескеруіңіз керек көптеген микросервистер, және біз ескеруіміз керек оларды шығару тәртібі. Жақсы түрде, біз шығарылымды дұрыс ретпен шығарып жатқанымызды бөлек тізбекте тексеруіміз керек.
Технологияны таңдау еркіндігі...
Ол. Бостандық көбінесе заңсыздықпен шектесетінін есте сақтаңыз. Мұнда тек олармен «ойнау» үшін технологияларды таңдамау өте маңызды.
Дамудың тәуелсіздігі...
Бүкіл қолданба үшін сынақ циклін қалай жасауға болады (сонша құрамдас бөліктермен)? Бірақ сіз оны әлі де жаңартып отыруыңыз керек. Мұның бәрі осыған әкеледі сынақ тізбектерінің нақты саны, біз негізінен қамтуы мүмкін, минималды болып шығады.
Осының барлығын жергілікті жерде орналастырғанға не жетсін?.. Көбінесе әзірлеуші өз жұмысын өз бетінше жасайды, бірақ «кездейсоқ», өйткені ол схема тестілеу үшін бос болғанша күтуге мәжбүр болады.
Бөлек масштабтау...
Ия, бірақ ол қолданылатын ДҚБЖ аймағында шектелген. Берілген архитектуралық мысалда Кассандрада проблемалар болмайды, бірақ MySQL және PostgreSQL.
Божоғары сенімділік ...
Шындығында бір микросервистің істен шығуы бүкіл жүйенің дұрыс жұмыс істеуін жиі бұзып қана қоймайды, сонымен қатар жаңа мәселе бар: әрбір микросервисті ақауларға төзімді ету өте қиын. Микросервистерде әртүрлі технологиялар (memcache, Redis және т.
Жүктеменің өлшенуі...
Бұл шынымен жақсы.
Микросервистердің «жеңілдігі»...
Бізде тек үлкен емес желілік үстеме шығындар (DNS сұраулары көбейіп жатыр және т.б.), сонымен қатар біз бастаған көптеген ішкі сұрауларға байланысты деректерді қайталау (дүкен кэштері), бұл сақтаудың айтарлықтай көлеміне әкелді.
Міне, біздің үмітімізді ақтау нәтижесі:
Бірақ бұл бәрі емес!
Себебі:
- Бізге хабарлар автобусы қажет болуы мүмкін.
- Уақытында дұрыс уақытта дәйекті сақтық көшірмені қалай жасауға болады? Жалғыз нақты опциясы бұл үшін трафикті өшіру болып табылады. Бірақ мұны өндірісте қалай жасауға болады?
- Егер біз бірнеше аймақты қолдау туралы айтатын болсақ, олардың әрқайсысында тұрақтылықты ұйымдастыру өте көп еңбекті қажет ететін жұмыс.
- Орталықтандырылған өзгерістер енгізу мәселесі туындайды. Мысалы, PHP нұсқасын жаңарту қажет болса, біз әрбір репозиторийге міндеттеме алуымыз керек (және олардың ондағандары бар).
- Операциялық күрделіліктің өсуі экспоненциалды болып табылады.
Мұның бәрін не істеу керек?
Монолитті қолданбадан бастаңыз. Фоулердің тәжірибесі барлық дерлік сәтті микросервис қолданбалары монолит ретінде басталды, ол тым үлкен болып, содан кейін бұзылды. Сонымен қатар, микросервис ретінде құрылған жүйелердің барлығы дерлік ерте ме, кеш пе күрделі мәселелерге тап болды.
Тағы бір құнды ой, микросервис архитектурасы бар жоба сәтті болуы үшін сіз өте жақсы білуіңіз керек және пәндік аймақ және микросервистерді қалай жасау керек. Ал пәндік саланы меңгерудің ең жақсы жолы - монолит жасау.
Бірақ біз қазірдің өзінде осы жағдайға тап болсақ ше?
Кез келген мәселені шешудің бірінші қадамы - онымен келісіп, оның проблема екенін, біз бұдан былай қиналуды қаламайтынымызды түсіну.
Егер монолит өсіп кеткен жағдайда (ол үшін қосымша ресурстарды сатып алу мүмкіндігіміз таусылған кезде) біз оны кесіп тастасақ, онда бұл жағдайда керісінше оқиға шығады: шамадан тыс микросервис бұдан былай көмектеспей, бірақ кедергі болғанда - артығын кесіп, үлкейту!
Мысалы, жоғарыда талқыланған ұжымдық бейне үшін...
Ең күмәнді микросервистерден құтылыңыз:
Frontend генерациясына жауапты барлық микросервистерді біріктіріңіз:
... бір микросервиске, бір тілде/фрамворда жазылған (заманауи және қалыпты, өзіңіз ойлағандай):
Оның бір ORM (бір ДҚБЖ) және алдымен бірнеше қосымшалары болады:
... бірақ жалпы алғанда, сіз келесі нәтижеге қол жеткізе отырып, көп нәрсені аудара аласыз:
Сонымен қатар, Kubernetes-те біз мұның бәрін бөлек данада орындаймыз, яғни біз әлі де жүктемені өлшей аламыз және оларды бөлек масштабтай аламыз.
қорытындысын
Үлкенірек суретке қараңыз. Көбінесе микросервистерге қатысты осы мәселелердің барлығы біреу өз міндетін атқарып, бірақ «микросервистермен ойнағысы» келгендіктен туындайды.
«Микросервис» сөзінде «микро» бөлігі артық.. Олар үлкен монолиттен кішірек болғандықтан ғана «микро» болып табылады. Бірақ оларды кішкентай нәрсе деп санамаңыз.
Ал соңғы ой үшін бастапқы диаграммаға оралайық:
Онда жазылған жазба (жоғарғы оң жақ) осыған байланысты Сіздің жобаңызды жасайтын команданың дағдылары әрқашан басты болып табылады — олар микросервис пен монолит арасындағы таңдауда маңызды рөл атқарады. Егер команданың дағдылары жеткіліксіз болса, бірақ ол микросервистерді жасай бастаса, оқиға міндетті түрде өлімге әкеледі.
Бейнелер мен слайдтар
Сөйлеуден алынған бейне (~50 минут; өкінішке орай, ол келушілердің көптеген эмоцияларын білдірмейді, бұл көбінесе баяндаманың көңіл-күйін анықтады, бірақ солай):
Баяндаманы көрсету:
PS
Біздің блогтағы басқа есептер:
- «» (Дмитрий Столяров; 28 жылғы 2018 мамырда RootConf сайтында);
- «» (Дмитрий Столяров; 7 жылғы 2017 қарашада HighLoad++);
- «» (Дмитрий Столяров; 6 жылғы 2017 маусымда RootConf сайтында);
- «» (Дмитрий Столяров; 8 жылғы 2016 қарашада HighLoad++);
- «» (Дмитрий Столяров; 31 жылғы 2016 мамырда RootConf сайтында).
Сізді келесі жарияланымдар қызықтыруы мүмкін:
- ««;
- ««;
- ««.
Ақпарат көзі: www.habr.com