Прекарахте месеци в препроектиране на вашия монолит в микроуслуги и накрая всички се събраха, за да натиснат ключа. Отивате на първата уеб страница... и нищо не се случва. Презареждате го - и отново нищо добро, сайтът е толкова бавен, че не отговаря няколко минути. Какво стана?
В своята беседа Джими Богард ще проведе „аутопсия“ на катастрофа в микросервиз в реалния живот. Той ще покаже проблемите с моделирането, разработката и производството, които е открил, и как неговият екип бавно трансформира новия разпределен монолит в окончателната картина на здравия разум. Въпреки че е невъзможно напълно да предотвратите грешки в дизайна, можете поне да идентифицирате проблемите в началото на процеса на проектиране, за да гарантирате, че крайният продукт ще стане надеждна разпределена система.
Здравейте на всички, аз съм Джими и днес ще чуете как можете да избегнете мега бедствия, когато създавате микроуслуги. Това е историята на една компания, за която работих около година и половина, за да помогна за предотвратяване на сблъсъка на кораба им с айсберг. За да разкажем правилно тази история, ще трябва да се върнем назад във времето и да поговорим за това къде е започнала тази компания и как нейната ИТ инфраструктура е нараснала с течение на времето. За да защитя имената на невинните в това бедствие, промених името на тази компания на Bell Computers. Следващият слайд показва как е изглеждала ИТ инфраструктурата на такива компании в средата на 90-те години. Това е типична архитектура на голям универсален и устойчив на грешки HP Tandem мейнфрейм сървър за управление на магазин за компютърен хардуер.
Те трябваше да изградят система за управление на всички поръчки, продажби, връщания, продуктови каталози и клиентска база, така че те избраха най-често срещаното мейнфрейм решение по това време. Тази гигантска система съдържа всяка частица информация за компанията, всичко възможно и всяка транзакция се извършва през този мейнфрейм. Те държаха всичките си яйца в една кошница и смятаха, че това е нормално. Единственото нещо, което не е включено тук, е каталозите за поръчка по пощата и пускането на поръчки по телефона.
С течение на времето системата ставаше все по-голяма и в нея се натрупа огромно количество боклук. Освен това 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. В черните петъци броят на поръчките, направени през сайта, достигна няколко милиона. Съществуващата архитектура обаче не позволяваше никакво развитие, тъй като твърдите взаимовръзки на системните елементи практически не позволяваха да се правят промени в услугата.
Най-сериозният проблем беше невъзможността да направите поръчка от една страна, да я платите в друга и да я изпратите до трета, въпреки факта, че подобна търговска схема е много разпространена в световните компании. Съществуващият уебсайт не позволяваше подобно нещо, така че трябваше да приемат и правят тези поръчки по телефона. Това накара компанията все повече да мисли за промяна на архитектурата, по-специално за преминаване към микроуслуги.
Те направиха умното нещо, като погледнаха други компании, за да видят как са решили подобен проблем. Едно от тези решения беше архитектурата на услугата Netflix, която се състои от микроуслуги, свързани чрез API и външна база данни.
Ръководството на Bell Computers решава да изгради точно такава архитектура, като се придържа към определени основни принципи. Първо, те елиминираха дублирането на данни чрез използване на подход на споделена база данни. Не бяха изпратени данни, напротив, всеки, който имаше нужда от тях, трябваше да отиде до централизиран източник. Последва изолация и автономност – всяка служба беше независима от другите. Те решиха да използват Web API за абсолютно всичко - ако искахте да получите данни или да направите промени в друга система, всичко това се правеше чрез Web API. Последното голямо нещо беше нов мейнфрейм, наречен "Bell on Bell", за разлика от мейнфрейма "Bell", базиран на хардуера на конкурентите.
И така, в продължение на 18 месеца те изградиха системата около тези основни принципи и я доведоха до предпроизводство. Връщайки се на работа след уикенда, разработчиците се събраха и включиха всички сървъри, към които беше свързана новата система. 18 месеца работа, стотици разработчици, най-модерният хардуер на Bell - и никакъв положителен резултат! Това разочарова много хора, защото те са стартирали тази система на своите лаптопи много пъти и всичко е наред.
Те бяха умни да хвърлят всичките си пари за решаването на този проблем. Инсталираха най-модерните сървърни стелажи с комутатори, използваха гигабитови оптични влакна, най-мощния сървърен хардуер с безумно количество RAM, свързаха всичко, конфигурираха го - и пак нищо! Тогава те започнаха да подозират, че причината може да е изчакване, така че влязоха във всички уеб настройки, всички настройки на API и актуализираха цялата конфигурация на изчакване до максималните стойности, така че всичко, което можеха да направят, беше да седят и да чакат нещо да се случи към сайта. Те чакаха и чакаха и чакаха 9 минути и половина, докато уебсайтът най-накрая се зареди.
След това им светна, че сегашната ситуация има нужда от задълбочен анализ и ни поканиха. Първото нещо, което разбрахме, беше, че през всичките 18 месеца на разработка не беше създадено нито едно истинско „микро“ - всичко само стана по-голямо. След това започнахме да пишем аутопсия, известна още като „ретроспектива“ или „тъжна ретроспекция“, известна още като „обвинителна буря“, подобна на „мозъчна буря“, за да разберем причината за бедствието.
Имахме няколко улики, една от които беше пълното насищане на трафика по време на извикването на API. Когато използвате монолитна архитектура на услугата, можете незабавно да разберете какво точно се е объркало, защото имате едно проследяване на стека, което отчита всичко, което може да е причинило грешката. В случай, че куп услуги имат достъп едновременно до един и същи API, няма начин да се проследи следата, освен да се използват допълнителни инструменти за наблюдение на мрежата като WireShark, благодарение на които можете да разгледате една заявка и да разберете какво се е случило по време на изпълнението й. Така че взехме една уеб страница и прекарахме почти 2 седмици, за да сглобим парчетата от пъзела, да направим различни извиквания към нея и да анализираме до какво е довело всяко от тях.
Погледни тази снимка. Това показва, че една външна заявка подканва услугата да направи много вътрешни повиквания, които се връщат обратно. Оказва се, че всяко вътрешно обаждане прави допълнителни скокове, за да може самостоятелно да обслужи тази заявка, тъй като не може да се обърне никъде другаде, за да получи необходимата информация. Тази картина изглежда като безсмислена каскада от повиквания, тъй като външната заявка извиква допълнителни услуги, които извикват други допълнителни услуги и така нататък, почти до безкрайност.
Зеленият цвят в тази диаграма показва полукръг, в който услугите се обаждат една на друга - услуга A извиква услуга B, услуга B извиква услуга C и отново извиква услуга A. В резултат на това получаваме „разпределена безизходица“. Една единствена заявка създаде хиляда мрежови API извиквания и тъй като системата нямаше вградена толерантност към грешки и защита от цикъл, заявката щеше да се провали, ако дори едно от тези API извиквания се провали.
Направихме малко математика. Всяко API извикване имаше SLA от не повече от 150 ms и 99,9% време на работа. Една заявка предизвика 200 различни обаждания и в най-добрия случай страницата можеше да бъде показана за 200 x 150 ms = 30 секунди. Естествено, това не беше добро. Умножавайки 99,9% ъптайм по 200, получаваме 0% наличност. Оказва се, че тази архитектура е била обречена на провал от самото начало.
Попитахме разработчиците как не успяха да разпознаят този проблем след 18 месеца работа? Оказа се, че те отчитат само SLA за кода, който изпълняват, но ако тяхната услуга извика друга услуга, те не отчитат това време в своя SLA. Всичко, което беше стартирано в рамките на един процес, се придържаше към стойността от 150 ms, но достъпът до други обслужващи процеси увеличи общото забавяне многократно. Първият научен урок беше: „Вие ли контролирате вашето SLA или SLA контролира вас?“ В нашия случай беше второто.
Следващото нещо, което открихме, беше, че те знаеха за концепцията за погрешни схващания за разпределени изчисления, формулирана от Питър Дейч и Джеймс Гослинг, но пренебрегнаха първата част от нея. В него се посочва, че твърденията „мрежата е надеждна“, „нулева латентност“ и „безкрайна пропускателна способност“ са погрешни схващания. Други погрешни схващания включват твърденията „мрежата е защитена“, „топологията никога не се променя“, „винаги има само един администратор“, „цената за пренос на данни е нула“ и „мрежата е хомогенна“.
Те направиха грешка, защото тестваха услугата си на локални машини и никога не се свързваха с външни услуги. Когато разработват локално и използват локален кеш, те никога не са срещали мрежови скокове. През всичките 18 месеца на разработка те нито веднъж не са се чудили какво може да се случи, ако външните услуги бъдат засегнати.
Ако погледнете границите на услугата в предишната снимка, можете да видите, че всички те са неправилни. Има много източници, които съветват как да се определят границите на услугата и повечето го правят погрешно, като Microsoft на следващия слайд.
Тази снимка е от блога на MS по темата „Как да изградим микроуслуги“. Това показва просто уеб приложение, блок от бизнес логика и база данни. Заявката идва директно, вероятно има един сървър за уеб, един сървър за бизнеса и един за базата данни. Ако увеличите трафика, картината ще се промени малко.
Тук идва балансьор на натоварването за разпределяне на трафика между два уеб сървъра, кеш, разположен между уеб услугата и бизнес логиката, и друг кеш между бизнес логиката и базата данни. Това е точно архитектурата, която Bell използва за своето приложение за балансиране на натоварването и синьо/зелено внедряване в средата на 2000-те. До известно време всичко работеше добре, тъй като тази схема беше предназначена за монолитна структура.
Следващата снимка показва как MS препоръчва преминаване от монолит към микроуслуги – просто разделяне на всяка от основните услуги на отделни микроуслуги. Именно по време на прилагането на тази схема Бел направи грешка.
Те разделиха всички свои услуги на различни нива, всяко от които се състоеше от много отделни услуги. Например, уеб услугата включваше микроуслуги за рендиране на съдържание и удостоверяване, услугата на бизнес логиката се състоеше от микроуслуги за обработка на поръчки и информация за акаунти, базата данни беше разделена на куп микроуслуги със специализирани данни. И мрежата, и бизнес логиката, и базата данни бяха услуги без състояние.
Тази картина обаче беше напълно погрешна, защото не картографира никакви бизнес единици извън ИТ клъстера на компанията. Тази схема не отчита никаква връзка с външния свят, така че не беше ясно как например да се получи бизнес анализ от трета страна. Отбелязвам, че те също имаха няколко услуги, измислени просто за развитие на кариерата на отделни служители, които се стремяха да управляват възможно най-много хора, за да получат повече пари за това.
Те вярваха, че преминаването към микроуслуги е толкова лесно, колкото да се вземе тяхната вътрешна N-нивова инфраструктура на физическия слой и да се залепи Docker върху нея. Нека да разгледаме как изглежда традиционната N-tier архитектура.
Състои се от 4 нива: ниво на потребителски интерфейс, ниво на бизнес логика, ниво на достъп до данни и база данни. По-прогресивна е DDD (Дизайн, управляван от домейн) или софтуерно-ориентирана архитектура, където двете средни нива са обекти на домейн и хранилище.
Опитах се да разгледам различни области на промяна, различни области на отговорност в тази архитектура. В типично N-ниво приложение се класифицират различни области на промяна, които проникват в структурата вертикално отгоре надолу. Това са каталог, настройките на конфигурацията, извършени на отделни компютри, и проверките на Checkout, които бяха обработени от моя екип.
Особеността на тази схема е, че границите на тези области на промяна засягат не само нивото на бизнес логиката, но също така се простират до базата данни.
Нека да разгледаме какво означава да си услуга. Има 6 характерни свойства на дефиницията на услугата - това е софтуер, който:
- създадени и използвани от конкретна организация;
- отговаря за съдържанието, обработката и/или предоставянето на определен вид информация в рамките на системата;
- може да се изгради, внедри и управлява независимо, за да отговори на специфични оперативни нужди;
- комуникира с потребители и други услуги, като предоставя информация въз основа на споразумения или договорни гаранции;
- предпазва себе си от неоторизиран достъп и информацията си от загуба;
- обработва грешките по такъв начин, че да не водят до увреждане на информацията.
Всички тези свойства могат да бъдат изразени с една дума „автономия“. Услугите работят независимо една от друга, отговарят на определени ограничения и определят договори, въз основа на които хората могат да получат необходимата им информация. Не споменах конкретни технологии, чието използване се разбира от само себе си.
Сега нека да разгледаме дефиницията на микроуслугите:
- микроуслугата е малка по размер и предназначена за решаване на един конкретен проблем;
- Микроуслугата е автономна;
- При създаването на микросервизна архитектура се използва метафората за градоустройство. Това е определението от книгата на Сам Нюман, Изграждане на микроуслуги.
Дефиницията на ограничен контекст е взета от книгата на Eric Evans Domain-Driven Design. Това е основен модел в DDD, център за архитектурен дизайн, който работи с обемни архитектурни модели, като ги разделя на различни ограничени контексти и изрично дефинира взаимодействията между тях.
Просто казано, ограниченият контекст обозначава обхвата, в който може да се използва определен модул. В този контекст е логически обединен модел, който може да се види, например, във вашия бизнес домейн. Ако попитате „кой е клиент” на персонала, който се занимава с поръчки, ще получите едно определение, ако попитате тези, които се занимават с продажби, ще получите друго, а изпълнителите ще ви дадат трето определение.
И така, Ограниченият контекст казва, че ако не можем да дадем ясна дефиниция на това какво е потребител на нашите услуги, нека дефинираме границите, в които можем да говорим за значението на този термин, и след това да дефинираме преходните точки между тези различни дефиниции. Тоест, ако говорим за клиент от гледна точка на подаване на поръчки, това означава това и това, а ако от гледна точка на продажбите, това означава това и това.
Следващата дефиниция на микроуслуга е капсулирането на всякакъв вид вътрешни операции, предотвратявайки „изтичането“ на компонентите на работния процес в околната среда. Следва „дефиницията на изрични договори за външни взаимодействия или външни комуникации“, която е представена от идеята за договори, връщащи се от SLA. Последната дефиниция е метафората на клетка, или клетка, което означава пълното капсулиране на набор от операции в микроуслуга и наличието в нея на рецептори за комуникация с външния свят.
Затова казахме на момчетата от Bell Computers: „Не можем да поправим нищо от хаоса, който сте създали, защото просто нямате пари да го направите, но ние ще поправим само една услуга, за да направим всичко възможно смисъл.” В този момент ще започна, като ви разкажа как поправихме единствената ни услуга, така че да отговаря на заявки по-бързо от 9 минути и половина.
22:30 мин
Продължение съвсем скоро...
Малко реклама
Благодарим ви, че останахте с нас. Харесвате ли нашите статии? Искате ли да видите още интересно съдържание? Подкрепете ни, като направите поръчка или препоръчате на приятели, , уникален аналог на сървъри от начално ниво, който беше изобретен от нас за вас: (предлага се с 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! Прочети за
Източник: www.habr.com