Провели сте месеце редизајнирајући свој монолит у микроуслуге, и коначно су се сви окупили да пребаце прекидач. Одете на прву веб страницу... и ништа се не дешава. Поново га учитате - и опет ништа добро, сајт је толико спор да не реагује неколико минута. Шта се десило?
У свом говору, Џими Богард ће спровести „пост мортем” катастрофу микросервиса у стварном животу. Он ће показати проблеме моделирања, развоја и производње које је открио и како је његов тим полако трансформисао нови дистрибуирани монолит у коначну слику здравог разума. Иако је немогуће у потпуности спречити грешке у дизајну, можете барем идентификовати проблеме рано у процесу дизајна како бисте осигурали да коначни производ постане поуздан дистрибуирани систем.
Здраво свима, ја сам Џими и данас ћете чути како можете да избегнете мега катастрофе приликом изградње микросервиса. Ово је прича о компанији за коју сам радио око годину и по да бих спречио њихов брод да се судари са сантом леда. Да бисмо ову причу испричали на прави начин, мораћемо да се вратимо у прошлост и разговарамо о томе одакле је ова компанија почела и како је њена ИТ инфраструктура временом расла. Да бих заштитио имена невиних у овој катастрофи, променио сам назив ове компаније у Белл Цомпутерс. Следећи слајд показује како је изгледала ИТ инфраструктура таквих компанија средином 90-их. Ово је типична архитектура великог универзалног ХП Тандем Маинфраме сервера отпорног на грешке за рад продавнице рачунарског хардвера.
Требало им је да изграде систем за управљање свим поруџбинама, продајом, повратима, каталозима производа и базом купаца, тако да су изабрали најчешће решење за маинфраме у то време. Овај џиновски систем је садржао сваки делић информација о компанији, све могуће, а свака трансакција се обављала преко овог главног рачунара. Сва јаја су држали у једној корпи и сматрали су да је то нормално. Једина ствар која овде није укључена су каталози за поруџбину поштом и наруџбине путем телефона.
Временом је систем постајао све већи и већи, а у њему се накупила огромна количина смећа. Такође, ЦОБОЛ није најизразитији језик на свету, тако да је систем на крају постао велико, монолитно смеће. До 2000. године видели су да многе компаније имају веб-сајтове преко којих су обављале апсолутно све своје послове и одлучили су да направе свој први комерцијални дот-цом веб-сајт.
Почетни дизајн је изгледао прилично лепо и састојао се од сајта белл.цом највишег нивоа и низа поддомена за појединачне апликације: цаталог.белл.цом, аццоунтс.белл.цом, ордерс.белл.цом, сеарцх.белл за претрагу производа. цом. Сваки поддомен је користио АСП.Нет 1.0 оквир и сопствене базе података, и сви су разговарали са позадином система. Међутим, све наруџбине су наставиле да се обрађују и извршавају у оквиру једног огромног главног рачунара, у коме је остало сво смеће, али су предњи део били одвојени веб-сајтови са појединачним апликацијама и засебним базама података.
Дакле, дизајн система је изгледао уредно и логично, али стварни систем је био као што је приказано на следећем слајду.
Сви елементи су упућивали позиве једни другима, приступали АПИ-јима, уграђеним длл-овима треће стране и слично. Често се дешавало да системи за контролу верзија зграбе туђи код, угурају га у пројекат и онда се све поквари. МС СКЛ Сервер 2005 користио је концепт линк сервера, и иако нисам показао стрелице на слајду, свака од база је такође разговарала једна са другом, јер нема ништа лоше у прављењу табела на основу података добијених из неколико база података.
Пошто су сада имали извесну раздвојеност између различитих логичких области система, ово је постало дистрибуирана мрља прљавштине, са највећим комадом смећа који је још увек остао у позадини главног рачунара.
Смешно је било то што су овај мејнфрејм направили конкуренти компаније Белл Цомпутерс и да су га још увек одржавали њихови технички консултанти. Уверена у незадовољавајуће перформансе својих апликација, компанија је одлучила да их се реши и редизајнира систем.
Постојећа апликација је била у производњи 15 година, што је рекорд за апликације засноване на АСП.Нет-у. Сервис је прихватао поруџбине из целог света, а годишњи приход од ове јединствене апликације достигао је милијарду долара. Значајан део профита генерисао је сајт белл.цом. На Црни петак, број поруџбина извршених преко сајта достигао је неколико милиона. Међутим, постојећа архитектура није дозвољавала било какав развој, пошто круте међусобне везе елемената система практично нису дозвољавале било какве промене у сервису.
Најозбиљнији проблем је била немогућност да се наручи из једне земље, плати у другој и пошаље у трећу, упркос чињеници да је таква шема трговања веома честа у светским компанијама. Постојећа веб локација није дозвољавала ништа слично, па су морали да прихвате и дају ове поруџбине преко телефона. Ово је довело до тога да компанија све више размишља о промени архитектуре, посебно о преласку на микросервисе.
Урадили су паметну ствар гледајући друге компаније да виде како су решили сличан проблем. Једно од ових решења била је архитектура Нетфлик сервиса, која се састоји од микросервиса повезаних преко АПИ-ја и екстерне базе података.
Менаџмент Белл Цомпутерс-а одлучио је да изгради управо такву архитектуру, придржавајући се одређених основних принципа. Прво, елиминисали су дуплицирање података користећи приступ дељеној бази података. Подаци нису послати, напротив, сви којима су били потребни морали су да оду до централизованог извора. Након тога је уследила изолација и аутономија – свака служба је била независна од других. Одлучили су да користе Веб АПИ за апсолутно све – ако сте желели да добијете податке или направите измене на другом систему, све је то урађено преко Веб АПИ-ја. Последња велика ствар био је нови мејнфрејм под називом „Белл он Белл“ за разлику од „Белл“ главног рачунара заснованог на хардверу конкурената.
Дакле, током 18 месеци, изградили су систем око ових основних принципа и довели га у претпродукцију. Вративши се на посао после викенда, програмери су се окупили и укључили све сервере на које је био повезан нови систем. 18 месеци рада, стотине програмера, најсавременији Белл хардвер - и никакав позитиван резултат! Ово је разочарало многе људе јер су користили овај систем на својим лаптопима много пута и све је било у реду.
Били су паметни да уложе сав свој новац на решавање овог проблема. Инсталирали су најсавременије серверске рекове са прекидачима, користили гигабитна оптичка влакна, најмоћнији серверски хардвер са суманутом количином РАМ-а, све то повезали, конфигурисали – и опет ништа! Онда су почели да сумњају да је разлог можда тајмаут, па су ушли у сва веб подешавања, сва подешавања АПИ-ја и ажурирали целу конфигурацију временског ограничења на максималне вредности, тако да је све што су могли да ураде било да седе и чекају да се нешто деси на сајт. Чекали су и чекали и чекали 9 и по минута док се веб локација коначно не учита.
Након тога им је синуло да је тренутна ситуација потребна темељна анализа и позвали су нас. Прво што смо сазнали је да током свих 18 месеци развоја није створен ниједан прави „микро“ – све је само постајало веће. Након тога, почели смо да пишемо пост мортем, познат и као „ретроспектива“, или „тужна ретроспектива“, такође познат као „олуја кривице“, слично „олуји мозга“, да бисмо разумели узрок катастрофе.
Имали смо неколико назнака, од којих је један био потпуна засићеност саобраћаја у време АПИ позива. Када користите монолитну архитектуру услуге, можете одмах да разумете шта је тачно пошло наопако јер имате једно праћење стека које извештава о свему што је могло да изазове неуспех. У случају када гомила услуга истовремено приступа истом АПИ-ју, не постоји начин да се прати траг осим да се користе додатни алати за праћење мреже као што је ВиреСхарк, захваљујући којима можете испитати један захтев и сазнати шта се десило током његове имплементације. Тако смо узели једну веб страницу и провели скоро 2 недеље састављајући делове слагалице, позивајући се на разне позиве и анализирајући до чега је сваки од њих довео.
Погледај ову слику. Показује да један екстерни захтев тражи од услуге да обави много интерних позива који се враћају назад. Испоставља се да сваки интерни позив прави додатне скокове како би могао самостално да сервисира овај захтев, јер не може да се обрати никуда другде да би добио потребне информације. Ова слика изгледа као бесмислена каскада позива, пошто спољни захтев позива додатне сервисе, који позивају друге додатне услуге, и тако даље, скоро до бесконачности.
Зелена боја на овом дијаграму показује полукруг у којем се услуге међусобно позивају - сервис А позива сервис Б, сервис Б позива сервис Ц и поново позива сервис А. Као резултат, добијамо „дистрибуирани застој“. Један захтев је створио хиљаду мрежних АПИ позива, а пошто систем није имао уграђену толеранцију грешака и заштиту од петље, захтев би пропао ако чак и један од ових АПИ позива није успео.
Урадили смо математику. Сваки АПИ позив је имао СЛА од не више од 150 мс и 99,9% непрекидног рада. Један захтев је изазвао 200 различитих позива, а у најбољем случају страница би се могла приказати у 200 к 150 мс = 30 секунди. Наравно, ово није било добро. Помноживши 99,9% времена рада са 200, добили смо 0% доступности. Испоставило се да је ова архитектура од самог почетка била осуђена на пропаст.
Питали смо програмере како нису препознали овај проблем након 18 месеци рада? Испоставило се да су они рачунали само СЛА за код који су водили, али ако је њихова служба позвала другу услугу, то време нису рачунали у свом СЛА. Све што је покренуто у оквиру једног процеса придржавало се вредности од 150 мс, али је приступ другим сервисним процесима вишеструко повећао укупно кашњење. Прва научена лекција била је: „Да ли ви контролишете свој СЛА или СЛА контролише вас?“ У нашем случају, било је ово друго.
Следеће што смо открили је да су знали за концепт заблуда о дистрибуираном рачунарству, који су формулисали Питер Дајч и Џејмс Гослинг, али су игнорисали први део. У њему се наводи да су изјаве „мрежа је поуздана“, „нулта латенција“ и „бесконачна пропусност“ погрешна схватања. Друге заблуде укључују изјаве „мрежа је безбедна“, „топологија се никада не мења“, „увек постоји само један администратор“, „трошак преноса података је нула“ и „мрежа је хомогена“.
Направили су грешку јер су тестирали своју услугу на локалним машинама и никада се нису повезивали са спољним сервисима. Када су развијали локално и користили локални кеш, никада нису наишли на мрежне скокове. Током свих 18 месеци развоја, никада се нису запитали шта би се могло десити ако би спољне услуге биле погођене.
Ако погледате границе услуге на претходној слици, можете видети да су све нетачне. Постоји много извора који саветују како да дефинишете границе услуге, а већина то чини погрешно, као што је Мицрософт на следећем слајду.
Ова слика је са МС блога на тему „Како направити микросервисе“. Ово показује једноставну веб апликацију, блок пословне логике и базу података. Захтев долази директно, вероватно постоји један сервер за веб, један сервер за посао и један за базу података. Ако повећате промет, слика ће се мало променити.
Овде долази балансатор оптерећења за дистрибуцију саобраћаја између два веб сервера, кеш који се налази између веб услуге и пословне логике, и други кеш између пословне логике и базе података. То је управо архитектура коју је Белл користио за балансирање оптерећења и плаво/зелену апликацију за примену средином 2000-их. До неког времена све је функционисало добро, пошто је ова шема била намењена монолитној структури.
Следећа слика показује како МС препоручује прелазак са монолита на микросервисе – једноставно поделите сваку од главних услуга у засебне микросервисе. Током имплементације ове шеме, Белл је направио грешку.
Све своје услуге су поделили на различите нивое, од којих се сваки састојао од много појединачних услуга. На пример, веб сервис је укључивао микросервисе за приказивање садржаја и аутентификацију, сервис пословне логике састојао се од микросервиса за обраду налога и информација о налогу, база података је подељена на гомилу микросервиса са специјализованим подацима. И веб, пословна логика и база података били су сервиси без држављанства.
Међутим, ова слика је била потпуно погрешна јер није мапирала ниједну пословну јединицу ван ИТ кластера компаније. Ова шема није узела у обзир никакву везу са спољним светом, тако да није било јасно како, на пример, добити пословну аналитику треће стране. Напомињем да су имали и неколико услуга измишљених само да развију каријере појединачних запослених који су настојали да управљају што већим бројем људи како би за то добили више новца.
Веровали су да је прелазак на микроуслуге био лак као да се узме њихова интерна Н-слојна инфраструктура физичког слоја и стави Доцкер на њу. Хајде да погледамо како изгледа традиционална Н-слојна архитектура.
Састоји се од 4 нивоа: нивоа корисничког интерфејса корисничког интерфејса, нивоа пословне логике, нивоа приступа подацима и базе података. Прогресивнији је ДДД (Домаин-Дривен Десигн), или софтверски оријентисана архитектура, где су два средња нивоа објекти домена и спремиште.
Покушао сам да сагледам различите области промена, различите области одговорности у овој архитектури. У типичној примени Н-слоја, различите области промене су класификоване које прожимају структуру вертикално од врха до дна. Ово су Каталог, подешавања конфигурације која се врше на појединачним рачунарима и провере наплате, којима је управљао мој тим.
Посебност ове шеме је да границе ових области промене утичу не само на ниво пословне логике, већ се протежу и на базу података.
Погледајмо шта значи бити сервис. Постоји 6 карактеристичних особина дефиниције услуге - то је софтвер који:
- креирана и коришћена од стране одређене организације;
- одговоран је за садржај, обраду и/или пружање одређене врсте информација у оквиру система;
- могу се изградити, распоредити и покренути независно да би се задовољиле специфичне оперативне потребе;
- комуницира са потрошачима и другим услугама, пружајући информације на основу споразума или уговорних гаранција;
- штити себе од неовлашћеног приступа, а своје информације од губитка;
- управља кваровима на начин да не доводе до оштећења информација.
Сва ова својства могу се изразити једном речју „аутономија“. Услуге раде независно једна од друге, задовољавају одређена ограничења и дефинишу уговоре на основу којих људи могу да добију информације које су им потребне. Нисам поменуо конкретне технологије чија се употреба подразумева сама по себи.
Сада погледајмо дефиницију микросервиса:
- микросервис је мале величине и дизајниран да реши један специфичан проблем;
- Микросервис је аутономан;
- Приликом креирања микросервисне архитектуре користи се урбанистичка метафора. Ово је дефиниција из књиге Сема Њумана, Изградња микросервиса.
Дефиниција ограниченог контекста је преузета из књиге Ерица Еванса Домаин-Дривен Десигн. Ово је основни образац у ДДД-у, центру за дизајн архитектуре који ради са волуметријским архитектонским моделима, делећи их у различите ограничене контексте и експлицитно дефинишући интеракције између њих.
Једноставно речено, ограничени контекст означава опсег у којем се одређени модул може користити. У овом контексту је логички обједињени модел који се може видети, на пример, у вашем пословном домену. Ако особљу укљученом у поруџбине питате „ко је клијент“, добићете једну дефиницију, ако питате оне који се баве продајом, добићете другу, а извођачи ће вам дати трећу дефиницију.
Дакле, Ограничени контекст каже да ако не можемо дати јасну дефиницију шта је потрошач наших услуга, хајде да дефинишемо границе унутар којих можемо да говоримо о значењу овог појма, а затим дефинишемо прелазне тачке између ових различитих дефиниција. Односно, ако говоримо о клијенту са становишта наручивања, ово значи то и то, а ако са становишта продаје, ово значи ово и оно.
Следећа дефиниција микросервиса је инкапсулација било које врсте интерних операција, спречавајући „цурење“ компоненти радног процеса у окружење. Затим следи „дефиниција експлицитних уговора за спољне интеракције, или екстерне комуникације“, која је представљена идејом уговора који се враћају из СЛА. Последња дефиниција је метафора ћелије, односно ћелије, која означава потпуну инкапсулацију скупа операција унутар микросервиса и присуство у њему рецептора за комуникацију са спољним светом.
Зато смо рекли момцима из Белл Цомпутерс-а: „Не можемо да поправимо хаос који сте направили јер једноставно немате новца да то урадите, али поправићемо само једну услугу да све то учини смисао.” У овом тренутку, почећу тако што ћу вам рећи како смо поправили нашу једину услугу тако да је одговарала на захтеве брже од 9 и по минута.
22:30 мин
Ускоро ће се наставити...
Нека реклама
Хвала вам што сте остали са нама. Да ли вам се свиђају наши чланци? Желите да видите још занимљивијег садржаја? Подржите нас тако што ћете наручити или препоручити пријатељима, , јединствени аналог сервера почетног нивоа, који смо ми измислили за вас: (доступно са РАИД1 и РАИД10, до 24 језгра и до 40 ГБ ДДР4).
Делл Р730кд 2 пута јефтинији у Екуиник Тиер ИВ дата центру у Амстердаму? Само овде у Холандији! Делл Р420 - 2к Е5-2430 2.2Гхз 6Ц 128ГБ ДДР3 2к960ГБ ССД 1Гбпс 100ТБ - од 99 долара! Читали о
Извор: ввв.хабр.цом