Се чини дека врвот на возбудата за микросервисите е зад нас. Повеќе не читаме објави неколку пати неделно „Како го преместив мојот монолит на 150 услуги“. Сега слушам повеќе разумни мисли: „Не го мразам монолитот, само се грижам за ефикасноста“. Дури забележавме неколку миграции од микроуслуги назад во монолит. Кога се движите од една голема апликација на повеќе помали услуги, ќе треба да решите неколку нови проблеми. Да ги наведеме што е можно пократко.

Поставување: од основна хемија до квантна механика

Поставувањето основна база на податоци и апликација со процес на позадина беше прилично јасен процес. Го објавувам readme на Github - и често по еден час, најмногу неколку часа, сè функционира и започнувам нов проект. Додавањето и извршувањето на кодот, барем за почетната средина, се врши на првиот ден. Но, ако се впуштиме во микроуслуги, почетното време на лансирање вртоглаво расте. Да, сега го имаме Docker со оркестрација и кластер од K8 машини, но за почетник програмер сето ова е многу покомплицирано. За многу јуниори ова е товар кој е навистина непотребна компликација.

Системот не е лесно да се разбере

Ајде да се фокусираме на нашиот јуниор за момент. Со монолитни апликации, ако се појави грешка, беше лесно да се следи и веднаш да се премине на дебагирање. Сега имаме услуга која разговара со друга услуга која чека нешто во редица во магистралата за пораки што обработува друга услуга - и потоа се појавува грешка. Мораме да ги собереме сите овие делови за на крајот да откриеме дека услугата А работи со верзија 11, а услугата Е веќе ја чека верзијата 12. Ова е многу различно од мојот стандарден консолидиран дневник: морам да користам интерактивен терминал/дебагер за да одиме низ процесот чекор по чекор. Отстранувањето грешки и разбирањето инхерентно станаа потешко.

Ако не може да се дебагира, можеби ќе ги тестираме

Континуираната интеграција и континуираниот развој сега стануваат секојдневие. Повеќето нови апликации што ги гледам автоматски создаваат и извршуваат тестови со секое ново издание и бараат да се направат тестови и да се прегледаат пред регистрацијата. Ова се одлични процеси кои не треба да се напуштат и беа голема промена за многу компании. Но, сега, за навистина да ја тестирам услугата, морам да подигнам целосна работна верзија на мојата апликација. Се сеќавате на тој нов инженер со кластерот K8 од 150 услуги? Па, сега ќе го научиме нашиот CI систем како да ги покрене сите овие системи за да потврди дека сè навистина функционира. Ова е веројатно премногу напор, па затоа само ќе го тестираме секој дел изолирано: убеден сум дека нашите спецификации се доволно добри, API-ите се чисти, а дефектот на услугата е изолиран и нема да влијае на другите.

Сите компромиси имаат добра причина. нели?

Постојат многу причини да се преселите во микросервиси. Го видов ова направено за поголема флексибилност, за зголемување на тимовите, за перформанси, за да се обезбеди подобра одржливост. Но, во реалноста, ние инвестиравме децении во алатки и практики за да развиеме монолити кои продолжуваат да се развиваат. Работам со професионалци во различни технологии. Обично зборуваме за скалирање бидејќи тие се во границите на еден јазол на базата на податоци на Postgres. Повеќето од разговорите се за скалирање на базата на податоци.

Но, секогаш сум заинтересиран да учам за нивната архитектура. Во која фаза од преминот кон микроуслуги се наоѓаат? Интересно е да се видат повеќе инженери кои велат дека се задоволни со нивната монолитна апликација. Многу луѓе ќе имаат корист од микроуслугите, а придобивките ќе ги надминат нерамнините на патот на миграцијата. Но, лично, ве молам дајте ми ја мојата монолитна апликација, место на плажа - и јас сум целосно среќен.

Извор: www.habr.com