Поминавте месеци редизајнирајќи го вашиот монолит во микросервис, и конечно сите се собраа да го превртат прекинувачот. Одиш на првата веб-страница... и ништо не се случува. Го вчитате повторно - и повторно ништо добро, страницата е толку бавна што не реагира неколку минути. Што се случи?
Во својот говор, Џими Богард ќе спроведе „посмртница“ за катастрофа од реални микросервис. Тој ќе ги покаже проблемите со моделирањето, развојот и производството што ги открил и како неговиот тим полека го трансформирал новиот дистрибуиран монолит во конечна слика за разумност. Иако е невозможно целосно да се спречат грешките во дизајнот, можете барем да ги идентификувате проблемите на почетокот на процесот на дизајнирање за да се осигурате дека финалниот производ ќе стане сигурен дистрибуиран систем.
Здраво на сите, јас сум Џими и денес ќе слушнете како можете да избегнете мега катастрофи кога градите микросервис. Ова е приказна за една компанија во која работев околу година и половина за да помогнам да се спречи нивниот брод да се судри со санта мраз. За правилно да ја раскажеме оваа приказна, ќе треба да се вратиме во времето и да разговараме за тоа каде започна оваа компанија и како нејзината ИТ инфраструктура растеше со текот на времето. За да ги заштитам имињата на невините во оваа катастрофа, го сменив името на оваа компанија во Bell Computers. Следниот слајд покажува како изгледала ИТ инфраструктурата на таквите компании во средината на 90-тите. Ова е типична архитектура на голем универзален HP Tandem Mainframe сервер кој е толерантен на грешки за управување со продавница за компјутерски хардвер.
Тие требаше да изградат систем за управување со сите нарачки, продажба, враќање, каталози на производи и база на клиенти, па затоа го избраа најчестото решение за мејнфрејм во тоа време. Овој џиновски систем ги содржеше сите информации за компанијата, сè што е можно, и секоја трансакција беше извршена преку овој мејнфрејм. Ги чувале сите јајца во една корпа и мислеле дека тоа е нормално. Единственото нешто што не е вклучено овде е каталозите за нарачки по пошта и нарачките по телефон.
Со текот на времето, системот стануваше се поголем и поголем, а во него се акумулираше огромно количество ѓубре. Исто така, COBOL не е најизразениот јазик во светот, така што системот на крајот стана големо, монолитно парче ѓубре. До 2000 година, тие увидоа дека многу компании имаат веб-страници преку кои го водеа апсолутно целиот свој бизнис и решија да ја изградат својата прва комерцијална веб-локација dot-com.
Почетниот дизајн изгледаше прилично убаво и се состоеше од страница од највисоко ниво bell.com и голем број поддомени за поединечни апликации: catalog.bell.com, accounts.bell.com, orders.bell.com, пребарување на производи.bell. com. Секој поддомен ја користеше рамката ASP.Net 1.0 и сопствените бази на податоци, и сите тие разговараа со задниот дел на системот. Сепак, сите нарачки продолжија да се обработуваат и да се извршуваат во еден огромен мејнфрејм, во кој остана целото ѓубре, но предниот дел беа посебни веб-локации со индивидуални апликации и посебни бази на податоци.
Така, дизајнот на системот изгледаше уреден и логичен, но вистинскиот систем беше како што е прикажан во следниот слајд.
Сите елементи упатуваа повици еден на друг, пристапуваа до API, вградени dll од трети страни и слично. Често се случувало системите за контрола на верзии да зграпчат туѓ код, да го втурнат во проектот и потоа сè да се скрши. MS SQL Server 2005 го користеше концептот на сервери за врски, и иако не ги покажав стрелките на слајдот, секоја од базите на податоци исто така разговараше една со друга, бидејќи нема ништо лошо во градењето табели врз основа на податоци добиени од неколку бази на податоци.
Бидејќи сега имаа одредено одвојување помеѓу различните логички области на системот, ова стана дистрибуирани дамки од нечистотија, при што најголемото парче ѓубре сè уште останува во задниот дел на главниот компјутер.
Смешното беше што овој мејнфрејм беше изграден од конкурентите на Bell Computers и сè уште го одржуваа нивните технички консултанти. Убедени во незадоволителните перформанси на своите апликации, компанијата одлучи да се ослободи од нив и да го редизајнира системот.
Постоечката апликација беше во производство 15 години, што е рекорд за апликациите базирани на ASP.Net. Сервисот прифаќаше нарачки од целиот свет, а годишниот приход од оваа единствена апликација достигна милијарда долари. Значителен дел од добивката беше генерирана од веб-страницата bell.com. Во Black Friday, бројот на нарачки поставени преку страницата достигна неколку милиони. Сепак, постоечката архитектура не дозволуваше никаков развој, бидејќи крутите меѓусебни врски на системските елементи практично не дозволуваа да се направат никакви промени во услугата.
Најсериозен проблем беше неможноста да се направи нарачка од една земја, да се плати во друга и да се испрати во трета, и покрај фактот што таквата шема за тргување е многу честа појава во светските компании. Постоечката веб-страница не дозволуваше вакво нешто, па мораа да ги прифатат и да ги направат овие нарачки преку телефон. Ова доведе до тоа компанијата сè повеќе да размислува за промена на архитектурата, особено за префрлување на микроуслуги.
Тие ја направија паметната работа гледајќи во други компании за да видат како решиле сличен проблем. Едно од овие решенија беше архитектурата на услугата Netflix, која се состои од микроуслуги поврзани преку API и надворешна база на податоци.
Менаџментот на Bell Computers реши да изгради токму таква архитектура, придржувајќи се до одредени основни принципи. Прво, тие го елиминираа дуплирањето на податоците со користење на пристап за заедничка база на податоци. Не беа испратени податоци, напротив, сите на кои им беа потребни мораа да одат на централизиран извор. Потоа следеше изолација и автономија - секоја служба беше независна од другите. Тие одлучија да го користат Web API за апсолутно сè - ако сакате да добиете податоци или да направите промени во друг систем, сето тоа беше направено преку Web API. Последната голема работа беше новиот мејнфрејм наречен „Bell on Bell“ за разлика од главниот „Bell“ базиран на хардверот на конкурентите.
Така, во текот на 18 месеци, тие го изградија системот околу овие основни принципи и го доведоа до претпродукција. Враќајќи се на работа по викендот, програмерите се собраа и ги вклучија сите сервери на кои беше поврзан новиот систем. 18 месеци работа, стотици програмери, најсовремен хардвер Bell - и без позитивен резултат! Ова разочара многу луѓе бидејќи тие го имаа користено овој систем на нивните лаптопи многу пати и сè беше во ред.
Беа паметни да ги фрлат сите пари за да го решат овој проблем. Тие ги инсталираа најмодерните серверски лавици со прекинувачи, користеа гигабитни оптички влакна, најмоќниот хардвер на серверот со луда количина RAM, го поврзаа сето тоа, го конфигурираа - и повторно, ништо! Потоа почнаа да се сомневаат дека причината можеби е тајмаутот, па влегоа во сите веб-поставки, сите поставки на API и ја ажурираа целата конфигурација на тајмаут до максималните вредности, така што сè што можеа да направат е да седат и да чекаат нешто да се случи. до страницата. Чекаа и чекаа и чекаа 9 и пол минути додека конечно се вчита веб-страницата.
После тоа им текна дека на моменталната ситуација треба темелна анализа и не поканија. Првото нешто што го дознавме беше дека во текот на сите 18 месеци на развој, не беше создаден ниту еден вистински „микро“ - сè стана само поголемо. По ова, почнавме да пишуваме постмортам, исто така познат како „регретроспектива“ или „тажна ретроспектива“, позната и како „бура на вина“, слична на „мозочна бура“, за да ја разбереме причината за катастрофата.
Имавме неколку индиции, од кои едната беше целосна заситеност на сообраќајот во времето на повикот на API. Кога користите монолитна архитектура на услуги, можете веднаш да разберете што точно тргнало наопаку бидејќи имате единствена трага на стек што известува за сè што можело да предизвика неуспех. Во случај кога куп услуги истовремено пристапуваат до истиот API, нема начин да се следи трагата освен да се користат дополнителни алатки за следење на мрежата како WireShark, благодарение на кои можете да испитате едно барање и да дознаете што се случило за време на неговото спроведување. Така, зедовме една веб-страница и поминавме скоро 2 недели за да ги составиме парчињата од сложувалката, да упатуваме различни повици до неа и да анализираме до што води секоја од нив.
Погледнете ја оваа слика. Тоа покажува дека едно надворешно барање ја поттикнува услугата да оствари многу внатрешни повици кои се враќаат назад. Излегува дека секој внатрешен повик прави дополнителни скокови за да може самостојно да го сервисира ова барање, бидејќи не може да се обрати на друго место за да ги добие потребните информации. Оваа слика изгледа како бесмислена каскада од повици, бидејќи надворешното барање повикува дополнителни услуги, кои повикуваат други дополнителни услуги и така натаму, речиси бесконечно.
Зелената боја на овој дијаграм покажува полукруг во кој услугите се јавуваат меѓусебно - услугата А ја повикува услугата Б, услугата Б ја повикува услугата C и повторно ја повикува услугата А. Како резултат на тоа, добиваме „дистрибуиран ќорсокак“. Едно барање создаде илјада мрежни повици на 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 на тема „Како да се изградат микросервиси“. Ова покажува едноставна веб-апликација, блок од деловна логика и база на податоци. Барањето доаѓа директно, веројатно има еден сервер за веб, еден сервер за бизнисот и еден за базата на податоци. Ако го зголемите сообраќајот, сликата малку ќе се промени.
Овде доаѓа load balancer за дистрибуција на сообраќај помеѓу два веб-сервери, кеш лоциран помеѓу веб-услугата и деловната логика и друг кеш помеѓу деловната логика и базата на податоци. Ова е токму архитектурата што Bell ја користеше за балансирање на оптоварување и примена на сино/зелено распоредување во средината на 2000-тите. До одредено време сè функционираше добро, бидејќи оваа шема беше наменета за монолитна структура.
Следната слика покажува како MS препорачува преминување од монолит на микросервис - едноставно поделете ја секоја од главните услуги на посебни микросервиси. За време на спроведувањето на оваа шема, Бел направи грешка.
Тие ги поделија сите свои услуги на различни нивоа, од кои секоја се состоеше од многу индивидуални услуги. На пример, веб-услугата вклучуваше микроуслуги за рендерирање и автентикација на содржини, услугата за деловна логика се состоеше од микроуслуги за обработка на нарачки и информации за сметката, базата на податоци беше поделена на куп микросервиси со специјализирани податоци. И интернетот, деловната логика и базата на податоци беа услуги без државјанство.
Сепак, оваа слика беше целосно погрешна бидејќи не мапираше ниту една деловна единица надвор од ИТ кластерот на компанијата. Оваа шема не земаше предвид никаква поврзаност со надворешниот свет, така што не беше јасно како, на пример, да се добие деловна аналитика од трета страна. Забележувам дека тие исто така имаа неколку услуги измислени едноставно за да ги развијат кариерите на поединечни вработени кои се обидуваа да управуваат со што е можно повеќе луѓе за да добијат повеќе пари за тоа.
Тие веруваа дека преместувањето кон микросервисите е исто толку лесно како преземање на нивната внатрешна инфраструктура N-ниво на физички слој и залепување на Docker на неа. Ајде да погледнеме како изгледа традиционалната архитектура N-tier.
Се состои од 4 нивоа: ниво на кориснички интерфејс на UI, ниво на деловна логика, ниво на пристап до податоци и база на податоци. Попрогресивен е DDD (Domain-Driven Design) или архитектура ориентирана кон софтвер, каде што двете средни нивоа се објекти на доменот и складиште.
Се обидов да разгледам различни области на промени, различни области на одговорност во оваа архитектура. Во типична апликација N-ниво, се класифицираат различни области на промени кои продираат во структурата вертикално од врвот до дното. Станува збор за Каталог, поставки за конфигурација извршени на поединечни компјутери и проверки на Checkout, со кои управуваше мојот тим.
Особеноста на оваа шема е тоа што границите на овие области на промени влијаат не само на нивото на деловната логика, туку и се прошируваат на базата на податоци.
Ајде да погледнеме што значи да се биде услуга. Постојат 6 карактеристични својства на дефиницијата на услугата - тоа е софтвер кој:
- создадена и користена од одредена организација;
- е одговорен за содржината, обработката и/или обезбедувањето на одреден тип на информации во рамките на системот;
- може да се изгради, распореди и работи независно за да се задоволат специфичните оперативни потреби;
- комуницира со потрошувачите и други услуги, обезбедувајќи информации врз основа на договори или договорни гаранции;
- се заштитува од неовластен пристап, а своите информации од загуба;
- се справува со неуспесите на таков начин што тие не доведуваат до оштетување на информациите.
Сите овие својства можат да се изразат со еден збор „автономија“. Услугите работат независно една од друга, задоволуваат одредени ограничувања и дефинираат договори врз основа на кои луѓето можат да ги добијат потребните информации. Не спомнав конкретни технологии, чија употреба е очигледна.
Сега да ја погледнеме дефиницијата за микроуслуги:
- микросервис е мал по големина и дизајниран да реши еден специфичен проблем;
- Микросервисот е автономен;
- При креирање на микросервисна архитектура, се користи метафората за планирање на градот. Ова е дефиницијата од книгата на Сем Њумен, Градење микросервис.
Дефиницијата за ограничен контекст е преземена од книгата на Ерик Еванс Дизајн управуван од домен. Ова е основна шема во DDD, центар за дизајн на архитектура што работи со волуметриски архитектонски модели, делејќи ги на различни Ограничени контексти и експлицитно дефинирајќи ги интеракциите меѓу нив.
Едноставно кажано, Bounded Context го означува опсегот во кој може да се користи одреден модул. Во овој контекст е логички унифициран модел кој може да се види, на пример, во вашиот бизнис домен. Ако прашате „кој е клиент“ на персоналот вклучен во нарачките, ќе добиете една дефиниција, ако ги прашате оние кои се вклучени во продажбата, ќе добиете друга, а изведувачите ќе ви дадат трета дефиниција.
Значи, Bounded Context вели дека ако не можеме да дадеме јасна дефиниција за тоа што е потрошувач на нашите услуги, ајде да ги дефинираме границите во кои можеме да зборуваме за значењето на овој термин, а потоа да ги дефинираме преодните точки помеѓу овие различни дефиниции. Односно, ако зборуваме за клиент од гледна точка на поставување нарачки, тоа значи ова и она, а ако од гледна точка на продажба, ова значи ова и тоа.
Следната дефиниција за микросервис е инкапсулирање на секаков вид внатрешни операции, спречувајќи „истекување“ на компонентите на работниот процес во околината. Следува „дефиниција на експлицитни договори за надворешни интеракции или надворешни комуникации“, што е претставено со идејата за договори кои се враќаат од SLA. Последната дефиниција е метафора на клетка, или ќелија, што значи целосна инкапсулација на збир на операции во рамките на микросервис и присуство во неа на рецептори за комуникација со надворешниот свет.
Затоа, им рековме на момците од Bell Computers: „Не можеме да поправиме никаков хаос што го создадовте затоа што едноставно немате пари да го направите тоа, но ние ќе поправиме само една услуга за да го направиме сето тоа смисла.” Во овој момент, ќе започнам со тоа што ќе ви кажам како ја поправивме нашата единствена услуга, така што таа одговори на барањата побрзо од 9 и пол минути.
22:30 мин
Продолжува наскоро...
Малку рекламирање
Ви благодариме што останавте со нас. Дали ви се допаѓаат нашите написи? Сакате да видите поинтересна содржина? Поддржете не со нарачка или препорака на пријатели, , уникатен аналог на сервери на почетно ниво, кој беше измислен од нас за вас: (достапен со RAID1 и RAID10, до 24 јадра и до 40 GB 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