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

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

Проектот ја започна својата историја многу одамна, на почетокот на 2000 година. Првите верзии беа напишани во Visual Basic 6. Со текот на времето, стана јасно дека развојот на овој јазик ќе биде тешко да се поддржи во иднина, бидејќи IDE а самиот јазик се слабо развиени. На крајот на 2000-тите, беше одлучено да се префрли на поперспективниот C#. Новата верзија беше напишана паралелно со ревизијата на старата, постепено се повеќе се пишуваше код во .NET. Backend во C# првично беше фокусиран на архитектура на услуги, но за време на развојот, беа користени заеднички библиотеки со логика, а услугите беа лансирани во еден процес. Резултатот беше апликација што ја нарековме „монолит на услуги“.

Една од ретките предности на оваа комбинација беше способноста на услугите да се јавуваат меѓу себе преку надворешен API. Имаше јасни предуслови за премин кон покоректна услуга, а во иднина и микросервис архитектура.

Работата на распаѓање ја започнавме околу 2015 година. Сè уште не сме достигнале идеална состојба - се уште има делови од голем проект кои тешко можат да се наречат монолити, но не личат ниту на микросервис. Сепак, напредокот е значаен.
Ќе зборувам за тоа во статијата.

содржина

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

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

Првично, архитектурата изгледаше вака: UI е посебна апликација, монолитниот дел е напишан во Visual Basic 6, апликацијата .NET е збир на поврзани услуги кои работат со прилично голема база на податоци.

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

Единствена точка на неуспех
Имавме единствена точка на неуспех: апликацијата .NET работеше во еден процес. Ако некој модул не успеа, целата апликација пропадна и мораше да се рестартира. Бидејќи автоматизираме голем број процеси за различни корисници, поради дефект на еден од нив, секој не можеше да работи некое време. И во случај на софтверска грешка, дури и резервната копија не помогна.

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

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

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

Тешкотии при издавање промени
Ова беше најсериозниот проблем - издававме изданија на секои два месеци.
Секое издание се претвори во вистинска катастрофа за банката, и покрај тестирањето и напорите на програмерите. Бизнисот разбра дека на почетокот на неделата дел од неговата функционалност нема да работи. И програмерите разбраа дека ги чека една недела сериозни инциденти.
Сите имаа желба да ја променат ситуацијата.

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

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

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

Изолација на услугите во посебни процеси. Идеално, би сакал да го изолирам во контејнери, но голем број услуги напишани во .NET Framework работат само под WindowsСега се појавуваат услуги базирани на .NET Core, но сè уште има малку од нив.

Флексибилност на распоредување. Ние би сакале да ги комбинираме услугите онака како што ни се потребни, а не како што го принудува кодот.

Употреба на нови технологии. Ова е интересно за секој програмер.

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

Се разбира, кога би било лесно да се скрши монолит во микросервис, нема да има потреба да се зборува за тоа на конференции и да се пишуваат статии. Има многу стапици во овој процес; јас ќе ги опишам главните што нè попречија.

Првиот проблем типично за повеќето монолити: кохерентност на деловната логика. Кога пишуваме монолит, сакаме повторно да ги користиме нашите класи за да не пишуваме непотребен код. И кога се префрлате на микроуслуги, ова станува проблем: целиот код е прилично цврсто поврзан и тешко е да се одделат услугите.

За време на почетокот на работата, складиштето имаше повеќе од 500 проекти и повеќе од 700 илјади линии код. Ова е прилично голема одлука и втор проблем. Не беше можно едноставно да се земе и да се подели на микросервиси.

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

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

Обезбедување микроуслуги

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

Кои методи ги користиме за да ги изолираме микросервисите?

Првиот начин — преместете ги постоечките модули како услуги. Во овој поглед, имавме среќа: веќе имаше регистрирани услуги кои работеа користејќи го протоколот WCF. Тие беа поделени во посебни собранија. Ги пренесовме одделно, додавајќи мал фрлач на секоја изработка. Напишано е со помош на прекрасната библиотека Topshelf, која ви овозможува да ја стартувате апликацијата и како услуга и како конзола. Ова е погодно за дебагирање бидејќи не се потребни дополнителни проекти во решението.

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

Склопувањето со домаќинот е само една линија код во класата Program. Работата со Topshelf ја криевме во помошна класа.

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

       }
    }
}

Вториот начин за распределба на микроуслугите е: креирајте ги за решавање на нови проблеми. Ако во исто време монолитот не расте, ова е веќе одлично, што значи дека се движиме во вистинската насока. За да решиме нови проблеми, се обидовме да создадеме посебни услуги. Ако постоеше таква можност, тогаш создадовме повеќе „канонски“ услуги кои целосно управуваат со сопствениот модел на податоци, посебна база на податоци.

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

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

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

Вистинската логика на корисничкиот интерфејс е само во последните неколку редови. Го префрливме на серверот за да може повторно да се користи, а со тоа да се намали интерфејсот и да се постигне правилна архитектура.

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

Одвојувањето на услугите од обработката е нераскинливо поврзано со концептот на ограничен контекст. Ова е концепт од Domain Driven Design. Тоа значи дел од моделот на доменот во кој сите термини на еден јазик се уникатно дефинирани. Да го погледнеме контекстот на осигурувањето и сметките како пример. Имаме монолитна апликација и треба да работиме со сметката во осигурувањето. Очекуваме програмерот да најде постоечка класа на сметки во друго склопување, да ја упати од класата Осигурување и ќе имаме работен код. Принципот DRY ќе се почитува, задачата ќе се изврши побрзо со користење на постоечки код.

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

За да ги одвоиме овие ограничени контексти еден од друг и да го започнеме процесот на одвојување на микросервисите од монолитно решение, користевме пристап како што е создавање надворешни API во рамките на апликацијата. Ако знаевме дека некој модул треба да стане микросервис, некако изменет во рамките на процесот, тогаш веднаш преку надворешни повици упативме повици кон логиката што припаѓа на друг ограничен контекст. На пример, преку REST или WCF.

Цврсто одлучивме дека нема да избегнуваме код што ќе бара дистрибуирани трансакции. Во нашиот случај, се покажа дека е прилично лесно да се следи ова правило. Сè уште не наидовме на ситуации каде што навистина се потребни строги дистрибуирани трансакции - конечната конзистентност помеѓу модулите е сосема доволна.

Ајде да погледнеме конкретен пример. Го имаме концептот на оркестратор - цевковод што го обработува ентитетот на „апликацијата“. За возврат создава клиент, сметка и банкарска картичка. Ако клиентот и сметката се успешно креирани, но креирањето на картичката не успее, апликацијата не преминува во статусот „успешна“ и останува во статусот „картичката не е создадена“. Во иднина, активноста во заднина ќе ја земе и ќе ја заврши. Системот веќе некое време е во состојба на недоследност, но генерално сме задоволни од ова.

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

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

Прво, создаваме микросервис со препишување на кодот. Подобруваме некои аспекти со кои не бевме задоволни. Ние имплементираме нови деловни барања од клиентите. Додаваме API Gateway на врската помеѓу интерфејсот и задниот дел, што ќе обезбеди пренасочување на повици.

Следно, ја пуштаме оваа конфигурација во функција, но во пилот-состојба. Повеќето од нашите корисници сè уште работат со стари деловни процеси. За новите корисници, развиваме нова верзија на монолитна апликација која повеќе не го содржи овој процес. Во суштина, имаме комбинација од монолит и микросервис кој работи како пилот.

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

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

Работа со базата на податоци

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

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

Во нашиот случај, на врвот на сите проблеми (голема база на податоци, многу врски, понекогаш нејасни граници меѓу табелите), се појави проблем што се јавува во многу големи проекти: употребата на шаблонот за заедничка база на податоци. Податоците беа земени од табелите преку преглед, преку репликација и испратени до други системи каде што беше потребна оваа репликација. Како резултат на тоа, не можевме да ги преместиме табелите во посебна шема бидејќи тие беа активно користени.

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

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

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

Потребен е оддел со обработка кога бизнис моделот е многу променет, а табелите веќе воопшто не не задоволуваат.

Разделување на постоечките табели. Треба да одредиме што ќе одвоиме. Без ова знаење, ништо нема да работи, и тука ќе ни помогне раздвојувањето на ограничените контексти во кодот. Како по правило, ако можете да ги разберете границите на контекстите во изворниот код, станува јасно кои табели треба да бидат вклучени во списокот за одделот.

Да замислиме дека имаме решение во кое два монолитни модули комуницираат со една база на податоци. Треба да се погрижиме само еден модул да комуницира со делот од одвоените табели, а другиот да започне да комуницира со него преку API. За почеток, доволно е само снимањето да се врши преку API. Ова е неопходен услов за да зборуваме за независноста на микросервисите. Врските за читање може да останат се додека нема голем проблем.

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

Подоцна ќе ја отстраниме оваа врска, односно читањето податоци од монолитна апликација од одделени табели исто така ќе се префрли на API.

Следно, од општата база на податоци ќе ги избереме табелите со кои работи само новиот микросервис. Можеме да ги преместиме табелите во посебна шема или дури и во посебна физичка база на податоци. Сè уште постои врска за читање помеѓу микросервисот и монолитната база на податоци, но нема што да се грижите, во оваа конфигурација може да живее доста долго.

Последниот чекор е целосно да ги отстраните сите врски. Во овој случај, можеби ќе треба да мигрираме податоци од главната база на податоци. Понекогаш сакаме повторно да користиме некои податоци или директориуми реплицирани од надворешни системи во неколку бази на податоци. Ова ни се случува периодично.

Оддел за обработка. Овој метод е многу сличен на првиот, само во обратен редослед. Веднаш доделуваме нова база на податоци и нов микросервис што комуницира со монолитот преку API. Но, во исто време, останува збир на табели со бази на податоци што сакаме да ги избришеме во иднина. Повеќе не ни треба, го заменивме во новиот модел.

За да функционира оваа шема, најверојатно ќе ни треба преоден период.

Потоа, постојат два можни пристапи.

Прво: ги дуплираме сите податоци во новата и старата база на податоци. Во овој случај, имаме вишок на податоци и може да се појават проблеми со синхронизацијата. Но, можеме да земеме два различни клиенти. Едниот ќе работи со новата верзија, другиот со старата.

Вториот: податоците ги делиме според некои деловни критериуми. На пример, имавме 5 производи во системот кои беа зачувани во старата база на податоци. Шестата ја ставаме во рамките на новата деловна задача во нова база на податоци. Но, ќе ни треба API Gateway кој ќе ги синхронизира овие податоци и ќе му покаже на клиентот од каде и од што да добие.

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

Откако ќе се увериме дека сè работи, делот од монолитот што работи со стари структури на бази на податоци може да се оневозможи.

Последниот чекор е да се отстранат старите структури на податоци.

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

Работа со изворниот код

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

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

Имавме среќа што имаме инфраструктурни библиотеки кои може да се користат посебно.

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

Најголемата грижа беа ограничените контексти. Се случи 3-4 контексти да се измешаат во едно Заедничко собрание и да се користат меѓусебно во рамките на истите деловни функции. Беше неопходно да се разбере каде ова може да се подели и по кои граници, и што понатаму да се прави со мапирање на оваа поделба во склопови на изворниот код.

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

Првиот: Повеќе не сакавме да споделуваме деловна логика помеѓу услугите, активностите и додатоците. Сакавме да ја направиме деловната логика независна во рамките на микросервисите. Микроуслугите, од друга страна, идеално се сметаат за услуги кои постојат целосно независно. Верувам дека овој пристап е донекаде расипнички и тешко е да се постигне, бидејќи, на пример, услугите во C# во секој случај ќе бидат поврзани со стандардна библиотека. Нашиот систем е напишан во C#; ние сè уште не сме користеле други технологии. Затоа, решивме дека можеме да си дозволиме да користиме заеднички технички склопови. Главната работа е што тие не содржат никакви фрагменти од деловната логика. Ако имате практична обвивка преку ORM што ја користите, тогаш копирањето од сервис до сервис е многу скапо.

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

Во оваа фаза наидовме на нашиот прв сериозен проблем. Услугата мораше да се однесува на едно склопување на домен, сакавме да ја направиме логиката независна, а принципот DRY многу нè попречи овде. Програмерите сакаа повторно да ги користат класите од соседните склопови за да избегнат дуплирање, и како резултат на тоа, домените повторно почнаа да се поврзуваат заедно. Ги анализиравме резултатите и одлучивме дека можеби проблемот лежи и во областа на уредот за складирање на изворниот код. Имавме големо складиште кое го содржи целиот изворен код. Решението за целиот проект беше многу тешко да се состави на локална машина. Затоа, беа креирани одделни мали решенија за делови од проектот и никој не забрани да им се додаде некаков заеднички или домен склоп на нив и повторно да се употреби. Единствената алатка што не ни дозволи да го направиме ова беше прегледот на кодот. Но, понекогаш и тоа не успеа.

Потоа почнавме да се движиме кон модел со посебни складишта. Деловната логика повеќе не тече од услуга до услуга, домените навистина станаа независни. Ограничените контексти се поддржани појасно. Како повторно ги користиме инфраструктурните библиотеки? Ги одвоивме во посебно складиште, потоа ги ставивме во пакетите Nuget, кои ги ставивме во Artifactory. Со секоја промена, склопувањето и објавувањето се случуваат автоматски.

Нашите услуги почнаа да упатуваат на внатрешни инфраструктурни пакети на ист начин како и надворешните. Преземаме надворешни библиотеки од Nuget. За да работиме со Artifactory, каде што ги сместивме овие пакети, користевме два менаџери на пакети. Во малите складишта користевме и Nuget. Во складиштата со повеќе услуги, користевме Paket, што обезбедува поголема конзистентност на верзијата помеѓу модулите.

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

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

Повеќето од лошите страни за преминување кон микроуслуги се поврзани со инфраструктурата. Ќе ви треба автоматско распоредување, ќе ви требаат нови библиотеки за да ја стартувате инфраструктурата.

Рачна инсталација во средини

Првично, рачно го инсталиравме решението за околини. За да го автоматизираме овој процес, создадовме цевковод CI/CD. Го избравме процесот на континуирана испорака бидејќи континуираното распоредување сè уште не е прифатливо за нас од гледна точка на деловните процеси. Затоа, испраќањето за работа се врши со помош на копче, а за тестирање - автоматски.

Ние користиме Atlassian, Bitbucket за складирање на изворниот код и Bamboo за градење. Сакаме да пишуваме build скрипти во Cake бидејќи е исто како C#. Готови пакети доаѓаат во Artifactory, а Ansible автоматски доаѓа до серверите за тестирање, по што тие можат веднаш да се тестираат.

Одделно сеча

Едно време, една од идеите на монолитот беше да се обезбеди заедничка сеча. Исто така, требаше да разбереме што да правиме со поединечните дневници што се наоѓаат на дисковите. Нашите дневници се запишуваат во текстуални датотеки. Решивме да користиме стандарден стек ELK. Не му пишувавме на ELK директно преку провајдерите, туку решивме да ги финализираме дневниците на текст и да го напишеме ID-то на трага во нив како идентификатор, додавајќи го името на услугата, за да може подоцна да се анализираат овие дневници.

Со Filebeat можеме да ги собираме нашите логови од сервери, потоа трансформирајте ги, користете Kibana за да изградите барања во корисничкиот интерфејс и видете како повикот бил насочен помеѓу услугите. Идентификаторите за траги се многу корисни за ова.

Тестирање и дебагирање поврзани услуги

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

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

Додадовме автоматизиран процес на тестирање користејќи ја популарната библиотека Specflow. Тестовите се извршуваат автоматски со помош на NUnit веднаш по распоредувањето од Ansible. Ако покривањето на задачите е целосно автоматско, тогаш нема потреба од рачно тестирање. Иако понекогаш се уште е потребно дополнително рачно тестирање. Ние користиме ознаки во Jira за да одредиме кои тестови да ги извршиме за одреден проблем.

Дополнително, зголемена е потребата за тестирање на оптоварување, претходно тоа се вршеше само во ретки случаи. Ние користиме JMeter за извршување на тестови, InfluxDB за нивно складирање и Grafana за изградба на графикони на процеси.

Што постигнавме?

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

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

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

Дополнително, значително го намаливме проблемот со голема редица подобрувања. Сега имаме посебни тимови за производи кои работат со некои од услугите независно. Процесот Scrum веќе добро се вклопува овде. Специфичен тим може да има посебен Сопственик на производ кој му доделува задачи.

Краток преглед

• Микросервисите се добро прилагодени за разложување на сложени системи. Во тој процес, почнуваме да разбираме што е во нашиот систем, какви ограничени контексти постојат, каде лежат нивните граници. Ова ви овозможува правилно да ги дистрибуирате подобрувањата меѓу модулите и да спречите конфузија на кодот.
• Микросервисите обезбедуваат организациски придобивки. За нив често се зборува само како архитектура, но секоја архитектура е потребна за да се решат деловните потреби, а не сама по себе. Затоа, можеме да кажеме дека микросервисите се добро прилагодени за решавање на проблеми во мали тимови, имајќи предвид дека Scrum сега е многу популарен.
• Раздвојувањето е итеративен процес. Не можете да земете апликација и едноставно да ја поделите на микросервис. Резултирачкиот производ веројатно нема да биде функционален. Кога се посветуваат микроуслуги, корисно е да се преработи постоечкото наследство, односно да се претвори во код што ни се допаѓа и подобро ги задоволува деловните потреби во однос на функционалноста и брзината.

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

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

Извор: www.habr.com