Прывітанне, хабр. Прама цяпер у OTUS адкрыты набор на новы паток курса . Напярэдадні старту курса хачу падзяліцца з вамі сваім аўтарскім артыкулам.
Увядзенне
Выбар архітэктурнага стылю з'яўляецца адным з асноўных тэхнічных рашэнняў пры пабудове інфармацыйнай сістэмы. У гэтай серыі артыкулаў я прапаную разабраць самыя папулярныя архітэктурныя стылі пабудовы прыкладанняў і адказаць на пытанне калі які архітэктурны стыль з'яўляецца найболей пераважным. У працэсе выкладу я пастараюся правесці лагічны ланцужок, які тлумачыць развіццё архітэктурных стыляў ад маналітаў да мікрасэрвісаў.
Трохі гісторыі
Калі вы паспрабуеце задаць пытанне распрацоўнікам: "Навошта патрэбныя мікрасэрвісы?", то вы атрымаеце самыя розныя адказы. Вы пачуеце, што мікрасэрвісы паляпшаюць маштабаванне, спрашчаюць разуменне кода, паляпшаюць адмоваўстойлівасць, часам можна пачуць, што яны дазваляюць «ачысціць код». Давайце звернемся да гісторыі, каб зразумець, якую мэту прыследавала з'яўленне мікрасэрвісаў.
Калі казаць сцісла, то мікрасэрвісы ў нашым бягучым разуменні ўзніклі наступным чынам: у 2011 Джэймс Льюіс, аналізуючы працы розных кампаній, звярнуў увагу на з'яўленне новага патэрна "micro-app", які аптымізаваў SOA з пункту гледжання паскарэння разгортвання сэрвісаў. Крыху пазней, у 2012 годзе, на архітэктурным саміце патэрн быў перайменаваны ў мікрасэрвіс. Такім чынам, першапачатковай мэтай укаранення мікрасэрвісаў было паляпшэнне праславутага час на рынак.
На «хвалі хайпа» мікрасэрвісы былі ў 2015 годзе. Па некаторых даследаваннях, ні адна канферэнцыя не абыходзілася без даклада на тэму мікрасэрвісаў. Больш за тое, некаторыя канферэнцыі былі прысвечаны выключна мікрасэрвісам. Цяпер жа шматлікія праекты пачынаюцца з ужываннем дадзенага архітэктурнага стылю, а калі праект утрымоўвае тоны legacy-кода, то напэўна актыўна ажыццяўляецца міграцыя на мікрасэрвісы.
Нягледзячы на ўсё вышэйсказанае, да гэтага дастаткова невялікая колькасць распрацоўшчыкаў можа вызначыць паняцце «мікрасэрвіс». Але пра гэта мы пагаворым крыху пазней…
Маналіт
Архітэктурным стылем, які супрацьпастаўляецца мікрасэрвіснаму, з'яўляецца маналіт (або «ўсё ў адным»). Што такое маналіт расказваць, напэўна, не мае сэнсу, таму я адразу пералічу недахопы гэтага архітэктурнага стылю, якія ініцыявалі далейшае развіццё архітэктурных стыляў: памер, звязанасць, разгортванне, маштабаванасць, надзейнасць і коснасць. Ніжэй я прапаную азноміцца з кожным з недахопаў асобна.
Памер
Маналіт вельмі вялікі. І мае зносіны ён як правіла з вельмі вялікай базай даных. Прыкладанне становіцца занадта вялікім, каб яго мог зразумець адзін распрацоўшчык у прынцыпе. З маналітам добра працаваць могуць толькі тыя, хто правёў за гэтым кодам дастаткова шмат часу, тады як навічкі выдаткуюць вельмі шмат часу на спробы разабрацца з маналітам і не факт, што разбяруцца. Звычайна пры працы з маналітам заўсёды ёсць некаторы «умоўны» senior, які ведае маналіт больш-менш добра і б'е па руках на працягу года-паўтара іншых новых распрацоўшчыкаў. Натуральна, што такі ўмоўны senior з'яўляецца адзіным пунктам адмовы, і яго сыход можа прывесці да гібелі маналіта.
Звязанасць
Маналіт уяўляе з сябе «вялікі камяк бруду» (big ball of mud), змены ў якім могуць прывесці да непрадказальных наступстваў. Уносячы змены ў адным месцы, можна пашкодзіць маналіт у іншым (тое самае «вуха пачухаў, *@ адвалілася»). Звязана гэта з тым, што кампаненты ў маналіце маюць вельмі складаныя і, галоўнае, невідавочныя ўзаемасувязі.
разгортванне
Разгортванне маналіта з прычыны складаных узаемасувязяў паміж яго кампанентамі - гэта доўгі працэс са сваім рытуалам. Такі рытуал звычайна не канчаткова стандартызаваны і перадаецца "з вуснаў у вусны".
маштабаванасць
Модулі маналіта могуць мець канфліктуючыя запатрабаванні ў рэсурсах, з-за чаго неабходна шукаць кампраміс з пункту гледжання жалеза. Уявіце сабе, што ў вас маналіт складаецца з сэрвісаў A і B. Сэрвіс A патрабавальны да памеру цвёрдай кружэлкі, а сэрвіс B – да аператыўнай памяці. У такім выпадку, альбо машына, на якую ставіцца маналіт, павінна падтрымліваць патрабаванні абодвух сэрвісаў, альбо давядзецца рукамі, штучна адзін з сэрвісаў адключаць.
Яшчэ адзін прыклад (больш класічны): сэрвіс A нашмат больш папулярны, чым сэрвіс B, таму вы жадаеце, каб сэрвісаў A было 100, а сэрвісаў B было 10. Ізноў-ткі два варыянты: альбо разгортваем 100 паўнавартасных маналітаў, альбо на якіх- то з іх рукамі сэрвісы B давядзецца адключаць.
Надзейнасць
Паколькі ўсе сэрвісы знаходзяцца разам, калі маналіт падае, то падаюць усе сэрвісы адразу. Насамрэч, магчыма гэта не так ужо і дрэнна, прынамсі частковых адмоваў у размеркаванай сістэме не будзе, але з іншага боку, з-за памылкі ў функцыянальнасці, якую выкарыстоўвае 0.001% карыстачоў, вы можаце страціць усіх карыстачоў вашай сістэмы.
Коснасць
З прычыны памеру маналіта цяжка перайсці на новыя тэхналогіі. Як следства, асобнай задачай вымалёўвае ўтрыманне таго самага ўмоўнага senior'а. Абраны на старце праекта тэхналагічны стэк можа стаць блокам, якія перашкаджаюць развіццю прадукта.
Заключэнне
У наступны раз мы пагаворым аб тым, як людзі паспрабавалі вырашыць пазначаныя праблемы, перайшоўшы да кампанентаў і SOA.
Чытаць яшчэ:
Крыніца: habr.com