Сіз монолитті микросервистерге қайта құруға бірнеше ай жұмсадыңыз және соңында барлығы қосқышты ауыстыру үшін жиналды. Сіз бірінші веб-бетке кіресіз... және ештеңе болмайды. Сіз оны қайта жүктеңіз - және тағы да жақсы ештеңе жоқ, сайт соншалықты баяу, ол бірнеше минут бойы жауап бермейді. Не болды?
Джимми Богард өз баяндамасында микросервистің шынайы өміріндегі апат туралы «өлімнен кейінгі» зерттеу жүргізеді. Ол модельдеу, әзірлеу және өндіру мәселелерін және оның командасының жаңа бөлінген монолитті ақырындап ақыл-ойдың соңғы суретіне қалай өзгерткенін көрсетеді. Дизайн қателерінің алдын алу мүмкін болмаса да, соңғы өнімнің сенімді таратылатын жүйеге айналуын қамтамасыз ету үшін, кем дегенде, жобалау процесінің басында проблемаларды анықтауға болады.
Барлығына сәлем, мен Джиммимін және бүгін сіз микросервистерді құру кезінде мега апаттардан қалай аулақ болуға болатынын тыңдайсыз. Бұл кеменің айсбергпен соқтығысуына жол бермеу үшін мен бір жарым жылдай жұмыс істеген компанияның тарихы. Бұл оқиғаны дұрыс айту үшін өткенге оралып, бұл компанияның қай жерде басталғаны және уақыт өте келе оның IT инфрақұрылымы қалай өскені туралы сөйлесуіміз керек. Осы апатта кінәсіз адамдардың есімдерін қорғау үшін мен бұл компанияның атын Bell Computers деп өзгерттім. Келесі слайд 90-жылдардың ортасында мұндай компаниялардың IT-инфрақұрылымы қандай болғанын көрсетеді. Бұл компьютерлік жабдық дүкенін басқаруға арналған үлкен әмбебап ақауларға төзімді HP Tandem Mainframe серверінің типтік архитектурасы.
Оларға барлық тапсырыстарды, сатылымдарды, қайтарымдарды, өнім каталогтарын және тұтынушылар базасын басқару жүйесін құру қажет болды, сондықтан олар сол кездегі ең көп таралған негізгі фрейм шешімін таңдады. Бұл алып жүйе компания туралы барлық ақпаратты, мүмкін болатын барлық нәрсені қамтиды және әрбір транзакция осы негізгі фрейм арқылы жүзеге асырылды. Олар барлық жұмыртқаларын бір себетке салып, бұл қалыпты жағдай деп есептеді. Мұнда қосылмаған жалғыз нәрсе - пошталық тапсырыс каталогтары және телефон арқылы тапсырыс беру.
Уақыт өте келе жүйе ұлғайып, оған қоқыс көп жиналды. Сондай-ақ, COBOL әлемдегі ең мәнерлі тіл емес, сондықтан жүйе үлкен, монолитті қоқыс бөлігі болды. 2000 жылға қарай олар көптеген компаниялардың веб-сайттары бар екенін көрді, олар арқылы барлық бизнестерін жүргізеді және өздерінің алғашқы коммерциялық dot-com веб-сайттарын құруға шешім қабылдады.
Бастапқы дизайн өте жақсы көрінді және жоғары деңгейлі bell.com сайтынан және жеке қолданбаларға арналған бірқатар ішкі домендерден тұрды: catalog.bell.com, accounts.bell.com, orders.bell.com, өнім іздеу search.bell. com. Әрбір ішкі домен ASP.Net 1.0 құрылымын және өзінің дерекқорын пайдаланды және олардың барлығы жүйе серверімен сөйлесті. Дегенмен, барлық тапсырыстар барлық қоқыс қалған жалғыз үлкен мэйнфреймде өңделуін және орындалуын жалғастырды, бірақ алдыңғы жағы жеке қолданбалары мен бөлек дерекқорлары бар бөлек веб-сайттар болды.
Осылайша, жүйенің дизайны реттелген және логикалық көрінді, бірақ нақты жүйе келесі слайдта көрсетілгендей болды.
Барлық элементтер бір-біріне қоңырауларды жіберді, API интерфейстеріне қол жеткізді, ендірілген үшінші тарап DLL файлдары және т.б. Көбінесе нұсқаларды басқару жүйелері басқа біреудің кодын басып алып, оны жобаның ішіне кіргізеді, содан кейін бәрі бұзылады. MS SQL Server 2005 сілтеме серверлері тұжырымдамасын қолданды, мен слайдта көрсеткілерді көрсетпесем де, деректер қорының әрқайсысы бір-бірімен сөйлесті, өйткені бірнеше дерекқордан алынған деректер негізінде кестелерді құрудың ешбір қатесі жоқ.
Олар қазір жүйенің әртүрлі логикалық аймақтары арасында біршама алшақтыққа ие болғандықтан, бұл негізгі фрейм серверінде әлі де қалған ең үлкен қоқыс бөлігімен үлестірілген ластануға айналды.
Бір қызығы, бұл негізгі компьютерді Bell Computers бәсекелестері құрастырған және әлі де олардың техникалық кеңесшілері қолдаған. Қолданбаларының қанағаттанарлықсыз жұмысына көз жеткізген компания олардан құтылып, жүйені қайта құру туралы шешім қабылдады.
Қолданыстағы қолданба 15 жыл бойы өндірісте болды, бұл ASP.Net негізіндегі қолданбалар үшін рекордтық көрсеткіш. Сервис әлемнің түкпір-түкпірінен тапсырыстарды қабылдады және осы жалғыз қосымшадан жылдық табыс миллиард долларға жетті. Пайданың едәуір бөлігін bell.com веб-сайты құрады. Қара жұма күндері сайт арқылы берілген тапсырыстардың саны бірнеше миллионға жетті. Дегенмен, қолданыстағы архитектура ешқандай дамуға мүмкіндік бермеді, өйткені жүйе элементтерінің қатаң өзара байланыстары қызметке ешқандай өзгерістер енгізуге іс жүзінде мүмкіндік бермеді.
Ең күрделі мәселе, мұндай сауда схемасы әлемдік компанияларда өте кең таралғанына қарамастан, бір елден тапсырыс беріп, оны басқа елде төлеп, оны үшінші елге жібере алмау болды. Қолданыстағы веб-сайт мұндай нәрсеге рұқсат бермеді, сондықтан олар бұл тапсырыстарды телефон арқылы қабылдауға және орналастыруға мәжбүр болды. Бұл компанияның архитектураны өзгерту, атап айтқанда микросервистерге ауысу туралы көбірек ойлауына әкелді.
Олар ұқсас мәселені қалай шешкенін көру үшін басқа компанияларға қарап, ақылды нәрсені жасады. Осы шешімдердің бірі API және сыртқы дерекқор арқылы қосылған микросервистерден тұратын Netflix сервис архитектурасы болды.
Bell Computers басшылығы белгілі бір негізгі принциптерді сақтай отырып, дәл осындай архитектураны құруға шешім қабылдады. Біріншіден, олар ортақ дерекқор тәсілін қолдану арқылы деректердің қайталануын жойды. Ешқандай деректер жіберілмеді, керісінше, оны қажет ететіндердің барлығы орталықтандырылған дереккөзге баруға мәжбүр болды. Бұдан кейін оқшаулану және автономия болды - әрбір қызмет басқалардан тәуелсіз болды. Олар Web API интерфейсін мүлдем барлығы үшін пайдалануды ұйғарды - егер сіз деректерді алғыңыз келсе немесе басқа жүйеге өзгерістер енгізгіңіз келсе, барлығы Web API арқылы жасалды. Соңғы үлкен нәрсе бәсекелестердің аппараттық құралдарына негізделген «Қоңырау» негізгі фрейміне қарағанда «Қоңыраудағы қоңырау» деп аталатын жаңа негізгі фрейм болды.
Осылайша, 18 ай ішінде олар жүйені осы негізгі принциптерге сай құрып, оны өндіріске дейін жеткізді. Демалыс күнінен кейін жұмысқа оралған әзірлеушілер жиналып, жаңа жүйе қосылған барлық серверлерді қосты. 18 айлық жұмыс, жүздеген әзірлеушілер, ең заманауи Bell жабдығы - оң нәтиже жоқ! Бұл көптеген адамдардың көңілін қалдырды, өйткені олар бұл жүйені ноутбуктарында бірнеше рет іске қосты және бәрі жақсы болды.
Олар бұл мәселені шешуге бар ақшаларын жұмсау үшін ақылды болды. Олар коммутаторлары бар ең заманауи сервер сөрелерін орнатты, гигабиттік оптикалық талшықты, оперативті жадының ең қуатты серверлік жабдықты пайдаланды, барлығын қосты, конфигурациялады - және тағы да ештеңе! Содан кейін олар себебі күту уақыты болуы мүмкін деп күдіктене бастады, сондықтан олар барлық веб-параметрлерге, барлық API параметрлеріне кіріп, барлық күту уақытының конфигурациясын максималды мәндерге дейін жаңартты, осылайша олар бірдеңе болғанша күте алады. сайтқа. Олар күтті, күтті және веб-сайт ақыры жүктелгенше 9 жарым минут күтті.
Осыдан кейін оларға қазіргі жағдайды жан-жақты сараптау керектігін түсініп, бізді шақырды. Біз анықтаған бірінші нәрсе, дамудың 18 айының ішінде бірде-бір нақты «микро» жасалмады - бәрі тек қана үлкен болды. Осыдан кейін біз апаттың себебін түсіну үшін «регретроспективалық» немесе «қайғылы ретроспектива» деп те аталатын «кінәлі дауыл» деп аталатын, «ми дауылына» ұқсас өлімнен кейінгі жазуды жаза бастадық.
Бізде бірнеше анықтамалар болды, олардың бірі API қоңырауы кезінде трафиктің толық қанықтығы болды. Монолитті қызмет архитектурасын пайдаланған кезде, сізде қателік тудыруы мүмкін барлық нәрселер туралы хабарлайтын жалғыз стек ізі болғандықтан, дәл ненің дұрыс емес екенін бірден түсіне аласыз. Бірдей API-ге бір уақытта қызметтердің шоғыры қол жеткізген жағдайда, WireShark сияқты желіні бақылаудың қосымша құралдарын пайдаланудан басқа ізді қадағалаудың ешқандай жолы жоқ, соның арқасында сіз бір сұрауды тексеріп, оны орындау кезінде не болғанын біле аласыз. Сонымен, біз бір веб-парақшаны алып, пазл бөліктерін біріктіріп, оған әртүрлі қоңыраулар шалып, олардың әрқайсысы не әкелгенін талдауға шамамен 2 апта жұмсадық.
Мына суретке қараңдар. Ол бір сыртқы сұрау қызметке кері қайтарылатын көптеген ішкі қоңыраулар жасауға шақыратынын көрсетеді. Әрбір ішкі қоңырау осы сұрауға өз бетінше қызмет көрсету үшін қосымша секірулер жасайтыны белгілі болды, өйткені ол қажетті ақпаратты алу үшін басқа жерге бұрыла алмайды. Бұл сурет қоңыраулардың мағынасыз каскады сияқты көрінеді, өйткені сыртқы сұрау қосымша қызметтерді шақырады, олар басқа қосымша қызметтерді шақырады және т.б. дерлік ad infinitum.
Бұл диаграммадағы жасыл түс жарты шеңберді көрсетеді, онда қызметтер бір-бірін шақырады – А қызметі В қызметіне, В қызметі С қызметіне, ал ол қайтадан А қызметіне қоңырау шалады.Нәтижесінде біз «таратылған тығырықтан» аламыз. Бір сұрау мың желілік API қоңырауларын жасады және жүйеде ақауларға төзімділік пен цикл қорғанысы болмағандықтан, осы API қоңырауларының біреуі сәтсіз болса да сұрау орындалмай қалады.
Біз математикалық есеп жүргіздік. Әрбір API шақыруында 150 мс аспайтын SLA және 99,9% жұмыс уақыты болды. Бір сұрау 200 түрлі қоңырауды тудырды және ең жақсы жағдайда бетті 200 x 150 мс = 30 секундта көрсетуге болады. Әрине, бұл жақсы болмады. 99,9% жұмыс уақытын 200-ге көбейтсек, біз 0% қолжетімділікке ие болдық. Бұл архитектура әу бастан сәтсіздікке ұшыраған екен.
Біз әзірлеушілерден 18 айлық жұмыстан кейін бұл мәселені қалай тани алмағанын сұрадық? Белгілі болғандай, олар тек SLA-ны өздері басқарған код үшін санаған, бірақ егер олардың қызметі басқа қызметті шақырса, олар SLA-да бұл уақытты есептемеген. Бір процесте іске қосылғанның барлығы 150 мс мәнін ұстанды, бірақ басқа қызмет көрсету процестеріне қол жеткізу жалпы кідірісті бірнеше есе арттырды. Алынған бірінші сабақ: «Сіз SLA басқарасыз ба, әлде SLA сізді бақылайды ма?» Біздің жағдайда бұл соңғы болды.
Біз анықтаған келесі нәрсе, олар Питер Дейч пен Джеймс Гослинг тұжырымдаған үлестірілген есептеулер туралы қате түсініктер туралы білетін, бірақ олар оның бірінші бөлігін елемеген. Онда «желі сенімді», «нөлдік кідіріс» және «шексіз өткізу қабілеті» мәлімдемелері қате түсініктер екені айтылған. Басқа қате түсініктерге «желі қауіпсіз», «топология ешқашан өзгермейді», «әрқашан бір ғана әкімші болады», «деректерді тасымалдау құны нөлге тең» және «желі біртекті» деген тұжырымдарды қамтиды.
Олар қателесті, себебі олар өз қызметтерін жергілікті машиналарда сынап көрді және ешқашан сыртқы қызметтерге қосылмаған. Жергілікті түрде дамытқанда және жергілікті кэшті пайдаланған кезде, олар ешқашан желілік хоптарды кездестірмеген. Барлық 18 айлық даму барысында олар сыртқы қызметтерге әсер етсе не болатынын ешқашан ойлаған емес.
Алдыңғы суреттегі қызмет көрсету шекараларына қарасаңыз, олардың барлығы дұрыс емес екенін көруге болады. Қызмет шекараларын анықтау бойынша кеңес беретін көптеген дереккөздер бар және көпшілігі келесі слайдтағы Microsoft сияқты қате жасайды.
Бұл сурет «Микросервистерді қалай құруға болады» тақырыбындағы MS блогынан алынған. Бұл қарапайым веб-қосымшаны, бизнес логика блогын және дерекқорды көрсетеді. Сұрау тікелей келеді, мүмкін бір сервер веб үшін, бір сервер бизнес үшін және біреуі дерекқор үшін. Егер сіз трафикті арттырсаңыз, сурет аздап өзгереді.
Мұнда екі веб-сервер арасында трафикті таратуға арналған жүктеме балансы, веб-қызмет пен бизнес логикасы арасында орналасқан кэш және бизнес логикасы мен дерекқор арасындағы басқа кэш келеді. Бұл дәл 2000-шы жылдардың ортасында жүктемені теңестіру және көк/жасыл орналастыру қолданбасы үшін пайдаланылған Bell архитектурасы. Біраз уақытқа дейін бәрі жақсы жұмыс істеді, өйткені бұл схема монолитті құрылымға арналған.
Төмендегі суретте MS монолиттен микросервистерге көшуді қалай ұсынатынын көрсетеді - негізгі қызметтердің әрқайсысын бөлек микросервистерге бөлу. Дәл осы схеманы жүзеге асыру кезінде Белл қателік жіберді.
Олар өздерінің барлық қызметтерін әртүрлі деңгейлерге бөлді, олардың әрқайсысы көптеген жеке қызметтерден тұрды. Мысалы, веб-сервис мазмұнды көрсету және аутентификация үшін микросервистерді қамтыды, бизнес-логикалық қызмет тапсырыстарды және тіркелгі ақпаратын өңдеуге арналған микросервистерден тұрды, деректер базасы мамандандырылған деректері бар микросервистердің тобына бөлінген. Веб, бизнес логикасы және дерекқордың екеуі де азаматтығы жоқ қызметтер болды.
Дегенмен, бұл сурет мүлдем қате болды, өйткені ол компанияның АТ кластерінен тыс ешбір бөлімшелерді көрсетпеген. Бұл схема сыртқы әлеммен ешқандай байланысты ескермеді, сондықтан, мысалы, үшінші тарап бизнес-аналитикасын қалай алуға болатыны түсініксіз болды. Сондай-ақ оларда жеке қызметкерлердің мансабын дамыту үшін бірнеше қызметтер ойлап табылғанын атап өтемін, олар бұл үшін көбірек ақша алу үшін мүмкіндігінше көп адамдарды басқаруға тырысты.
Олар микросервистерге көшу N-деңгейінің ішкі физикалық қабатының инфрақұрылымын алып, оған Docker-ді жабыстыру сияқты оңай деп есептеді. N-деңгейінің дәстүрлі архитектурасы қандай болатынын қарастырайық.
Ол 4 деңгейден тұрады: UI пайдаланушы интерфейсі деңгейі, іскери логикалық деңгей, деректерге қол жеткізу деңгейі және дерекқор. Неғұрлым прогрессивті DDD (доменге негізделген дизайн) немесе бағдарламалық қамтамасыз етуге бағытталған архитектура, мұнда екі орта деңгей домен нысандары мен репозиторий болып табылады.
Мен бұл сәулеттегі өзгерістердің әртүрлі салаларын, әртүрлі жауапкершілік салаларын қарастыруға тырыстым. Әдеттегі N-деңгейлі қолданбада құрылымды жоғарыдан төменге қарай тігінен өткізетін әртүрлі өзгерістер аймақтары жіктеледі. Бұл Каталог, жеке компьютерлерде орындалатын конфигурация параметрлері және менің командам өңдеген Checkout тексерулері.
Бұл схеманың ерекшелігі мынада: бұл өзгерістер аймақтарының шекаралары бизнес логикалық деңгейіне ғана емес, сонымен қатар мәліметтер базасына да әсер етеді.
Қызмет болу деген нені білдіретінін қарастырайық. Қызмет анықтамасының 6 сипатты қасиеті бар – бұл бағдарламалық қамтамасыз ету, ол:
- белгілі бір ұйым жасаған және пайдаланатын;
- жүйе ішіндегі ақпараттың белгілі бір түрін мазмұндауға, өңдеуге және/немесе қамтамасыз етуге жауапты;
- арнайы операциялық қажеттіліктерді қанағаттандыру үшін дербес салынуы, орналастырылуы және іске қосылуы мүмкін;
- келісімдер немесе шарттық кепілдіктер негізінде ақпарат бере отырып, тұтынушылармен және басқа қызметтермен байланыс жасайды;
- өзін рұқсатсыз кіруден, ал оның ақпаратын жоғалтудан қорғайды;
- сәтсіздіктерді ақпараттың бұзылуына әкелмейтіндей өңдейді.
Бұл қасиеттердің барлығын бір сөзбен «автономия» деп айтуға болады. Қызметтер бір-бірінен тәуелсіз жұмыс істейді, белгілі бір шектеулерді қанағаттандырады және адамдар қажетті ақпаратты ала алатын шарттарды анықтайды. Мен нақты технологияларды атап өткен жоқпын, олардың қолданылуы өзінен-өзі түсінікті.
Енді микросервистердің анықтамасын қарастырайық:
- микросервис көлемі жағынан шағын және бір нақты мәселені шешуге арналған;
- Микросервис автономды болып табылады;
- Микросервис архитектурасын құру кезінде қала құрылысы метафорасы қолданылады. Бұл Сэм Ньюманның «Құрылыс микросервистері» кітабындағы анықтама.
Шектелген контекст анықтамасы Эрик Эванстың Доменге негізделген дизайн кітабынан алынған. Бұл көлемді архитектуралық үлгілермен жұмыс істейтін, оларды әртүрлі Шектелген мәтінмәндерге бөлетін және олардың арасындағы өзара әрекеттесуді нақты анықтайтын DDD, сәулет дизайн орталығының негізгі үлгісі.
Қарапайым тілмен айтқанда, Шектелген контекст белгілі бір модульді пайдалануға болатын аумақты білдіреді. Бұл контексте, мысалы, сіздің бизнес доменіңізде көруге болатын логикалық біріктірілген үлгі бар. Тапсырыстарға қатысатын персоналдан «клиент кім» деп сұрасаңыз, сіз бір анықтама аласыз, сатумен айналысатындардан сұрасаңыз, сіз басқасын аласыз, ал орындаушылар сізге үшінші анықтаманы береді.
Сонымен, Шектелген контекст егер біз қызметтерімізді тұтынушы дегеннің нақты анықтамасын бере алмасақ, осы терминнің мағынасы туралы сөйлесуге болатын шекараларды анықтап алайық, содан кейін осы әртүрлі анықтамалар арасындағы өтпелі нүктелерді анықтайық. Яғни, егер тапсырыс беру тұрғысынан клиент туралы айтатын болсақ, бұл мынаны және ананы білдіреді, ал егер сату тұрғысынан алғанда, бұл осы және басқаны білдіреді.
Микросервистің келесі анықтамасы жұмыс процесінің құрамдас бөліктерінің қоршаған ортаға «ағып кетуіне» жол бермей, кез келген түрдегі ішкі операцияларды инкапсуляциялау болып табылады. Одан кейін SLA-дан қайтарылатын келісім-шарттар идеясымен ұсынылған «сыртқы өзара әрекеттесу немесе сыртқы коммуникациялар үшін айқын келісімшарттардың анықтамасы» келеді. Соңғы анықтама микросервис ішіндегі операциялар жиынтығының толық инкапсуляциясын және ондағы сыртқы әлеммен байланыс үшін рецепторлардың болуын білдіретін ұяшық немесе ұяшық метафорасы болып табылады.
Сондықтан біз Bell Computers компаниясының жігіттеріне былай дедік: «Біз сіз жасаған хаостың ешқайсысын түзете алмаймыз, өйткені сізде мұны істеуге ақша жоқ, бірақ барлығын жасау үшін бір ғана қызметті жөндейміз. сезім». Осы сәтте мен сұрауларға 9 жарым минуттан тезірек жауап беретіндей жалғыз қызметімізді қалай жөндегенімізді айтып бастаймын.
22:30 мин
Жақында жалғасын табады...
Кішкене жарнама
Бізбен бірге болғандарыңызға рахмет. Сізге біздің мақалалар ұнайды ма? Қызықты мазмұнды көргіңіз келе ме? Тапсырыс беру немесе достарыңызға ұсыну арқылы бізге қолдау көрсетіңіз, , Сіз үшін біз ойлап тапқан бастапқы деңгейдегі серверлердің бірегей аналогы: (RAID1 және RAID10, 24 ядроға дейін және 40 ГБ DDR4 дейін қол жетімді).
Dell R730xd Амстердамдағы Equinix Tier IV деректер орталығында 2 есе арзан ба? Тек осында Нидерландыда! Dell R420 - 2x E5-2430 2.2 ГГц 6C 128 ГБ DDR3 2x960 ГБ SSD 1 Гбит/с 100 ТБ - 99 доллардан бастап! туралы оқыңыз
Ақпарат көзі: www.habr.com