Микросървисната архитектура е толкова модерно и всеобхватно архитектурно решение, че всеки специалист по бекенд програмиране се е уморил да повтаря и повтаря приложенията му. И все пак, съвсем не всеки е длъжен да знае за какво става дума… докато не му се наложи.
Именно към вас са насочени следващите редове. Ще се опитаме кратко и достатъчно изчерпателно да разкажем какво представляват микросървисите, как работят. На какво се дължат днешните им силни позиции, как през последните години те успяха да завладеят света. И, разбира се, как изглежда бъдещето в тази посока.
Микро скрито
През последните години сравнително плахо идеята навлиза и във фронтенд технологиите, но поне до момента тя далеч не се прилага толкова широко там. Царството на микросървисите си остава бекендът.
Според данните на мащабното проучване сред програмистите O’Reilly през 2020-а:
- 61% от включените компании са използвали микросървисна архитектура;
- 29% казват, че поне половината им системи се базират на този подход;
- 74% потвърждават, че собствените им екипи отговарят за процесите по билдване, тестване и деплойване на апликациите.
И така, какво са микросървисите? Казано в рамките само на едно изречение: специфичен метод за дизайн на софтуерните системи, при който една апликация е разработена като колекция от свободно свързани (loosely coupled, това наистина звучи странно на български) услуги.
Звучи изключително просто? Да, принципът е точно такъв. Проблемите идват тогава, когато започне да се прилага върху огромните, мащабни, оплетени системи, каквито са днешните уеб приложения. Защото идеята за свободното свързване е прекрасна, тя е в основата на SOLID принципите и винаги е от полза за четимостта на кода и развитието на приложенията. Но в някакъв момент става почти невъзможна за абсолютно прецизна имплементация.
Срещу монолитите
И така, от едната страна стои микросървисната архитектура, а нейното пълно противоречие е доста по-старият и изпитан подход на монолитното приложение. Дори само по имената им можете да добиете достатъчно ясна представа какви са основните им характеристики. И в двата случая, въпреки различните подходи, имаме в основата само едно-единствено приложение, апликация, софтуер, предназначен да изпълнява дадени услуги. Но докато при монолитното решение кодът му е, грубо казано, събран накуп, при микросървисната архитектура той е логически разделен на отделни услуги, които почти не взаимодействат помежду си.
Ако например искате да създадете новия „Фейсбук“ по монолитния принцип, всички услуги, които се връщат при заявките ви към бекенда, ще водят на едно и също място. Докато при другия вариант ще имате отделни микросървиси, всеки от които отговаря за определена част от тях. Например, ще имате отделни микросървиси, които да отговарят за автентикацията на потребителите, за управлението на техните приятели, за управлението на фийда, за управление на отделните групи и т.н., и т.н.
По този начин, ако трябва да бъде добавена нова функционалност – например сторита, просто се създава допълнителен микросървис.
Аргументи и факти
Продължаваме нататък. Този подход трупа допълнителни точки и на базата на хардуерната инфраструктура. За да се изпълни дадена услуга, не е нужно да се използват ресурсите на цялото приложение, а е достатъчно да се генерира само съответният микросървис. Това е важно както при тестването, така и при билдването и деплойването на самия проект (тези думички още си нямат достатъчно разбираем превод на български, но обещаваме да ви ги представим при следваща среща) – при наистина големи апликации по този начин се пестят много сериозни ресурси.
А същото важи и за проблемите. Ако поради някаква причина в даден микросървис се появи бъг (а това винаги се случва, колкото и прецизен да е софтуерният екип), той няма да засегне останалите. Също и ако цял микросървис излезе от строя, поради някаква софтуерна или хардуерна причина, това няма задължително да порази и останалата част от услугата.
Всичко това звучеше прекрасно на теория, но дълго време беше почти неосъществимо на практика, защото управлението и поддържането на отделни микросървиси по същество беше истински кошмар. После се появиха две големи решения, които ще са ви познати, ако редовно следите блога на ZETTAHOST.bg. Първо беше представен Docker, който позволи достатъчно лесно и удобно да пускаме отделните микросървиси в независими контейнери. После дойде и Kubernetes, който да оркестрира с минимални усилия работата на отделните контейнери. И така, изведнъж се озовахме в свят, в който микросървисите имат огромни очевидни предимства, а и станаха удобни за чисто практическа работа. Както разказва известния изследовател и популяризатор на направлението Мартин Фаулър, днес на този принцип работят основните услуги на Netflix, eBay, Amazon, Twitter, PayPal. Има защо да се учим от най-големите, нали?
Микро стъпка за човека
Разбира си, по никакъв начин не бива да гледаме на този тип архитектура като на панацея. Онлайн можете да намерите немалко мнения на водещи специалисти, които са доста скептични към използването на микросървисната архитектура за щяло и нещяло.
Например: характеристиките на някои нови проекти просто не изискват нещо подобно. Ако е ясно, че даден бекенд ще има само строго ограничени, базови заявки, просто няма никакъв смисъл да „раздробявате“ 3 или 5 крайни точки от комуникацията с бекенда на отделни микросървиси, монолитният подход определено е вашето решение в този случай.
Защото, не на последно място, създаването на нов микросървис изисква със сигурност писането на немалко допълнителен код, който нерядко се повтаря. Изисква допълнителни усилия за разработка, които в случай като по-горния могат да бъдат напълно ненужни.
Освен това, микросървисната архитектура често поставя архитектурни въпроси, които иначе не съществуват. Старшите бекенд програмисти във вашия екип могат с часове да спорят дали е логично дадена услуга да бъде групирана в един или в няколко микросървиса, дали е удачно новата крайна точка да бъде в определен микросървис, или в друг.
На вашите услуги
И все пак, както говори и статистиката, днес много по-голяма част от приложенията са избрали именно тази архитектура, защото тя най-често отговаря на техните изисквания. Защото е спасение в света на тежките, комплексни софтуерни решения, в който живеем. Защото чрез тях прилагаме и още един от SOLID принципите – че програмата трябва да е отворена за разширения, но затворена за модификации.
Истината е, че в масовия случай бекенд услугите в дадено приложение постоянно растат. Програмистите трябва да добавят нови и нови услуги, което се случва значително по-лесно, отколкото е възможно при монолитната архитектура. И обратното: ако дадена услуга изведнъж се окаже ненужна, е доста лесно просто да отпадне даден микросървис, а това може да е огромен проблем при другия подход.
Всичко това се вписва съвсем точно и в класическите постулати на програмирането: а именно, че по същество то представя разбиване на даден проблем на подпроблеми и решаването им на малки стъпки с помощта на компютърен код.
Прекрасен принцип, който, всъщност, си струва да прилагаме във все повече страни на живота. Ето, ако например се колебаете за новия си сайт, най-лесно е да разбиете въпроса на подпроблеми. А с решението на първия можем да ви помогнем ние – опитайте тук напълно безплатния ни и безсрочен хостинг.
