Вы патрацілі месяцы, перарабляючы свой маналіт у мікрасэрвісы, і нарэшце, усе сабраліся, каб пстрыкнуць выключальнікам. Вы пераходзіце на першую вэб-старонку… і нічога не адбываецца. Перазагружаеце яе - і зноў нічога добрага, сайт працуе так павольна, што не адказвае на працягу некалькіх хвілін. Што ж здарылася?
У сваім выступе Джымі Богард правядзе «пасмяротнае выкрыццё» рэальнай катастрофы мікрасэрвісу. Ён пакажа праблемы мадэлявання, распрацоўкі і вытворчасці, якія выявіў, і раскажа, як яго каманда павольна трансфармавала новы размеркаваны маналіт у канчатковую карціну разважнасці. Хоць цалкам прадухіліць памылкі праекту немагчыма, можна, прынамсі, выявіць праблемы на ранняй стадыі праектавання, каб канчатковы прадукт ператварыўся ў надзейную размеркаваную сістэму.
Вітаю ўсіх, я Джымі, і сёння вы пачуеце, як можна пазбегнуць мегакатастроф пры стварэнні мікрасэрвісаў. Гэтая гісторыя кампаніі, у якой я прапрацаваў каля паўтара года, каб дапамагчы прадухіліць сутыкненне іх карабля з айсбергам. Каб расказаць гэтую гісторыю належным чынам, давядзецца вярнуцца ў мінулае і пагаварыць аб тым, з чаго пачыналася гэтая кампанія і як з часам расла яе ІТ-інфраструктура. Каб абараніць імёны невінаватых у гэтай катастрофе, я змяніў назву гэтай кампаніі на Bell Computers. На наступным слайдзе паказана, як выглядала IT інфраструктура такіх кампаній у сярэдзіне 90-х. Гэта тыповая архітэктура вялікага ўніверсальнага адмоваўстойлівага сервера HP Tandem Mainframe для функцыянавання крамы кампутарнай тэхнікі.
Ім трэба было пабудаваць сістэму кіравання ўсімі замовамі, продажамі, зваротам, каталогамі прадуктаў, кліенцкай базай, так што яны абралі самае распаўсюджанае на той час рашэнне мэйнфрэйма. Гэтая гіганцкая сістэма ўтрымоўвала ў сабе кожныя макулінкі інфармацыі аб кампаніі, усё, што толькі можна, і любая транзакцыя праводзілася праз гэты мэйнфрэйм. Яны трымалі ўсе свае яйкі ў адным кошыку і лічылі, што гэта нармальна. Адзінае, што сюды не ўвайшло - гэта каталогі паштовых заказаў і афармленне заказаў па тэлефоне.
З часам сістэма станавілася ўсё больш і больш, у ёй назапашвалася велізарная колькасць смецця. Акрамя таго, COBOL не самая выразная мова ў свеце, так што ў канчатковым выніку сістэма ператварылася ў вялікі маналітны ком смецця. Да 2000 году яны ўбачылі, што мноства кампаній маюць сайты, з дапамогай якіх вядуць абсалютна ўвесь бізнэс, і вырашылі пабудаваць свой першы камерцыйны датком-сайт.
Першапачатковы дызайн выглядаў даволі сімпатычна і складаўся з сайта верхняга ўзроўню bell.com і шэрагу паддаменаў для асобных прыкладанняў: каталога catalog.bell.com, акаўнтаў account.bell.com, заказаў orders.bell.com, пошуку тавараў search.bell.com. Кожны паддамен выкарыстоўваў фрэймворк ASP.Net 1.0 і ўласныя базы дадзеных, і ўсе яны размаўлялі з бэкэндам сістэмы. Аднак усе замовы працягвалі апрацоўвацца і выконвацца ўсярэдзіне адзінага велізарнага мэйнфрэйма, у якім заставалася ўсё смецце, затое фронтэнд уяўляў сабой асобныя вэб-сайты з індывідуальнымі прыкладаннямі і асобнымі базамі дадзеных.
Дык вось, дызайн сістэмы выглядаў спарадкаваным і лагічным, але рэальная сістэма была такой, як паказана на наступным слайдзе.
Усе элементы адрасавалі выклікі адзін аднаму, звярталіся да API, убудоўвалі іншыя бібліятэкі dll і таму падобнае. Часта здаралася, што сістэмы кіравання версіямі хапалі чужы код, запіхвалі яго ўнутр праекту, і затым усё ламалася. MS SQL Server 2005 выкарыстаў канцэпцыю лінк-сервераў, і хоць я не паказаў стрэлкамі на слайдзе, кожная з баз дадзеных таксама мела зносіны сябар з сябрам, таму што як бы няма нічога дрэннага ў тым, каб будаваць табліцы на падставе дадзеных, атрыманых з некалькіх БД .
Паколькі зараз у іх былі некаторыя падзелы паміж рознымі лагічнымі абласцямі сістэмы, гэта ператварылася ў размеркаваныя камякі бруду, а самы вялікі кавалак смецця па-ранейшаму заставаўся ў бэкендзе мэйнфрэйма.
Самае смешнае было тое, што гэты мэйнфрэйм быў пабудаваны канкурэнтамі Bell Сomputers і да гэтага часу абслугоўваўся іх тэхнічнымі кансультантамі. Пераканаўшыся ў нездавальняючай працы сваіх прыкладанняў, кампанія вырашыла ад іх пазбавіцца і зрабіць рэдызайн сістэмы.
Існуючае прыкладанне было ў прадакшэне на працягу 15 гадоў, што з'яўляецца рэкордным для прыкладанняў на базе ASP.Net. Сэрвіс прымаў заказы з усяго свету, і штогадовы прыбытак ад гэтага адзінага дадатку дасягаў мільярда долараў. Значную частку прыбытку фармаваў менавіта вэб-сайт bell.com. Па «чорных пятніцах» колькасць заказаў, зробленых праз сайт, дасягала некалькі мільёнаў. Аднак існуючая архітэктура не дазваляла ніякага развіцця, паколькі цвёрдыя ўзаемасувязі элементаў сістэмы практычна не дазвалялі ўносіць у сэрвіс ніякіх змен.
Самай сур'ёзнай праблемай стала немагчымасць зрабіць замову з адной краіны, аплаціць яго ў іншай і адправіць у трэцюю пры тым, што падобная схема гандлю вельмі распаўсюджаная ў глабальных кампаніях. Існуючы вэб-сайт не дазваляў нічога падобнага, таму яны вымушаны былі прымаць і афармляць такія заказы па тэлефоне. Гэта прыводзіла да таго, што кампанія ўсё больш задумвалася аб змене архітэктуры, у прыватнасці аб пераходзе на мікрасэрвісы.
Яны паступілі разумна, вывучыўшы досвед іншых кампаній, каб паглядзець, як тыя вырашылі аналагічную праблему. Адным з такіх рашэнняў была архітэктура сэрвісу Netflix, якая прадстаўляе сабой мікрасэрвісы, злучаныя праз API, і знешнюю базу дадзеных.
Кіраўніцтва Bell Сomputers прыняло рашэнне пабудаваць менавіта такую архітэктуру, прытрымліваючыся нейкіх асноўных прынцыпаў. Па-першае, яны адмовіліся ад дублявання звестак, выкарыстоўваючы падыход агульнага доступу да БД. Ніякія дадзеныя не перасылаліся, наадварот, усе, хто ў іх меў патрэбу, павінны былі звяртацца да цэнтралізаванай крыніцы. Далей ішлі ізаляванасць і аўтаномнасць - кожны сэрвіс быў незалежны ад іншых. Яны вырашылі выкарыстоўваць Web API абсалютна для ўсяго - калі вы жадалі атрымаць дадзеныя ці занесці змены ў іншую сістэму, усё гэта рабілася праз Web API. Апошняй важнай рэччу быў новы галоўны мэйнфрэйм пад назвай "Bell on Bell" у адрозненне ад мэйнфрэйма "Bell", заснаванага на "жалезе" канкурэнтаў.
Такім чынам, на працягу 18 месяцаў яны стваралі сістэму, кіруючыся гэтымі асноўнымі прынцыпамі, і давялі яе да стадыі предпродакшена. Вярнуўшыся на працу пасля выходных, распрацоўнікі сабраліся разам і ўлучылі ўсе серверы, да якіх была падлучаная новая сістэма. 18 месяцаў працы, сотні распрацоўшчыкаў, самае сучаснае апаратнае забеспячэнне Bell - і ніякага станоўчага выніку! Гэта расчаравала мноства людзей, таму што яны неаднаразова запускалі гэтую сістэму на сваіх наўтбуках, і ўсё было нармальна.
Яны зрабілі разумна, кінуўшы ўсе грошы на вырашэнне гэтай праблемы. Яны ўсталявалі самыя сучасныя серверныя стойкі са світкамі, выкарыстоўвалі гігабітнае оптавалакно, самае магутнае сервернае "жалеза" з вар'ятам аб'ёмам RAM, злучылі ўсё гэта, наладзілі - і зноў нічога! Тады яны пачалі падазраваць, што прычына можа быць у таймаўтах, таму зайшлі ва ўсе вэб-наладкі, усе налады API і абнавілі ўсю канфігурацыю таймаўтаў да максімальных значэнняў, так што заставалася толькі сядзець і чакаць, калі з сайтам нешта адбудзецца. Яны чакалі, чакалі і чакалі на працягу дзевяці з паловай хвілін, пакуль сайт загрузіўся.
Пасля гэтага да іх дайшло, што наяўная сітуацыя мае патрэбу ў дбайным разборы, і яны запрасілі нас. Першае, што мы высветлілі - на працягу ўсіх 18 месяцаў распрацоўкі так і не было створана ні аднаго рэальнага "мікра" - усё станавілася толькі яшчэ больш. Пасля гэтага мы прыступілі да напісання post-mortem, вядомага таксама як "regretrospective", або "сумная рэтраспектыва", яна ж "blame storm" - "абвінаваўчы штурм" па аналогіі з мазгавым штурмам "brain storm", каб разабрацца ў прычыне катастрофы.
У нас было некалькі доказаў, адной з якіх з'яўлялася поўнае насычэнне трафікам у момант выкліку API. Калі вы выкарыстоўваеце маналітную архітэктуру сэрвісу, то адразу можаце зразумець, што менавіта пайшло не так, таму што ў вас маецца трасіроўка да адзінага стэка, якая паведамляе аб усім, што магло выклікаць збой. У выпадку, калі куча сэрвісаў адначасова звяртаюцца да аднаго API, няма ніякай магчымасці адсачыць трасіроўку, акрамя як выкарыстоўваць дадатковыя прылады сеткавага маніторынгу тыпу WireShark, дзякуючы якім можна разгледзець асобны запыт і высветліць, што адбылося пры ім рэалізацыі. Таму мы ўзялі адну вэб-старонку і на працягу амаль 2-х тыдняў складалі кавалачкі мазаікі, здзяйсняючы да яе самыя розныя выклікі і аналізуючы, да чаго прыводзіць кожны з іх.
Паглядзіце на гэтую карцінку. Яна паказвае, што адзін вонкавы запыт падахвочвае сэрвіс здзяйсняць мноства ўнутраных выклікаў, якія вяртаюцца зваротна. Атрымліваецца, што кожны ўнутраны выклік здзяйсняе дадатковыя хопы, каб быць здольным самастойна абслужыць гэты запыт, бо не можа больш нікуды звярнуцца па атрыманне патрэбнай інфармацыі. Гэтая карцінка выглядае бессэнсоўным каскадам выклікаў, паколькі вонкавы запыт выклікае дадатковыя сэрвісы, якія выклікаюць іншыя дадатковыя сэрвісы, і так практычна да бясконцасці.
Зялёным колерам на гэтай схеме паказаны паўкола, у якім сэрвісы выклікаюць адзін аднаго - сэрвіс А выклікае сэрвіс У, сэрвіс У выклікае сэрвіс С, а той зноў выклікае сэрвіс А. У выніку мы атрымліваем «размеркаваны тупік». Адзіны запыт ствараў тысячу сеткавых выклікаў API, і паколькі сістэма не валодала ўбудаванай адмоваўстойлівасцю і абаронай ад зацыклення, то запыт сканчаўся няўдачай, калі хаця б адзін з гэтых API-выклікаў даваў збой.
Мы зрабілі некаторыя матэматычныя вылічэнні. Кожны API-выклік меў SLA не больш за 150 мс і 99,9% аптайм. Адзін запыт выклікаў 200 розных выклікаў, і ў найлепшым выпадку старонка магла быць паказана праз 200 х 150 мс = 30 секунд. Натуральна, гэта нікуды не варта. Перамножыўшы 99,9% аптайм на 200, мы атрымлівалі 0% даступнасць. Атрымліваецца, што гэтая архітэктура была асуджаная на правал з самага пачатку.
Мы звярнуліся да распрацоўшчыкаў з пытаннем, як жа яны не здолелі разглядзець гэтую праблему на працягу 18 месяцаў працы? Аказалася, што яны падчытвалі SLA толькі для запушчанага імі кода, але калі іх сэрвіс выклікаў іншы сэрвіс, яны не лічылі гэты час у сваіх SLA. Усё, што запускалася ў межах аднаго працэсу, прытрымлівалася значэння 150 мс, але зварот да іншых сэрвісных працэсаў шматкроць павялічвала сумарную затрымку. Першы выняты з гэтага ўрок фармуляваўся так: «Ці распараджаецеся вы сваім SLA ці ж SLA распараджаецца вамі»? У нашым выпадку выходзіла другое.
Наступнае, што мы выявілі - яны ведалі пра існаванне канцэпцыі памылак аб размеркаваных вылічэннях, сфармуляванай Пітэрам Дейча і Джэймсам Гослінг, але праігнаравалі яе першую частку. У ёй гаворыцца, што сцвярджэнні "сетка надзейная", "латэнтнасць нулявая" і "прапускная здольнасць бясконцая" з'яўляюцца памылкамі. Памылкамі таксама з'яўляюцца сцвярджэнні "сетка бяспечная", "тапалогія ніколі не змяняецца", "адміністратар заўсёды толькі адзін", "кошт перадачы дадзеных нулявая" і "сетка аднастайная".
Яны дапусцілі памылку, таму што абкочвалі свой сэрвіс на лакальных машынах і ніколі не "падчаплялі" знешнія сэрвісы. Пры лакальнай распрацоўцы і выкарыстанні лакальнага кэша яны ніколі не сутыкаліся з сеткавымі хопамі. За ўсе 18 месяцаў распрацоўкі яны ні разу не задаліся пытаннем, што можа здарыцца, калі закрануць вонкавыя сэрвісы.
Калі паглядзець на межы сэрвісаў на папярэднім малюнку, відаць, што ўсе яны няправільныя. Існуе маса крыніц, якія раяць, як вызначаць межы сэрвісаў, і большасць робяць гэта няправільна, як напрыклад, Microsoft на наступным слайдзе.
Гэтая карцінка з блога MS на тэму «Як будаваць мікрасэрвісы». Тут паказана простае вэб-дадатак, блок бізнес-логікі і база даных. Запыт паступае напрамую, верагодна, тут ёсць адзін сервер для вэб, адзін сервер для бізнесу і адзін для БД. Калі павялічыць трафік, малюнак крыху памяняецца.
Тут з'яўляецца балансавальнік нагрузкі для размеркавання трафіку паміж двума вэб-серверамі, кэш, размешчаны паміж вэб-сэрвісам і бізнес-логікай і яшчэ адзін кэш паміж бізнес-логікай і базай дадзеных. Менавіта такую архітэктуру выкарыстоўвала кампанія Bell для свайго прыкладання - балансаванне нагрузкі і blue/green разгортванне, выкананае ў сярэдзіне 2000-х. Да некаторага часу ўсё працавала добра, паколькі дадзеная схема прызначалася для маналітнай структуры.
На наступным малюнку паказана, як MS рэкамендуе ажыццяўляць пераход ад маналіта да мікрасэрвісаў - проста падзяліць кожны з асноўных сэрвісаў на асобныя мікрасэрвісы. Менавіта пры ўкараненні гэтай схемы Bell і здзейснілі памылку.
Яны разбілі ўсе свае сэрвісы на розныя ўзроўні, кожны з якіх складаўся са мноства індывідуальных сэрвісаў. Напрыклад, вэб-сэрвіс уключаў у сябе мікрасэрвісы для рэндэрынгу кантэнту і аўтэнтыфікацыі, сэрвіс бізнес-логікі складаўся з мікрасэрвісаў для апрацоўкі заказаў і інфармацыі аб акаўнтах, база дадзеных была падзелена на кучу мікрасэрвісаў са спецыялізаванымі дадзенымі. І вэб, і бізнэс-логіка, і БД уяўлялі сабой stateless-сэрвісы.
Аднак гэтая карцінка была абсалютна няправільнай, таму што не карціравала ніякія бізнес-адзінкі па-за IT-кластара кампаніі. Дадзеная схема не ўлічвала ніякай сувязі з навакольным светам, так што было незразумела, як, напрыклад, атрымліваць іншую бізнэс-аналітыку. Заўважу, што ў іх да таго ж было некалькі сэрвісаў, прыдуманых проста для развіцця кар'еры асобных супрацоўнікаў, якія імкнуліся кіраваць як мага большай колькасцю людзей, каб атрымліваць за гэта больш грошай.
Яны лічылі, што для пераходу на мікрасэрвісы дастаткова проста ўзяць іх унутраную інфраструктуру фізічнага ўзроўню N-tier і ўставіць у яе Docker. Давайце зірнем, як жа выглядае традыцыйная архітэктура N-tier.
Яна складаецца з 4 узроўняў: узровень карыстацкага інтэрфейсу UI, узровень бізнэс-логікі, узровень доступу да дадзеных і база дадзеных. Больш прагрэсіўная DDD (Domain-Driven Design), ці праграмна-арыентаваная архітэктура, дзе два сярэдніх узроўня ўяўляюць сабой даменныя аб'екты і рэпазітар.
Я паспрабаваў разгледзець у гэтай архітэктуры розныя вобласці змен, розныя вобласці адказнасці. У звычайным N-tier дадатку класіфікуюцца розныя вобласці змен, якія праймаюць структуру вертыкальна зверху ўніз. Гэта Catalog, налады Config, якія выконваюцца на індывідуальных кампутарах і праверкі Checkout, якімі займалася мая каманда.
Асаблівасць дадзенай схемы заключаецца ў тым, што межы гэтых абласцей змяненняў закранаюць не толькі ўзровень бізнес-логікі, але і распаўсюджваюцца на базу даных.
Давайце разгледзім, што азначае "быць сэрвісам". Існуе 6 характэрных уласцівасцяў вызначэння сэрвісу - гэта праграмнае забеспячэнне, якое:
- ствараецца і выкарыстоўваецца канкрэтнай арганізацыяй;
- адказвае за змест, апрацоўку і/або прадастаўленне пэўнага віду інфармацыі ў рамках сістэмы;
- можа быць створана, разгорнута і запушчана незалежна для задавальнення пэўных аперацыйных задач;
- мае зносіны са спажыўцамі і іншымі сэрвісамі, падаючы інфармацыю на аснове пагадненняў або дагаворных гарантый;
- абараняе само сябе ад несанкцыянаванага доступу, а сваю інфармацыю - ад страты;
- аперуе збоямі такім чынам, каб яны не прывялі да пашкоджання інфармацыі.
Усе гэтыя ўласцівасці можна выказаць адным словам "аўтаномнасць". Сэрвісы працуюць незалежна сябар ад сябра, задавальняюць вызначаным абмежаванням, вызначаюць кантракты, на аснове якіх людзі могуць атрымліваць патрэбную ім інфармацыю. Я не згадаў спецыфічныя тэхналогіі, выкарыстанне якіх маецца на ўвазе само сабой.
Цяпер разгледзім вызначэнне мікрасэрвісаў:
- мікрасэрвіс мае малы памер і прызначаны для рашэння адной канкрэтнай задачы;
- мікрасэрвіс аўтаномны;
- пры стварэнні архітэктуры мікрасэрвісу выкарыстоўваецца метафара "гарадской планіроўкі" town planning metaphor. Гэта вызначэнне з кнігі Сэма Ньюмана "Стварэнне мікрасэрвісаў".
Вызначэнне Bounded Context узята з кнігі Эрыка Эванса "Domain-Driven Design". Гэта асноўны патэрн у DDD, цэнтр праектавання архітэктуры, які працуе з аб'ёмнымі архітэктурнымі мадэлямі, падзяляючы іх на розныя Bounded Context і відавочна вызначаючы ўзаемадзеянне паміж імі.
Прасцей кажучы, абмежаваны кантэкст Bounded Context пазначае вобласць, у якой можа прымяняцца пэўны модуль. Унутры гэтага кантэксту размешчана лагічна ўніфікаваная мадэль, якую можна ўбачыць, напрыклад, у вашым бізнес-дамене. Калі вы спытаеце "хто такі кліент" у персанала, які займаецца заказамі, то атрымаеце адно вызначэнне, калі спытаеце ў тых, хто займаецца продажамі - атрымаеце іншае, а выканаўцы выдадуць вам трэцяе вызначэнне.
Дык вось, Bounded Context кажа, што калі мы не можам даць адназначнага вызначэння таму, што ўяўляе сабой спажывец нашых паслуг, давайце вызначым межы, у межах якіх можна разважаць аб значэнні гэтага тэрміна, а затым вызначым кропкі пераходу паміж гэтымі рознымі азначэннямі. Гэта значыць, калі мы гаворым пра кліента з пункту гледжання афармлення заказаў, гэта азначае тое і тое, а калі з пункту гледжання продажаў - тое і тое.
Наступным вызначэннем мікрасэрвісу з'яўляецца інкапсуляцыя любога віду ўнутраных аперацый, якая прадухіляе «уцечку» складнікаў працоўнага працэсу ў навакольнае асяроддзе. Далей варта "вызначэнне відавочных кантрактаў для вонкавых узаемадзеянняў, або вонкавых сувязяў", якое прадстаўлена ідэяй кантрактаў, якія вяртаюцца ад SLA. Апошнім вызначэннем з'яўляецца метафара клеткі, або вочкі, якая азначае поўную інкапсуляцыю набору аперацый усярэдзіне мікрасэрвісу і наяўнасць у ім рэцэптараў для зносін з навакольным светам.
Такім чынам, мы сказалі рабятам з Bell Computers: "Мы не зможам выправіць нічога ў створаным вамі хаосе, таму што ў вас проста не хопіць для гэтага грошай, але мы выправім усяго адзін сэрвіс, каб надаць усяму гэтаму сэнс". З гэтага месца я пачну аповяд аб тым, як мы выправілі адзіны сэрвіс, каб ён стаў адказваць на запыты хутчэй, чым праз 9 з паловай хвілін.
22:30 мін
Працяг будзе зусім хутка…
Трохі рэкламы
Дзякуй, што застаяцеся з намі. Вам падабаюцца нашыя артыкулы? Жадаеце бачыць больш цікавых матэрыялаў? Падтрымайце нас, аформіўшы замову ці парэкамендаваўшы знаёмым, , унікальны аналаг entry-level сервераў, які быў прыдуманы намі для Вас: (даступныя варыянты з RAID1 і RAID10, да 24 ядраў і да 40GB DDR4).
Dell R730xd у 2 разы танней у дата-цэнтры Equinix Tier IV у Амстэрдаме? Толькі ў нас у Нідэрландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – ад $99! Чытайце аб тым
Крыніца: habr.com