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

Здравейте, Хабр. Днес продължавам серията публикации, които написах специално за старта на новия поток на курса «Software Architect».

Въведение

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

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

Този път предлагам да поговорим за възможностите за организация на системата под формата на набор от модули/библиотеки (компонентно-ориентирана архитектура) или услуги (сервисно-ориентирана архитектура).

Компонентно-ориентирана архитектура

Компонентно-ориентираната архитектура предполага изпълнението на системата като набор от компоненти, които могат да се използват както в текущи, така и в бъдещи проекти. При разделянето на системата на компоненти се вземат предвид: пригодността им за повторна употреба, заменяемост, независимост от контекста, разширяемост, инкапсулиране и независимост.

При правилното използване на компонентите се решава проблемът с 'голямата топка мръсотия' (голям размер + висока свързаност), а самите компоненти могат да представляват както единици за сглобяване (модули, библиотеки), така и единици за разгръщане (услуги). Единиците за разгръщане не винаги се отразяват на изпълнявания процес: например, уебприложение и база данни се разгръщат съвместно.

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

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

"Идеалният" монолит представлява набор от логически разделени модули, всеки от които работи с собствена база данни.

Сервизно-ориентирана архитектура

Ако все пак се предполага организирането на системата под формата на набор от сервизи, става въпрос за сервизно-ориентирана архитектура. Неините принципи са: съвместимост на приложенията, ориентирани към потребителите, многократно използване на бизнес сервизи, независимост от набор технологии и автономност (независима еволюция, мащабируемост и разгръщане).

Сервизно-ориентираната архитектура (SOA = service oriented architecture) решава всички обозначени проблеми на монолита: при промяна се засяга само една услуга, а ясно дефинираното API поддържа добра инкапсуация на компонентите.

Но не всичко е толкова гладко: SOA води до възникването на нови проблеми. Отдалечените извиквания са по-скъпи от локалните, а разпределението на задълженията между компонентите стана значително по-скъпо.

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

Сервизно-ориентираната архитектура получава добра подкрепа от архитектурната общност и доставчиците. Оттук следва наличието на много курсове и сертификации, добре разработени модели. Към последните принадлежи, например, не безизвестната сервизна шина на предприятията (ESB = enterprise service bus). При това ESB е товар от доставчиците, не е задължително да бъде използвана в SOA.

Пик на популярност на услугите, ориентирани архитектури, бе около 2008 година, след което започна спад, който стана значително по-рязък след появата на микросервиси (~2015 година).

Заключение

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

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