Първо - монолит, или правилният път към микросервизната архитектура

Във всички истории за проекти, базирани на микросервизна архитектура, забелязах общ модел:

Почти всички успешни проекти за микросервизи започнаха с монолит, който стана твърде голям и в крайна сметка се раздели.
В почти всички случаи, когато проектът е разработен от самото начало върху микроуслуги, възникват сериозни проблеми.

Това наблюдение доведе много от моите колеги до следното твърдение: „не трябва да започвате нов проект с микроуслуги, дори ако сте напълно сигурни, че бъдещото приложение ще бъде достатъчно голямо, за да оправдае такъв подход.“

Микроуслугите са полезна архитектура, но дори привържениците казват, че използването им добавя значителни разходи и риск, с други думи, разработването на микроуслуги има смисъл само в по-сложни системи. Тези режийни разходи (основно за поддръжка на група от услуги) ще забавят екипа. Това прави мощен аргумент за стратегия „първо монолит“, при която първо трябва да изградите приложението си като монолит, въпреки че смятате, че може да можете да се възползвате от микроуслугите в бъдеще.

Първата причина да следвате принципа „първо монолит“ е класическият принцип на Ягни („Няма да ви трябва“). Когато започнете да разработвате ново приложение, колко сте уверени, че то ще бъде полезно за потребителите? Може да е трудно да мащабирате зле проектирана, но успешна софтуерна система, но е по-добре, отколкото да имате добре проектирана и непопулярна. Сега осъзнаваме, че най-добрият начин да проверим дали едно приложение ще бъде търсено е да създадем негова опростена версия. Скоростта е на първо мясторазвитие (и следователно скоростта на получаване на обратна връзка от потенциални потребители), а разработването на микроуслуги е бреме, което не трябва да се поема.

Следващият проблем е, че микроуслугите работят добре, ако постигнете ясни, стабилни граници между отделните услуги - за това трябва да получите правилния набор от ограничени контексти. Всеки рефакторинг на функционалност между услуги е по-сложен от подобен рефакторинг в монолит. Но дори опитни архитекти, работещи в познати райони, имат проблеми с определянето на правилните граници от самото начало. Чрез изграждането на монолитно приложение можете да определите правилните граници, преди микроуслугите да се превърнат в гъста мъгла над тях. Това също ще ви даде време да подготвите всичко необходимо за създаване на услуги с по-ясни граници.

Чувал съм за различни начини за прилагане на стратегия „първо монолит“. Логичният път е монолитът да се проектира внимателно, като се обръща внимание на модулността в софтуера, границите на API и как се съхраняват данните. Ако се направи добре, преходът към микроуслуги ще бъде относително лесен. Въпреки това бих бил по-уверен в този подход, ако знаех достатъчно проекти, където работи.

По-общ подход е да се започне с монолит и постепенно да се отделят микроуслугите от него. В този случай значителна част от оригиналния монолит може да остане централна за архитектурата на микросервизите, но по-голямата част от новото развитие ще се извърши в услуги, оставяйки монолита непроменен.

Често срещан е и подходът с пълната подмяна на монолита. Малцина гледат на това като на нещо, с което да се гордеят, но все пак има ползи от проектирането на "изхвърлящ" монолит. Не се страхувайте да развиете монолит, откоито след това ще трябва да бъдат изоставени, особено ако спомагат за пускането на продукта на пазара възможно най-скоро.

Друг път, с който трябваше да се справя, е да започна с няколко по-груби услуги, по-големи от това, което се очаква в края. Използвайте тези големи услуги, за да научите как да работите в мултисервизна среда, като същевременно се наслаждавате на факта, че техният размер намалява количеството рефакторинг между услуги, който трябва да направите. След това, когато границите вече са определени, разбийте услугите на по-малки.

Въпреки че много от моите познати клонят към подхода „първо монолит“, не всички споделят този подход. Контрааргументът е, че започвайки с микроуслугите, вие свиквате с темпото на развитие в такава среда. Необходима е много (дори твърде много) дисциплина за изграждане на монолитно приложение по модулен начин, достатъчно за просто разделяне на микроуслуги. Започвайки с микроуслуги, вие работите в малки екипи, разделени от граници на услугата, което ще ви позволи да ускорите развитието с допълнителни човешки ресурси, ако е необходимо. Този подход работи особено добре в случай на подмяна на системата, където имате по-голям шанс да получите сравнително стабилни граници в началото. Въпреки редките примери, не мисля, че трябва да започвате с микроуслуги, ако нямате достатъчно опит в разработването им.

Микроуслугите тепърва започват, така че нямам достатъчно примери, за да заявя с абсолютна сигурност критериите за използване на стратегия „монолит първо“. Следователно всеки съвет по тази тема трябва да се счита за предварителен, независимо колко добри са аргументите в негова полза.

Предлагам също да прочетете мислите на Сам Нюманвъзможността за използване на микроуслуги в един от проектите.