Прывітанне, Хабр. Сёння я працягваю серыю публікацый, якую напісаў спецыяльна да старту новага патоку курса .
Увядзенне
Выбар архітэктурнага стылю з'яўляецца адным з асноўных тэхнічных рашэнняў пры пабудове інфармацыйнай сістэмы. У гэтай серыі артыкулаў я прапаную разабраць самыя папулярныя архітэктурныя стылі пабудовы прыкладанняў і адказаць на пытанне калі які архітэктурны стыль з'яўляецца найболей пераважным. У працэсе выкладу я пастараюся правесці лагічны ланцужок, які тлумачыць развіццё архітэктурных стыляў ад маналітаў да мікрасэрвісаў.
В мы разабраліся з маналітам і прыйшлі да таго, што маналіт мае шэраг праблем: памер, злучанасць, разгортванне, маштабаванасць, надзейнасць і коснасць.
У гэты раз я прапаную пагаварыць аб магчымасцях арганізацыі сістэмы ў выглядзе набору модуляў/бібліятэк (кампанентна-арыентаваная архітэктура) або сэрвісаў (сэрвіс-арыентаваная архітэктура).
Кампанентна-арыентаваная архітэктура
Кампанентна-арыентаваная архітэктура мяркуе выкананне сістэмы ў выглядзе набору кампанентаў, якія можна выкарыстоўваць як у бягучым, так і ў будучых праектах. Пры разбіцці сістэмы на кампаненты ўлічваюцца: прыдатнасць іх для паўторнага выкарыстання, іх замяшчальнасць, незалежнасць ад кантэксту, пашыральнасць, інкапсуляцыю і незалежнасць.
Пры пісьменным выкарыстанні кампанентаў вырашаецца праблема "вялікага кома бруду" (вялікі памер + высокая злучанасць), а самі кампаненты могуць уяўляць з сябе як адзінкі зборкі (модулі, бібліятэкі), так і адзінкі разгортвання (сэрвісы). Адзінкі разгортвання не заўсёды адлюстроўваюцца на выкананы працэс: напрыклад, вэб-прыкладанне і база дадзеных разгортваюцца сумесна.
Найбольш часта маналіты распрацоўваюцца ў выглядзе набору модуляў. Такі падыход прыводзіць да забеспячэння незалежнасці распрацоўкі, але пры гэтым праблемы незалежных маштабавання і разгортвання, адмоваўстойлівасці і незалежнасці ад агульнага тэхналагічнага стэка застаюцца. Менавіта таму модуль - часткова незалежная кампанента.
Самая галоўная праблема такога маналіта складаецца ў тым, што падзел на модулі з'яўляецца чыста лагічным і можа быць лёгка парушана распрацоўшчыкамі. Можа з'явіцца модуль core, які паступова ператвараецца ў памыйніцу, можа расці граф залежнасцяў паміж модулямі і гэтак далей. Для пазбягання такіх праблем распрацоўка павінна весці або вельмі спелай камандай, або пад кіраўніцтвам "архітэктара", які на full time займаецца code review і б'е парушаючых лагічную структуру распрацоўшчыкаў па руках.
"Ідэальны" маналіт уяўляе з сябе набор лагічна падзеленых модуляў, кожны з якіх глядзіць у сваю базу дадзеных.
Сэрвіс-арыентаваная архітэктура
Калі ўсёткі мяркуецца арганізацыя сістэмы ў выглядзе набору сэрвісаў, то гаворка ідзе аб сэрвіс-арыентаванай архітэктуры. Яе прынцыпы: спалучальнасць прыкладанняў, арыентаваных на карыстальнікаў, шматразовае выкарыстанне бізнес-сэрвісаў, незалежнасць ад набору тэхналогій і аўтаномнасць (незалежныя эвалюцыя, маштабаванасць і разгортвальнасць).
Сэрвіс-арыентаваная архітэктура (SOA = service oriented architecture) вырашае ўсе пазначаныя праблемы маналіта: пры змене закранаецца толькі адна служба, а выразна вызначаны API падтрымлівае добрую інкапсуляцыю кампанент.
Але не ўсё так гладка: SOA прыводзіць да ўзнікнення новых праблем. Выдаленыя выклікі даражэй лакальных, а пераразмеркаванне абавязкаў паміж кампанентамі стала істотна даражэй.
Дарэчы кажучы, магчымасць незалежнага разгортвання - гэта вельмі важная асаблівасць сэрвісу. Калі сэрвісы павінны разгортвацца сумесна ці, тым больш, у вызначанай паслядоўнасці, то сістэма не можа лічыцца сэрвіс-арыентаванай. У такім выпадку кажуць аб размеркаваным маналіце (лічыцца антипатерном не толькі з пункта гледжання SOA, але і мікрасэрвіснай архітэктуры).
Сэрвіс-арыентаваная архітэктура нядрэнна падтрымліваецца архітэктурным кам'юніці і вендарамі. Адгэтуль варта наяўнасць мноства курсаў і сертыфікацый, добра прапрацаваных патэрнаў. Да апошніх адносіцца, напрыклад, не вядомая сэрвісная шына прадпрыемства (ESB = enterprise service bus). Пры гэтым ESB - гэта багаж ад вендараў, яна не абавязкова павінна выкарыстоўвацца ў SOA.
Пік папулярнасці сэрвіс-арыентаванай архітэктуры прыпадаў прыкладна на 2008 год, пасля чаго яна пайшла на спад, які стаў істотна больш рэзкім пасля з'яўлення мікрасэрвісаў (~2015).
Заключэнне
Пасля таго, як мы абмеркавалі магчымасці арганізацыі інфармацыйных сістэм у выглядзе сэрвісаў і модуляў, я прапаную нарэшце перайсці да прынцыпаў мікрасэрвіснай архітэктуры і надаць адмысловую ўвагу адрозненню мікрасэрвіснай архітэктуры ад сэрвіс-арыентаванай у наступнай частцы.
Крыніца: habr.com