Здаецца, пік хайпа па мікрасэрвісах застаўся ззаду. Мы ўжо не чытаем па некалькі разоў на тыдзень пасты "Як я перанёс свой маналіт на 150 сэрвісаў". Цяпер я часцей чую разумныя думкі: "Я не ненавіджу маналіт, я проста клапачуся аб эфектыўнасці". Мы нават назіралі некалькі міграцый ад мікрасэрвісаў назад да маналіту. Пры пераходзе ад аднаго вялікага прыкладання да некалькіх службаў меншага памеру вам давядзецца вырашаць некалькі новых праблем. Пералічоны іх максімальна коратка.

Устаноўка: ад базавай хіміі да квантавай механікі

Настройка базавай БД і прыкладанні з фонавым працэсам была даволі выразным працэсам. Я публікую readme на Github - і часта праз адну гадзіну, максімум, парачку гадзіннікаў, усё працуе, а я пачынаю новы праект. Даданне і запуск кода, прынамсі, для пачатковага асяроддзя, робіцца ў першы ж дзень. Але калі мы адважыліся на мікрасэрвісы, час першапачатковага запуску ўзлятае да нябёсаў. Так, цяпер у нас ёсць Docker з аркестроўкай і кластар машын K8, але для пачаткоўца праграміста ўсё гэта на парадак складаней. Для многіх джуніёраў гэты цяжар, ​​які сапраўды з'яўляецца непатрэбнай складанасцю.

Сістэму няпроста зразумець

На хвілінку спынімся на нашым джуніёры. З маналітнымі прыкладаннямі ў выпадку ўзнікнення памылкі яе лёгка было адсачыць і адразу перайсці да адладкі. Цяпер у нас ёсць служба, якая размаўляе з іншай службай, якая ставіць нешта ў чаргу на шыне паведамленняў, якая апрацоўвае іншую службу – і тут узнікае памылка. Мы павінны сабраць разам усе гэтыя часткі, каб у канчатковым выніку даведацца, што служба А працуе ў версіі 11, а служба Е ўжо чакае версію 12. Гэта моцна адрозніваецца ад майго стандартнага кансалідаванага часопіса: даводзіцца выкарыстоўваць інтэрактыўны тэрмінал/адладчык, каб прайсці праз працэс крок за крокам. Адладка і разуменне па сутнасці сталі больш складанымі.

Калі нельга адладзіць, магчыма, мы іх пратэстуем

Бесперапынная інтэграцыя і бесперапынная распрацоўка ў цяперашні час становяцца агульным месцам. Большасць новых прыкладанняў, якія я бачу, з кожным новым рэлізам аўтаматычна ствараюць і запускаюць тэсты і патрабуюць, каб тэсты праходзілі і праглядаліся перад рэгістрацыяй. Гэта выдатныя працэсы, ад якіх нельга адмаўляцца, яны сталі вялікім зрухам для многіх кампаній. Але зараз, каб сапраўды праверыць сэрвіс, я павінен падняць поўную працоўную версію свайго прыкладання. Памятаеце таго новага інжынера з кластарам K8 са 150 сэрвісаў? Ну, зараз мы навучым нашу сістэму CI, як падняць усе гэтыя сістэмы для праверкі што ўсё сапраўды працуе. Верагодна, гэта занадта шмат намаганняў, таму мы проста ізалявана пратэстуем кожную частку: я ўпэўнены, што нашы спецыфікацыі дастаткова добрыя, API чыстыя, а адмова службы ізаляваны і не паўплывае на іншых.

Ва ўсіх кампрамісаў ёсць важкі чыннік. Так?

Ёсць шмат прычын для пераходу на мікрасэрвісы. Я бачыў, што гэта робяць для большай гнуткасці, для маштабавання каманд, для прадукцыйнасці, каб забяспечыць лепшую ўстойлівасць працы. Але ў рэальнасці мы ўклалі дзесяцігоддзі ў інструментарый і практыкі распрацоўкі маналітаў, якія працягваюць развівацца. Я працую з прафесіяналамі ў розных тэхналогіях. Звычайна мы гаворым аб маштабаванні, таму што яны сутыкаюцца з лімітамі аднаго вузла базы дадзеных Postgres. Большая частка размоў прысвечана маштабаванню БД.

Але мне заўсёды цікава даведацца аб іх архітэктуры. На якім этапе пераходу да мікрасэрвісаў яны знаходзяцца. Цікава назіраць, як усё больш інжынераў кажуць, што яны задаволены сваім маналітным дадаткам. Многім мікрасэрвісы прынясуць карысць, а выгады пераважаць выбоіны на шляху міграцыі. Але асабіста мне дайце, калі ласка, маё маналітнае дадатак, месца на пляжы - і я цалкам шчаслівы.

Крыніца: habr.com