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

Здраво, Хабр. Денес продолжувам со серијата публикации што ги напишав специјално за почеток на нов тек на курсот. „Архитект на софтвер“.

Вовед

Изборот на архитектонски стил е една од основните технички одлуки при изградба на информациски систем. Во оваа серија написи, предлагам да ги анализирам најпопуларните архитектонски стилови за градење апликации и да одговорам на прашањето кога кој архитектонски стил е најпосакуван. Во процесот на презентација, ќе се обидам да нацртам логичен синџир кој го објаснува развојот на архитектонските стилови од монолити до микросервиси.

В последен пат се занимававме со монолитот и дојдовме до заклучок дека монолитот има голем број проблеми: големина, поврзаност, распоредување, приспособливост, сигурност и цврстина.

Овој пат предлагам да зборуваме за можностите за организирање на системот како збир од модули/библиотеки (компонентно-ориентирана архитектура) или услуги (архитектура ориентирана кон услуги).

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

Архитектурата ориентирана кон компоненти вклучува извршување на систем како збир на компоненти кои можат да се користат и во тековните и во идните проекти. При разградување на системот на компоненти, се земаат предвид следново: нивна повторна употреба, нивна заменливост, независност од контекст, екстензибилност, енкапсулација и независност.

Со правилна употреба на компонентите, проблемот со „големата топка од нечистотија“ (голема големина + висока спојка) е решен, а самите компоненти можат да бидат и монтажни единици (модули, библиотеки) и единици за распоредување (услуги). Единиците за распоредување не се секогаш мапирани на процесот што работи: на пример, веб-апликацијата и базата на податоци се распоредени заедно.

Најчесто, монолитите се развиваат како збир на модули. Овој пристап води кон независен развој, но проблемите со независното скалирање и распоредување, толеранцијата на грешки и независноста од севкупниот технолошки оџак остануваат. Затоа модулот е делумно независна компонента.

Најголемиот проблем со таков монолит е што поделбата на модули е чисто логична и може лесно да биде прекршена од програмерите. Може да се појави основен модул, кој постепено се претвора во депонија, графикот на зависности помеѓу модулите може да расте итн. За да се избегнат ваквите проблеми, развојот треба да го изврши или многу зрел тим, или под водство на „архитект“ кој е ангажиран во ревизија на кодот со полно работно време и ги тепа рацете на програмерите кои ја нарушуваат логичката структура.

„Идеалниот“ монолит е збир на логички одвоени модули, од кои секоја гледа во сопствената база на податоци.

Архитектура ориентирана кон услуги

Ако системот треба да биде организиран во форма на збир на услуги, тогаш зборуваме за сервисно ориентирана архитектура. Нејзините принципи се интероперабилност на апликациите насочени кон корисникот, повторна употреба на деловни услуги, независност на технолошкиот куп и автономија (независна еволуција, приспособливост и распоредување).

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

Но, не е сè толку мазно: SOA создава нови проблеми. Далечинските повици се поскапи од локалните, а прераспределбата на одговорностите помеѓу компонентите стана значително поскапа.

Патем, можноста за независно распоредување е многу важна карактеристика на услугата. Ако услугите мора да бидат распоредени заедно или, згора на тоа, во одредена секвенца, тогаш системот не може да се смета за сервисно ориентиран. Во овој случај, тие зборуваат за дистрибуиран монолит (се смета за анти-шаблон не само од гледна точка на SOA, туку и од гледна точка на микросервис архитектура).

Архитектурата ориентирана кон услуги е добро поддржана од архитектонската заедница и продавачите. Ова подразбира присуство на многу курсеви и сертификати, добро развиени обрасци. Последната ја вклучува, на пример, добро познатата автобуска услуга за претпријатија (ESB = автобуска услуга за претпријатие). Во исто време, ESB е багаж од продавачите, тој не мора нужно да се користи во SOA.

Популарноста на сервисно ориентирана архитектура го достигна врвот околу 2008 година, по што почна да опаѓа, што стана значително подраматично по појавата на микросервисите (~2015).

Заклучок

Откако ги разгледавме можностите за организирање на информациските системи во форма на услуги и модули, предлагам конечно да преминеме на принципите на микросервисната архитектура и да посветиме посебно внимание на разликата помеѓу микросервисната архитектура и архитектурата ориентирана кон услугите во следниот дел.

Извор: www.habr.com