Избор на архитектурен стил (част 1)

Здравейте, habr. Записването за нов поток от курсове е отворено в момента в OTUS "Софтуерен архитект". В навечерието на началото на курса искам да споделя с вас моята оригинална статия.

въведение

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

Малко история

Ако се опитате да попитате разработчиците: „Защо имаме нужда от микроуслуги?“, ще получите различни отговори. Ще чуете, че микроуслугите подобряват скалируемостта, правят кода по-лесен за разбиране, подобряват толерантността към грешки и понякога ще чуете, че ви позволяват да „почистите кода си“. Нека погледнем в историята, за да разберем целта зад появата на микроуслугите.

Накратко, микроуслугите в нашето сегашно разбиране възникнаха по следния начин: през 2011 г. Джеймс Луис, анализирайки работата на различни компании, обърна внимание на появата на нов модел на „микроприложение“, който оптимизира SOA по отношение на ускоряването на внедряването на услуги. Малко по-късно, през 2012 г., на среща на върха по архитектура моделът беше преименуван на микроуслуга. По този начин първоначалната цел на въвеждането на микроуслуги беше да се подобрят прословутите време за пазар.

Микроуслугите бяха на хайп вълна през 2015 г. Според някои проучвания нито една конференция не е завършена без доклад по темата за микроуслугите. Освен това някои конференции бяха посветени изключително на микроуслугите. В наши дни много проекти започват да използват този архитектурен стил и ако проектът съдържа тонове наследен код, тогава миграцията към микроуслуги вероятно се извършва активно.

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

Монолит

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

размер

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

Свързаност

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

Разгръщане

Разгръщането на монолит, поради сложните взаимоотношения между неговите компоненти, е дълъг процес със свой собствен ритуал. Такъв ритуал обикновено не е напълно стандартизиран и се предава „устно“.

Мащабируемост

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

Друг пример (по-класически): услуга A е много по-популярна от услуга B, така че искате да има 100 услуги A и 10 услуги B. Отново две възможности: или ние внедряваме 100 пълноценни монолита, или на някои след това услуги B ще трябва да бъдат деактивирани ръчно.

Надеждност

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

Инерция

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

Заключение

Следващият път ще говорим за това как хората са се опитали да решат тези проблеми, като са преминали към компоненти и SOA.

Прочетете още:

• Защо SQL Server не гарантира сортиране на резултатите без ORDER BY
• Архитектура за разработчици и администратори: кой какви умения има нужда?

Източник: www.habr.com