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

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

Увод

Избор архитектонског стила је једна од фундаменталних техничких одлука приликом изградње информационог система. У овој серији чланака предлажем да анализирам најпопуларније архитектонске стилове за грађевинске апликације и одговорим на питање када је који архитектонски стил најпожељнији. У процесу презентације покушаћу да нацртам логички ланац који објашњава развој архитектонских стилова од монолита до микросервиса.

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

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

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

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

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

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

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

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

Сервисно оријентисана архитектура

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

Сервисно оријентисана архитектура (СОА = сервисно оријентисана архитектура) решава све идентификоване проблеме монолита: само једна услуга је погођена када дође до промене, а добро дефинисан АПИ подржава добру инкапсулацију компоненти.

Али није све тако глатко: СОА ствара нове проблеме. Даљински позиви су скупљи од локалних, а прерасподела одговорности између компоненти је постала знатно скупља.

Иначе, могућност самосталног распоређивања је веома важна карактеристика сервиса. Ако услуге морају бити распоређене заједно или, штавише, у одређеном низу, онда се систем не може сматрати сервисно оријентисаним. У овом случају, они говоре о дистрибуираном монолиту (који се сматра анти шаблоном не само са становишта СОА-е, већ и са становишта микросервисне архитектуре).

Архитектура оријентисана на услуге је добро подржана од стране архитектонске заједнице и добављача. То подразумева присуство многих курсева и сертификата, добро развијених образаца. Ово последње укључује, на пример, добро познату услужну магистралу предузећа (ЕСБ = Ентерприсе сервице бус). У исто време, ЕСБ је пртљаг од добављача; не мора се нужно користити у СОА-и.

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

Закључак

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

Извор: ввв.хабр.цом