Прелазак са монолита на микросервисе: историја и пракса

У овом чланку ћу говорити о томе како се пројекат на којем радим трансформисао из великог монолита у скуп микросервиса.

Пројекат је започео своју историју прилично давно, почетком 2000. Прве верзије су написане у Висуал Басиц-у 6. Временом је постало јасно да ће развој на овом језику бити тешко подржати у будућности, пошто ИДЕ и сам језик су слабо развијени. Крајем 2000-их одлучено је да се пређе на Ц# који обећава. Нова верзија је писана паралелно са ревизијом старе, постепено се све више и више кода писало у .НЕТ-у. Бацкенд у Ц# је у почетку био фокусиран на архитектуру сервиса, али током развоја коришћене су заједничке библиотеке са логиком, а услуге су покренуте у једном процесу. Резултат је била апликација коју смо назвали „монолит услуге“.

Једна од ретких предности ове комбинације била је могућност услуга да се међусобно позивају преко спољног АПИ-ја. Постојали су јасни предуслови за прелазак на коректнију услугу, а у будућности и микросервисну архитектуру.

Почели смо са радом на декомпозицији око 2015. године. Још нисмо достигли идеално стање – још увек постоје делови великог пројекта који се тешко могу назвати монолитима, али ни они не личе на микросервисе. Ипак, напредак је значајан.
О томе ћу говорити у чланку.

Садржина

• Архитектура и проблеми постојећег решења
• Очекивања од микросервиса
• Проблеми транзиције
• Како прећи са монолита на микросервис
  • Први пут
  • Други пут
  • Трећи пут
  • Четврти пут
• Рад са базом података
  • Подела постојећих табела
  • Одељење за обраду
• Рад са изворним кодом
• Инфраструктурни проблеми
  • Ручна инсталација у окружењима
  • Одвојено евидентирање
  • Тестирање и отклањање грешака повезаних услуга

Архитектура и проблеми постојећег решења

У почетку је архитектура изгледала овако: кориснички интерфејс је посебна апликација, монолитни део је написан у Висуал Басиц-у 6, .НЕТ апликација је скуп повезаних услуга које раде са прилично великом базом података.

Недостаци претходног решења

Једна тачка неуспеха
Имали смо једну тачку неуспеха: .НЕТ апликација је радила у једном процесу. Ако било који модул није успео, цела апликација није успела и морала је да се поново покрене. Будући да аутоматизујемо велики број процеса за различите кориснике, због квара на једном од њих, неко време нису могли да раде сви. А у случају софтверске грешке, чак ни резервна копија није помогла.

Ред побољшања
Овај недостатак је прилично организациони. Наша апликација има много купаца и сви желе да је побољшају што је пре могуће. Раније је то било немогуће радити паралелно, а сви купци су стајали у реду. Овај процес је био негативан за предузећа јер су морали да докажу да је њихов задатак вредан. А развојни тим је провео време организујући овај ред. Ово је захтевало много времена и труда, а производ се на крају није могао променити тако брзо колико би желели.

Неоптимално коришћење ресурса
Када смо хостовали услуге у једном процесу, увек смо у потпуности копирали конфигурацију са сервера на сервер. Желели смо да поставимо најоптерећеније услуге одвојено како не бисмо трошили ресурсе и добили флексибилнију контролу над нашом шемом примене.

Тешко је имплементирати модерне технологије
Проблем познат свим програмерима: постоји жеља да се у пројекат уведу модерне технологије, али нема могућности. Са великим монолитним решењем, свако ажурирање тренутне библиотеке, а да не помињемо прелазак на нову, претвара се у прилично нетривијалан задатак. Потребно је доста времена да се вођи тима докаже да ће ово донети више бонуса него потрошене живце.

Потешкоће са издавањем промена
Ово је био најозбиљнији проблем - издавали смо свака два месеца.
Свако издање претворило се у праву катастрофу за банку, упркос тестирању и напорима програмера. Посао је схватио да почетком недеље неке његове функционалности неће радити. А програмери су схватили да их чека недеља озбиљних инцидената.
Сви су имали жељу да промене ситуацију.

Очекивања од микросервиса

Издавање компоненти када су спремни. Испорука компоненти када су готове разлагањем раствора и одвајањем различитих процеса.

Мали тимови производа. Ово је важно јер је великим тимом који је радио на старом монолиту било тешко управљати. Такав тим је био приморан да ради по строгом поступку, али је желео више креативности и независности. Само мали тимови су то могли да приуште.

Изолација услуга у одвојеним процесима. У идеалном случају, желео сам да га изолујем у контејнерима, али велики број услуга написаних у .НЕТ Фрамеворк-у ради само на Виндовс-у. Сада се појављују сервиси засновани на .НЕТ Цоре-у, али их је још мало.

Флексибилност примене. Желели бисмо да комбинујемо услуге онако како нам је потребно, а не онако како то налаже код.

Коришћење нових технологија. Ово је занимљиво сваком програмеру.

Проблеми транзиције

Наравно, да је лако разбити монолит на микросервисе, не би било потребе да се о томе прича на конференцијама и пише чланци. У овом процесу има много замки, описаћу главне које су нас ометале.

Први проблем типично за већину монолита: кохерентност пословне логике. Када пишемо монолит, желимо да поново користимо наше класе како не бисмо писали непотребан код. А када се пређе на микроуслуге, ово постаје проблем: сав код је прилично чврсто повезан и тешко је раздвојити услуге.

У тренутку почетка рада, репозиторијум је имао више од 500 пројеката и више од 700 хиљада линија кода. Ово је прилично велика одлука и други проблем. Није било могуће једноставно узети и поделити на микросервисе.

Трећи проблем — недостатак потребне инфраструктуре. У ствари, ручно смо копирали изворни код на сервере.

Како прећи са монолита на микросервис

Обезбеђивање микросервиса

Прво, одмах смо за себе утврдили да је одвајање микросервиса итеративни процес. Од нас се увек захтевало да паралелно развијамо пословне проблеме. Како ћемо то технички имплементирати већ је наш проблем. Стога смо се припремили за итеративни процес. Неће функционисати на други начин ако имате велику апликацију и у почетку није спремна за поновно писање.

Које методе користимо за изолацију микросервиса?

Први пут — преместите постојеће модуле као услуге. У том погледу, имали смо среће: већ су постојали регистровани сервиси који су радили користећи ВЦФ протокол. Били су раздвојени у посебне скупштине. Портирали смо их одвојено, додајући мали покретач свакој верзији. Написан је помоћу дивне библиотеке Топсхелф, која вам омогућава да покренете апликацију и као услугу и као конзолу. Ово је згодно за отклањање грешака јер у решењу нису потребни додатни пројекти.

Сервиси су повезани по пословној логици, јер су користили заједничке склопове и радили са заједничком базом података. Тешко би се могли назвати микросервисима у свом чистом облику. Међутим, могли бисмо да пружамо ове услуге одвојено, у различитим процесима. Само ово је омогућило смањење њиховог утицаја једни на друге, смањење проблема са паралелним развојем и једном тачком неуспеха.

Склапање са хостом је само једна линија кода у класи Програм. Сакрили смо рад са Топсхелфом у помоћном часу.

namespace RBA.Services.Accounts.Host
{
   internal class Program
   {
      private static void Main(string[] args)
      {
        HostRunner<Accounts>.Run("RBA.Services.Accounts.Host");

       }
    }
}

Други начин за доделу микроуслуга је: створити их за решавање нових проблема. Ако у исто време монолит не расте, ово је већ одлично, што значи да се крећемо у правом смеру. Да бисмо решили нове проблеме, покушали смо да направимо засебне услуге. Ако је постојала таква прилика, онда смо креирали више „канонских“ сервиса који у потпуности управљају сопственим моделом података, засебном базом података.

Ми смо, као и многи, почели са услугама аутентификације и ауторизације. Они су савршени за ово. Они су независни, по правилу имају посебан модел података. Они сами не ступају у интеракцију са монолитом, само се он њима окреће да реше неке проблеме. Користећи ове услуге, можете започети прелазак на нову архитектуру, отклонити грешке у инфраструктури на њима, испробати неке приступе у вези са мрежним библиотекама итд. У нашој организацији немамо тимове који не би могли да креирају услугу аутентификације.

Трећи начин доделе микросервисаОвај који користимо је мало специфичан за нас. Ово је уклањање пословне логике са слоја корисничког интерфејса. Наша главна УИ апликација је десктоп, она је, као и бацкенд, написана у Ц#. Програмери су повремено правили грешке и преносили делове логике у кориснички интерфејс који је требало да постоји у позадини и поново се користи.

Ако погледате прави пример из кода УИ дела, можете видети да већина овог решења садржи стварну пословну логику која је корисна у другим процесима, а не само за изградњу УИ форме.

Права логика корисничког интерфејса постоји само у последњих неколико редова. Пренели смо га на сервер да би се могао поново користити, чиме смо смањили кориснички интерфејс и постигли исправну архитектуру.

Четврти и најважнији начин за изоловање микросервиса, што омогућава смањење монолита, јесте уклањање постојећих услуга са обрадом. Када извадимо постојеће модуле какве јесу, резултат није увек по вољи програмера, а пословни процес је можда застарео од када је функционалност креирана. Са рефакторингом можемо подржати нови пословни процес јер се пословни захтеви стално мењају. Можемо побољшати изворни код, уклонити познате недостатке и креирати бољи модел података. Постоје многе бенефиције.

Одвајање услуга од обраде нераскидиво је повезано са концептом ограниченог контекста. Ово је концепт из домена вођеног дизајна. То значи део модела домена у коме су сви термини једног језика јединствено дефинисани. Погледајмо контекст осигурања и рачуна као пример. Имамо монолитну апликацију и треба да радимо са рачуном у осигурању. Очекујемо да ће програмер пронаћи постојећу класу Аццоунт у другом склопу, референцирати је из класе Осигурање, а ми ћемо имати радни код. Поштоваће се принцип ДРИ, задатак ће се обављати брже коришћењем постојећег кода.

Као резултат тога, испоставља се да су контексти рачуна и осигурања повезани. Како се појављују нови захтеви, ово спајање ће ометати развој, повећавајући сложеност већ сложене пословне логике. Да бисте решили овај проблем, морате пронаћи границе између контекста у коду и уклонити њихова кршења. На пример, у контексту осигурања, сасвим је могуће да ће бити довољни 20-цифрени број рачуна Централне банке и датум отварања рачуна.

Да бисмо одвојили ове ограничене контексте један од другог и започели процес одвајања микросервиса од монолитног решења, користили смо приступ као што је креирање спољних АПИ-ја унутар апликације. Ако смо знали да неки модул треба да постане микросервис, некако модификован у оквиру процеса, онда смо екстерним позивима одмах позвали логику која припада другом ограниченом контексту. На пример, преко РЕСТ-а или ВЦФ-а.

Чврсто смо одлучили да нећемо избегавати код који би захтевао дистрибуиране трансакције. У нашем случају, показало се да је прилично лако пратити ово правило. Још се нисмо сусрели са ситуацијама да су строге дистрибуиране трансакције заиста потребне - коначна конзистентност између модула је сасвим довољна.

Погледајмо конкретан пример. Имамо концепт оркестратора - цевовод који обрађује ентитет „апликације“. Он заузврат креира клијента, рачун и банковну картицу. Ако су клијент и налог успешно креирани, али креирање картице не успе, апликација се не помера у статус „успешно“ и остаје у статусу „картица није креирана“. У будућности ће га позадинска активност покупити и завршити. Систем је већ неко време у неконзистентном стању, али смо генерално тиме задовољни.

Уколико дође до ситуације када је потребно доследно чувати део података, највероватније ћемо ићи на обједињавање сервиса како бисмо га обрадили у једном процесу.

Погледајмо пример доделе микросервиса. Како га релативно безбедно довести у производњу? У овом примеру имамо посебан део система - модул платног списка, чији један од одељака кода желимо да направимо микросервис.

Пре свега, креирамо микросервис поновним писањем кода. Побољшавамо неке аспекте са којима нисмо били задовољни. Имплементирамо нове пословне захтеве купаца. Додамо АПИ мрежни пролаз на везу између корисничког интерфејса и позадине, који ће обезбедити прослеђивање позива.

Затим пуштамо ову конфигурацију у рад, али у пилот стању. Већина наших корисника и даље ради са старим пословним процесима. За нове кориснике, развијамо нову верзију монолитне апликације која више не садржи овај процес. У суштини, имамо комбинацију монолита и микросервиса који раде као пилот.

Уз успешан пилот, разумемо да је нова конфигурација заиста изводљива, можемо уклонити стари монолит из једначине и оставити нову конфигурацију на месту старог решења.

Укупно користимо скоро све постојеће методе за раздвајање изворног кода монолита. Сви они нам омогућавају да смањимо величину делова апликације и преведемо их у нове библиотеке, чинећи бољи изворни код.

Рад са базом података

База података се може поделити горе од изворног кода, јер садржи не само тренутну шему, већ и акумулиране историјске податке.

Наша база података, као и многе друге, имала је још један важан недостатак - огромну величину. Ова база података је дизајнирана у складу са замршеном пословном логиком монолита и односима акумулираним између табела различитих ограничених контекста.

У нашем случају, поред свих невоља (велика база података, много веза, понекад нејасне границе између табела), појавио се проблем који се јавља у многим великим пројектима: употреба шаблона дељене базе података. Подаци су узети из табела кроз приказ, кроз репликацију и послати у друге системе где је ова репликација била потребна. Као резултат тога, нисмо могли да преместимо табеле у посебну шему јер су се активно користиле.

Иста подела на ограничене контексте у коду нам помаже у раздвајању. Обично нам даје прилично добру идеју о томе како разбијамо податке на нивоу базе података. Разумемо које табеле припадају једном ограниченом контексту, а које другом.

Користили смо две глобалне методе партиционисања базе података: партиционисање постојећих табела и партиционисање са обрадом.

Одвајање постојећих табела је добар метод за коришћење ако је структура података добра, испуњава пословне захтеве и сви су задовољни тиме. У овом случају можемо одвојити постојеће табеле у посебну шему.

Одељење са обрадом је потребно када се пословни модел увелико променио, а табеле нас више нимало не задовољавају.

Подела постојећих табела. Морамо да одредимо шта ћемо одвојити. Без овог знања ништа неће функционисати, а овде ће нам помоћи одвајање ограничених контекста у коду. По правилу, ако можете разумети границе контекста у изворном коду, постаје јасно које табеле треба да буду укључене у листу за одељење.

Замислимо да имамо решење у коме два монолитна модула комуницирају са једном базом података. Морамо да се уверимо да само један модул ступа у интеракцију са одељком раздвојених табела, а други почиње да комуницира са њим преко АПИ-ја. За почетак, довољно је да се само снимање врши преко АПИ-ја. То је неопходан услов да говоримо о независности микросервиса. Везе за читање могу остати све док не постоји велики проблем.

Следећи корак је да одељак кода који ради са одвојеним табелама, са или без обраде, можемо одвојити у засебну микросервис и покренути га у засебном процесу, контејнеру. Ово ће бити посебна услуга са везом на монолитну базу података и оне табеле које се не односе директно на њу. Монолит је и даље у интеракцији за читање са одвојивим делом.

Касније ћемо уклонити ову везу, односно читање података из монолитне апликације из одвојених табела такође ће бити пребачено на АПИ.

Затим ћемо из опште базе података изабрати табеле са којима ради само нови микросервис. Можемо да преместимо табеле у посебну шему или чак у засебну физичку базу података. Још увек постоји веза за читање између микросервиса и монолитне базе података, али нема разлога за бригу, у овој конфигурацији може да живи прилично дуго.

Последњи корак је потпуно уклањање свих веза. У овом случају, можда ћемо морати да мигрирамо податке из главне базе података. Понекад желимо да поново користимо неке податке или директоријуме реплициране са спољних система у неколико база података. То нам се периодично дешава.

Одељење за обраду. Овај метод је веома сличан првом, само обрнутим редоследом. Одмах додељујемо нову базу података и нови микросервис који комуницира са монолитом преко АПИ-ја. Али у исто време, остаје скуп табела базе података које желимо да избришемо у будућности. Више нам није потребан, заменили смо га у новом моделу.

Да би ова шема функционисала, вероватно ће нам требати прелазни период.

Тада постоје два могућа приступа.

Прво: дуплирамо све податке у новој и старој бази података. У овом случају имамо редундантност података и могу се појавити проблеми са синхронизацијом. Али можемо узети два различита клијента. Један ће радити са новом верзијом, други са старом.

Други: податке делимо према неким пословним критеријумима. На пример, имали смо 5 производа у систему који су били ускладиштени у старој бази података. Шесту постављамо у оквиру новог пословног задатка у нову базу података. Али биће нам потребан АПИ мрежни пролаз који ће синхронизовати ове податке и показати клијенту одакле и шта да добије.

Оба приступа функционишу, бирајте у зависности од ситуације.

Након што се уверимо да све функционише, део монолита који ради са старим структурама базе података може бити онемогућен.

Последњи корак је уклањање старих структура података.

Да резимирамо, можемо рећи да имамо проблема са базом података: тешко је радити са њом у поређењу са изворним кодом, теже је делити, али то може и треба да се уради. Пронашли смо неке начине који нам омогућавају да то урадимо прилично безбедно, али је ипак лакше погрешити са подацима него са изворним кодом.

Рад са изворним кодом

Овако је изгледао дијаграм изворног кода када смо почели да анализирамо монолитни пројекат.

Може се грубо поделити на три слоја. Ово је слој покренутих модула, додатака, услуга и појединачних активности. У ствари, то су биле улазне тачке унутар монолитног решења. Сви су били чврсто запечаћени заједничким слојем. Имало је пословну логику коју су услуге делиле и много веза. Сваки сервис и додатак користио је до 10 или више уобичајених склопова, у зависности од њихове величине и савести програмера.

Имали смо среће што смо имали инфраструктурне библиотеке које су могле да се користе засебно.

Понекад је настајала ситуација када неки заједнички објекти заправо не припадају овом слоју, већ су инфраструктурне библиотеке. Ово је решено преименовањем.

Највећа брига су били ограничени контексти. Дешавало се да се 3-4 контекста помешају у једном заједничком склопу и да се међусобно користе у оквиру истих пословних функција. Требало је разумети где се ово може поделити и дуж којих граница, и шта даље урадити са мапирањем ове поделе у склопове изворног кода.

Формулисали смо неколико правила за процес раздвајања кода.

Први: Више нисмо желели да делимо пословну логику између услуга, активности и додатака. Желели смо да пословну логику учинимо независном у оквиру микросервиса. Микроуслуге, с друге стране, идеално се сматра услугама које постоје потпуно независно. Сматрам да је овакав приступ донекле расипнички и тешко остварив, јер ће, на пример, сервиси у Ц#-у у сваком случају бити повезани стандардном библиотеком. Наш систем је написан у Ц#; још нисмо користили друге технологије. Стога смо одлучили да можемо себи приуштити коришћење заједничких техничких склопова. Главна ствар је да они не садрже никакве фрагменте пословне логике. Ако имате практичан омот преко ОРМ-а који користите, онда је његово копирање из сервиса у услугу веома скупо.

Наш тим је љубитељ дизајна вођеног доменом, тако да нам је архитектура лука одлично одговарала. Основа наших услуга није слој приступа подацима, већ склоп са логиком домена, који садржи само пословну логику и нема везе са инфраструктуром. У исто време, можемо независно модификовати склоп домена да бисмо решили проблеме везане за оквире.

У овој фази наишли смо на први озбиљан проблем. Сервис је морао да се односи на један склоп домена, желели смо да осамосталимо логику, а ДРИ принцип нас је овде у великој мери омео. Програмери су желели да поново користе класе из суседних склопова како би избегли дуплирање, и као резултат тога, домени су поново почели да се повезују. Анализирали смо резултате и одлучили да можда проблем лежи иу области уређаја за складиштење изворног кода. Имали смо велико спремиште које садржи сав изворни код. Решење за цео пројекат је било веома тешко саставити на локалној машини. Стога су за делове пројекта направљена посебна мала решења и нико није забранио да им се дода неки заједнички или доменски склоп и да се поново користе. Једини алат који нам то није дозволио је преглед кода. Али понекад је и то пропало.

Затим смо почели да прелазимо на модел са одвојеним репозиторијумима. Пословна логика више не тече од услуге до услуге, домени су заиста постали независни. Ограничени контексти су јасније подржани. Како поново користимо инфраструктурне библиотеке? Одвојили смо их у посебно спремиште, а затим их ставили у Нугет пакете, које смо ставили у Артифацтори. Са било којом променом, склапање и објављивање се одвија аутоматски.

Наше услуге су почеле да упућују интерне инфраструктурне пакете на исти начин као и екстерне. Ми преузимамо екстерне библиотеке са Нугет-а. За рад са Артифацтори-ом, где смо поставили ове пакете, користили смо два менаџера пакета. У малим репозиторијумима користили смо и Нугет. У репозиторијумима са више сервиса користили смо Пакет, који обезбеђује више конзистентности верзија између модула.

Тако, радећи на изворном коду, незнатно мењајући архитектуру и одвајајући ризнице, чинимо наше услуге независнијим.

Инфраструктурни проблеми

Већина недостатака преласка на микроуслуге односи се на инфраструктуру. Биће вам потребна аутоматизована примена, биће вам потребне нове библиотеке за покретање инфраструктуре.

Ручна инсталација у окружењима

У почетку смо ручно инсталирали решење за окружења. Да бисмо аутоматизовали овај процес, креирали смо ЦИ/ЦД цевовод. Одабрали смо процес континуиране испоруке јер нам континуирана имплементација још није прихватљива са становишта пословних процеса. Дакле, слање на рад се врши помоћу дугмета, а за тестирање - аутоматски.

Користимо Атлассиан, Битбуцкет за складиштење изворног кода и Бамбоо за изградњу. Волимо да пишемо скрипте за израду у Цаке-у јер је исти као Ц#. Готови пакети долазе у Артифацтори, а Ансибле аутоматски долази до тест сервера, након чега се могу одмах тестирати.

Одвојено евидентирање

Некада је једна од идеја монолита била да обезбеди заједничку сечу. Такође смо морали да разумемо шта да радимо са појединачним евиденцијама које се налазе на дисковима. Наши дневники су уписани у текстуалне датотеке. Одлучили смо да користимо стандардни ЕЛК стек. Нисмо писали ЕЛК-у директно преко провајдера, већ смо одлучили да изменимо текстуалне евиденције и упишемо ИД праћења у њих као идентификатор, додајући име услуге, тако да се ови записи касније могу рашчланити.

Користећи Филебеат, добијамо прилику да прикупимо наше евиденције са сервера, затим их трансформишемо, користимо Кибану за прављење упита у корисничком интерфејсу и видимо како је позив прошао између услуга. Траце ИД у томе много помаже.

Тестирање и отклањање грешака повезаних услуга

У почетку нисмо у потпуности разумели како да отклонимо грешке у услугама које се развијају. Све је било једноставно са монолитом; покренули смо га на локалној машини. У почетку су покушали да ураде исто са микросервисима, али понекад да бисте у потпуности покренули један микросервис морате покренути неколико других, а то је незгодно. Схватили смо да треба да пређемо на модел где на локалној машини остављамо само услугу или сервисе које желимо да отклонимо. Преостале услуге се користе са сервера који одговарају конфигурацији са прод. Након отклањања грешака, током тестирања, за сваки задатак, тест серверу се издају само промењене услуге. Тако се решење тестира у облику у којем ће се у будућности појавити у производњи.

Постоје сервери који покрећу само производне верзије услуга. Ови сервери су потребни у случају инцидената, за проверу испоруке пре распоређивања и за интерну обуку.

Додали смо аутоматизовани процес тестирања користећи популарну библиотеку Спецфлов. Тестови се покрећу аутоматски користећи НУнит одмах након постављања из Ансибле-а. Ако је покривеност задатка потпуно аутоматска, онда нема потребе за ручним тестирањем. Иако је понекад потребно додатно ручно тестирање. Користимо ознаке у Јира да бисмо одредили које тестове да покренемо за одређени проблем.

Поред тога, повећана је потреба за тестирањем оптерећења, које се раније спроводило само у ретким случајевима. Користимо ЈМетер за покретање тестова, ИнфлукДБ за њихово складиштење и Графану за прављење графикона процеса.

Шта смо постигли?

Прво смо се ослободили концепта „ослобађања“. Прошла су двомесечна монструозна издања када је овај колос постављен у производно окружење, привремено ометајући пословне процесе. Сада распоређујемо услуге у просеку сваких 1,5 дан, групишући их јер почињу да раде након одобрења.

У нашем систему нема фаталних кварова. Ако пустимо микросервис са грешком, онда ће функционалност повезана са њом бити покварена, а све остале функционалности неће бити погођене. Ово значајно побољшава корисничко искуство.

Можемо да контролишемо образац распоређивања. По потреби можете одабрати групе услуга одвојено од остатка решења.

Поред тога, значајно смо смањили проблем великим редом побољшања. Сада имамо одвојене тимове за производе који са неким од услуга раде независно. Сцрум процес се већ добро уклапа овде. Одређени тим може имати засебног власника производа који му додељује задатке.

Резиме

• Микросервисе су веома погодне за разлагање сложених система. У том процесу почињемо да схватамо шта је у нашем систему, који ограничени контексти постоје, где леже њихове границе. Ово вам омогућава да правилно дистрибуирате побољшања међу модулима и спречите забуну кода.
• Микроуслуге пружају организационе предности. О њима се често говори само као о архитектури, али за решавање пословних потреба потребна је свака архитектура, а не сама. Дакле, можемо рећи да су микросервис веома погодан за решавање проблема у малим тимовима, с обзиром да је Сцрум сада веома популаран.
• Одвајање је итеративни процес. Не можете узети апликацију и једноставно је поделити на микросервисе. Мало је вероватно да ће добијени производ бити функционалан. Приликом посвећивања микросервиса, корисно је преписати постојећи легат, односно претворити га у код који нам се допада и који по функционалности и брзини боље задовољава пословне потребе.

  Мало упозорење: Трошкови преласка на микроуслуге су прилично значајни. Требало је доста времена да се сам инфраструктурни проблем реши. Дакле, ако имате малу апликацију која не захтева специфично скалирање, осим ако немате велики број купаца који се такмиче за пажњу и време вашег тима, онда микросервис можда није оно што вам треба данас. То је прилично скупо. Ако започнете процес са микросервисима, онда ће трошкови у почетку бити већи него ако започнете исти пројекат са развојем монолита.

  ПС Емотивнија прича (и као за тебе лично) - према веза.
  Ево пуне верзије извештаја.

Извор: ввв.хабр.цом