Прывітанне, Хабр. Сёння я працягваю серыю публікацый, якую напісаў спецыяльна да старту новага патоку курса .
Увядзенне
Выбар архітэктурнага стылю з'яўляецца адным з асноўных тэхнічных рашэнняў пры пабудове інфармацыйнай сістэмы. У гэтай серыі артыкулаў я прапаную разабраць самыя папулярныя архітэктурныя стылі пабудовы прыкладанняў і адказаць на пытанне калі які архітэктурны стыль з'яўляецца найболей пераважным. У працэсе выкладу я пастараюся правесці лагічны ланцужок, які тлумачыць развіццё архітэктурных стыляў ад маналітаў да мікрасэрвісаў.
У мінулы раз мы пагаварылі аб розных відах маналітаў і аб выкарыстанні кампанентаў для іх пабудовы, прычым як кампанентаў зборкі, так і кампанентаў разгортвання. Мы разабраліся з сервіс-арыентаванай архітэктурай.
Цяпер мы нарэшце вызначым асноўныя характарыстыкі мікрасэрвіснай архітэктуры.
Стаўленне архітэктур
Неабходна разумець, што зыходзячы з дадзеных у папярэдніх артыкулах азначэнняў любы сэрвіс з'яўляецца кампанентам, але не любы сэрвіс з'яўляецца мікрасэрвісам.
Характарыстыкі мікрасэрвіснай архітэктуры
Асноўнымі характарыстыкамі мікрасэрвіснай архітэктуры з'яўляюцца:
- Арганізацыя ў адпаведнасці з бізнес-магчымасцямі (Organized around Business Capabilities)
- Прадукты, а не праекты (Products not Projects)
- Разумныя кропкі ўваходу і дурныя каналы (Smart endpoints and dumb pipes)
- Дэцэнтралізаванае кіраванне (Decentralized Governance)
- Дэцэнтралізаванае кіраванне дадзенымі (Decentralized Data Management)
- Аўтаматызацыя інфраструктуры (Infrastructure Automation)
- Страхоўка ад збояў (Design for failure)
- Архітэктура з эвалюцыйным развіццём (Evolutionary Design)
Першы пункт прыходзіць ад сэрвіс-арыентаванай архітэктуры, так як мікрасэрвісы з'яўляюцца прыватным выпадкам паслуг. Іншыя пункты заслугоўваюць асобнага разгляду.
Арганізацыя ў адпаведнасці з бізнес-магчымасцямі (Organized around Business Capabilities)
Цяпер неабходна ўспомніць закон Канвея: арганізацыі, якія ствараюць сістэмы, арганізуюць яе архітэктуру, якая капіюе структуру ўзаемадзеяння ўнутры гэтых арганізацый. У якасці прыкладу можна ўспомніць выпадак стварэння кампілятара: каманда з сямі чалавек распрацавала сяміпрахаднога кампілятар, а каманда з пяці - пяціпраходны.
Калі мы гаворым пра маналіты і мікрасэрвісы, то ў тым выпадку, калі распрацоўка арганізавана па функцыянальных аддзелах (бэкэнд, фронтэнд, адміністратары баз дадзеных), то атрымліваецца класічны маналіт.
Для атрымання мікрасэрвісаў каманды неабходна арганізоўваць па бізнес-магчымасцях (каманда заказаў, адгрузак, каталога). Такая арганізацыя дасць магчымасць камандам засяродзіцца на стварэнні канкрэтных частак дадатку.
Прадукты, а не праекты (Products not Projects)
Праектны падыход пры якім каманда перадае распрацаваную функцыянальнасць іншым камандам у выпадку мікрасэрвіснай архітэктуры зусім не падыходзіць. Каманда мусіць падтрымліваць сістэму на працягу ўсяго яе жыццёвага цыклу. Кампанія Amazon, адзін з флагманаў укаранення мікрасэрвісаў, заяўляла: "вы ствараеце прадукт, і вы ж запускаеце яго" ("you build, you run it"). Прадуктовы падыход дазваляе камандзе адчуць патрэбнасці бізнесу.
Разумныя кропкі ўваходу і дурныя каналы (Smart endpoints and dumb pipes)
SOA архітэктура вялікую ўвагу надавала каналам сувязі, у прыватнасці Enterprise Service Bus (сэрвісная шына прадпрыемства). Што часцяком прыводзіць да Erroneous Spaghetti Box, гэта значыць складанасць маналіта пераходзіць у складанасць сувязяў паміж сэрвісамі. У мікрасявіснай архітэктуры выкарыстоўваюцца толькі простыя спосабы ўзаемадзеяння.
Дэцэнтралізаванае кіраванне (Decentralized Governance)
Ключавыя рашэнні па мікрасэрвісах павінны прымаць людзі, якія сапраўды распрацоўваюць мікрасэрвісы. Тут пад ключавымі рашэннямі маецца на ўвазе выбар
моў праграмавання, метадалогіі разгортвання, кантрактаў публічных інтэрфейсаў і т. д.
Дэцэнтралізаванае кіраванне дадзенымі (Decentralized Data Management)
Стандартны падыход, у якім прыкладанне абапіраецца на адну базу даных, не можа ўлічваць спецыфікі кожнага канкрэтнага сэрвісу. MSA мяркуе дэцэнтралізаванае кіраванне дадзенымі, аж да ўжыванні розных тэхналогій.
Аўтаматызацыя інфраструктуры (Infrastructure Automation)
MSA падтрымлівае працэсы бесперапыннага разгортвання і пастаўкі. Ажыццявіць гэта магчыма толькі шляхам аўтаматызацыі працэсаў. Пры гэтым, разгортванне вялікай колькасці сэрвісаў ужо не выглядае нечым страшным. Працэс разгортвання павінен стаць сумным. Другі аспект звязаны з кіраваннем сэрвісамі ў прадуктовым асяроддзі. Без аўтаматызацыі, кіраванне працэсамі, запушчанымі ў розных аперацыйных асяроддзях, становіцца немагчымым.
Страхоўка ад збояў (Design for failure)
Шматлікія сэрвісы MSA схільныя да збояў. Пры гэтым, апрацоўка памылак у размеркаванай сістэме - вельмі не трывіяльная задача. Архітэктура прыкладанняў павінна быць устойлівая да такіх збояў. Рэбека Парсанс лічыць вельмі важным, што мы больш не выкарыстоўваем нават унутрыпрацэснае ўзаемадзеянне паміж сэрвісамі, замест гэтага для сувязі мы звяртаемся да HTTP, які і блізка не бывае гэтак жа надзейны.
Архітэктура з эвалюцыйным развіццём (Evolutionary Design)
Архітэктура MSA сістэмы павінна развівацца эвалюцыйна. Пажадана абмежаваць неабходныя змены межамі аднаго сэрвісу. Неабходна таксама ўлічваць уплыў на іншыя сэрвісы. Традыцыйны падыход складаецца ў тым, каб паспрабаваць вырашыць гэтую праблему з дапамогай кіравання версіямі, але MSA мяркуе выкарыстоўваць кіраванне версіямі ў
якасці крайняй меры.
Заключэнне
Пасля ўсяго вышэйсказанага можна сфармуляваць што такое мікрасэрвісы. Мікрасэрвісная архітэктура - гэта падыход да распрацоўкі асобнага прыкладання ў выглядзе набору невялікіх сэрвісаў, кожны з якіх працуе ў сваім уласным працэсе і ўзаемадзейнічае з дапамогай палегчаных механізмаў, часта API-інтэрфейсам HTTP-рэсурсаў. Гэтыя сэрвісы пабудаваны на бізнес-магчымасцях і могуць быць разгорнуты незалежна з дапамогай цалкам
аўтаматызаванага механізму разгортвання. Існуе мінімальны ўзровень цэнтралізаванага кіравання гэтымі сэрвісамі, якія могуць быць напісаны на розных мовах праграмавання і выкарыстоўваць розныя тэхналогіі захоўвання даных.
Крыніца: habr.com