Преход от монолит към микросервизи: история и практика

В тази статия ще разкажа как проектът, по който работя, се превърна от голям монолит в набор от микросервизи.

Проектът започна историята си доста отдавна, в началото на 2000-те години. Първите версии бяха написани на Visual Basic 6. С течение на времето стана очевидно, че разработката на този език в бъдеще ще бъде сложна за поддръжка, тъй като IDE и самият език се развиват слабо. В края на 2000-те години беше решено да се премине на по-перспективния C#. Новата версия се писаше паралелно с доработката на старата, постепенно все повече код бе на .NET. Backend-ът на C# първоначално беше насочен към сервисна архитектура, но при разработката се използваха общи библиотеки с логика, а и сервисите се стартираха в един и същ процес. Получи се приложение, което наричахме "сервисен монолит".

Едно от малкото предимства на тази връзка беше възможността сервисите да се извикват един друг чрез външно API. Имаше ясни предпоставки за преход към по-правилна сервисна архитектура, а в перспектива и микросервисна такава.

Започнахме работата си по декомпозицията около 2015 година. Все още не сме достигнали идеалното състояние — остават части от големия проект, които вече трудно могат да се нарекат монолити, но и не приличат на микросервизи. Въпреки това, напредъкът е значителен.
За него ще разкажа в статията.

Съдържание

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

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

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

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

Единна точка на отказ
Имамeхме единна точка на отказ: приложението на .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.Run("RBA.Services.Accounts.Host");

       }
    }
}

Вторият начин за извеждане на микросервизи: да ги създаваме за решаване на нови задачи. Ако в същото време монолитът не расте, това вече е отлично, значи се движим в правилната посока. За решаване на нови задачи се стремяхме да правим отделни услуги. Ако имаше такава възможност, създавахме по-"канонични" услуги, които напълно управляват своята моделна данни, отделна база данни.

Ние, както и много други, започнахме с услуги за удостоверяване и авторизация. Те са идеални за това. Обикновено са независими и имат отделна моделна данни. Те сами не взаимодействат с монолита, само той се обръща към тях за решаване на определени задачи. На тези услуги може да се започне преходът към нова архитектура, да се отстраняват грешки на тях, да се пробват различни подходи, свързани с мрежовите библиотеки и т.н. В нашата организация няма екипи, които да не са успели да направят услуга за удостоверяване.

Третият начин за извеждане на микросервизи, който използваме, е малко специфичен за нас. Става въпрос за изнесената бизнес логика от интерфейса. Основното ни UI приложение е настолно и, както бекендът, е написано на C#. Разработчиците периодично правят грешки и пренасят логика на UI, която трябва да съществува в бекенда и да се повторно използва.

Ако погледнем истински пример от кода на UI частта, ще видим, че голяма част от това решение съдържа действителна бизнес логика, която е полезна в други процеси, не само за изграждане на UI форма.

Истинската логика на UI е само в последните две реда. Пренесохме я на сървъра, за да можем да я повторно използваме, като по този начин намаляваме UI и постигаме правилна архитектура.

Четвъртият, най-важен начин за оформяне на микросервизи, който позволява да намалим монолита, е изнасянето на съществуващите услуги с преосмисляне. Когато изнасяме съществуващи модули както са, резултатът не винаги удовлетворава разработчиците, а бизнес процесът от времето на създаването на функционала е могъл да остарее. Чрез рефакторинг можем да поддържаме нов бизнес процес, тъй като изискванията на бизнеса непрекъснато се променят. Можем да подобрим изходния код, да премахнем известни дефекти и да създадем по-качествена модел на данни. Събират се много предимства.

Отделянето на услуги с преосмисляне е неразривно свързано с понятието за ограничен контекст. Това е концепция от предметно-ориентираното проектиране. Тя означава участък от домейн модел, в който всички термини на единен език са точно определени. Нека разгледаме примера с контекста на застраховките и сметките. Имаме монолитно приложение и е необходимо да работим със сметката в застраховките. Очакваме, че разработчикът ще намери в друга сборка съществуващ клас „Сметка“, ще направи референция към него от класа „Застраховка“, и ще получим работещ код. Принципът DRY ще бъде спазен, задачата чрез използване на съществуващ код ще бъде свършена по-бързо.

В крайна сметка се оказва, че контекстите на сметките и застраховките са свързани. Когато се появят нови изисквания, тази връзка ще пречи на разработката, увеличавайки сложността на и без това сложната бизнес логика. За да решим този проблем, е необходимо в кода да се открият границите между контекстите и да се отстранят техните нарушения. Например, на контекста на застраховките, цялостно, може да е достатъчен 20-значен номер на сметка на ЦБ и дата на откриване на сметка.

За да разделим тези ограничени контексти един от друг и да започнем процеса по извеждане на микросервизи от монолитното решение, използвахме подхода на създаване на външни API в приложението. Ако знаехме, че даден модул трябва да стане микросервис, или да се видоизменя в рамките на процеса, веднага правехме извиквания на логиката, принадлежаща на друг ограничен контекст, чрез външни извиквания. Например, чрез REST или WCF.

Ние решихме безусловно, че няма да избягваме код, който изисква да правим разпределени транзакции. В нашия случай се оказа сравнително лесно да спазваме това правило. До момента не сме имали ситуации, при които действително да са необходими жестоки разпределени транзакции — напълно е достатъчна крайна съгласуваност между модулите.

Нека разгледаме конкретен пример. Имаме понятието оркестратор — конвейер, който обработва същността „заявка“. Той последователно създава клиент, сметка и банкова карта. Ако клиентът и сметката са създадени успешно, а създаването на картата е провалено, заявката не преминава в статус „успешно“ и остава в статус „картата не е създадена“. В бъдеще фонова активност ще я подеме и завърши. Системата остава известно време в състояние на несъгласуваност, но за нас това е приемливо.

В случай че все пак възникне ситуация, в която ще бъде необходимо последователно да се запази част от данните, вероятно ще се наложи да увеличим размера на услугата, за да обработим това в един процес.

Нека разгледаме пример за извеждане на микросервис. Как може относително безопасно да го доведем до продукция? В този пример имаме отделна част от системата — модул за заплати, един от участъците код, който бихме искали да направим микросервисен.

На първо място създаваме микросервис, прекодирайки кода. Подобряваме някои моменти, които не ни удовлетворяваха. Реализираме нови бизнес изисквания от клиента. Добавяме API Gateway в връзката между UI и бекенда, който ще осигурява предаване на повиквания.

След това пускаме тази конфигурация в експлоатация, но в пилотен режим. Повечето потребители все още работят със старите бизнес процеси. За новите потребители разработваме нова версия на монолитното приложение, което вече не съдържа този процес. Всъщност, в пилотния режим работи връзката между монолита и микросервиса.

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

В крайна сметка прилагаме почти всички съществуващи методи за разделяне на изходния код на монолита. Всички те ни позволяват да намалим размера на частите от приложението и да ги прехвърлим на нови библиотеки, създавайки по-качен изходен код.

Работа с БД

Базата данни се разделя по-лошо от изходния код, тъй като съдържа не само текущата схема, но и натрупаните исторически данни.

Нашата база данни, както и много други, имаше още един важен недостатък — огромния размер. Тази база данни беше проектирана в съответствие със заплетената бизнес логика на монолита и между таблиците на различните ограничени контексти се натрупаха връзки.

В нашия случай, като добавим всичките проблеми (голяма база данни, множество връзки, понякога неясни граници между таблиците), се появи проблем, който се среща в много големи проекти: използването на шаблона shared database. Данните идваха от таблиците чрез view, чрез репликация и се изпращаха в други системи, където тази репликация е необходима. В резултат не можехме да изнесем таблиците в отделна схема, тъй като те активно се използваха.

В разделянето ни помага това разделение на ограничени контексти в кода. То обикновено ни дава достатъчно добро разбиране за това как разделяме данните на ниво база данни. Разбираме кои таблици принадлежат на един ограничен контекст и кои на друг.

Приложихме два глобални метода за разделяне на базата данни: отделяне на съществуващите таблици и отделяне с преработка.

Отделянето на съществуващите таблици е метод, който е подходящ за прилагане, когато структурата на данните е качествена, отговаря на бизнес изискванията и е приета от всички. В този случай можем да отделим съществуващите таблици в отделна схема.

Отделянето с преработка е необходимо, когато бизнес моделът е значително променен и таблиците вече не удовлетворяват нуждите ни.

Отделяне на съществуващите таблици. Трябва да определим какво ще отделим. Без това знание нищо няма да се получи и тук ни помага разделението на ограничени контексти в кода. Като правило, ако успеем да разберем границите на контекстите в изходния код, става ясно кои таблици трябва да попаднат в списъка за отделяне.

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

На следващата стъпка можем да отделим част от кода, работеща с отделяемите таблици, с преработка или без преработка, в отделен микросервис и да я стартираме в отделен процес, контейнер. Това ще бъде отделен сервис с връзка с базата данни на монолита и с таблиците, които не принадлежат директно към него. Монолитът все още взаимодействува с отделяемата част за четене.

По-късно ще премахнем тази връзка, т.е. читенето на данни от монолитното приложение от отделяемите таблици също ще бъде преместено на API.

След това ще отделим от общата база данни таблиците, с които работи само новият микросервис. Можем да изнесем таблиците в отделна схема или дори в отделна физическа база данни. Остана връзката за четене между микросервиса и базата данни на монолита, но в това няма нищо страшно, в такава конфигурация той може да съществува достатъчно дълго.

Последната стъпка е да премахнем напълно всички връзки. В този случай може да се наложи да мигрираме данни от основната база. Понякога искаме да повторно използваме в няколко бази определени реплицирани данни или справочници от външни системи. Това периодично се случва при нас.

Отделение с преработка. Този метод е много сходен с първия, но следва обратен ред. Незабавно се създава нова база данни и нов микросервис, който взаимодействува с монолита чрез API. В същото време остава набор от таблици в БД, които искаме да премахнем в бъдеще. Те вече няма да са необходими, заменени сме в новия модел.

За да заработи тази схема, вероятно ще е необходим преходен период.

Следват два възможни подхода.

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

Втори: разделяме данните по някакъв бизнес признак. Например, в системата ни имаше 5 продукта, които се съхраняват в старата база данни. Шестият в новата бизнес задача ще бъде в новата БД. Но ще е необходим API Gateway, който да синхронизира тези данни и да покаже на клиента откъде и какво да вземе.

И двата подхода работят, изберете в зависимост от ситуацията.

След като се уверим, че всичко работи, част от монолита, която работи със старите структури на БД, може да бъде изключена.

Последната стъпка ще бъде премахването на старите структури на данни.

Накрая можем да кажем, че имаме проблеми с БД: трудно е да се работи с нея в сравнение с изходния код, по-трудно е да се разделя, но все пак може и трябва да се прави. Намерили сме някои начини, които позволяват да се прави това достатъчно безопасно, все пак да допуснем грешка с данните е по-лесно, отколкото с изходния код.

Работа със изходния код

Така изглеждаше схемата на изходния код, когато започнахме да анализираме монолитния проект.

Условно можем да го разделим на три слоя. Това е слой на стартирани модули, плъгини, услуги и отделни активности. Всъщност, това бяха входни точки в монолитното решение. Всички те бяха плътно свързани със слоя Common. В него се съдържаше бизнес логика, която се използваше от услугите заедно, и множество зависимости. Всяка услуга и плъгин използваше до 10 и повече общи сборки, в зависимост от техния размер и съвестта на разработчиците.

Имахме късмет, разполагахме с инфраструктурни библиотеки, които можехме да използваме поотделно.

Понякога възникваше ситуация, когато някои Common обекти всъщност не принадлежаха на този слой, а бяха инфраструктурни библиотеки. Това се решаваше с преименуване.

Най-много притеснения предизвикваха ограничените контексти. Понякога 3-4 контекста се смесваха в една сборка Common и се използваха взаимно в рамките на едни и същи бизнес функции. Необходимо беше да разберем къде можем да ги разделим и по какви граници, и какво да правим след това с мапинга на това разделение на сборките на изходния код.

Сформирахме няколко правила за процеса на разделяне на кода.

Първо: не искахме повече да споделяме бизнес логика между услугите, активностите и плъгините. Искахме бизнес логиката да бъде независима в рамките на микросервизите. От друга страна, микросервизите, в идеалния случай, се възприемат като услуги, които съществуват напълно независимо. Смятам, че този подход е донякъде разточителен и е трудно да се постигне, тъй като, например, услугите на C# все пак ще бъдат свързани със стандартната библиотека. Нашата система е написана на C#, а други технологии засега не употребяваме. Затова решихме, че можем да си позволим да използваме общи технически сборки. Важно е само в тях да не има никакви фрагменти от бизнес логика. Ако имате удобна обвивка над ORM, която използвате, то е много скъпо да я копирате от услуга на услуга.

Нашият екип е почитател на предметно-ориентираното проектиране, затова "луковата архитектура" ни подхожда прекрасно. Основата на нашите сервизи е не слой за достъп до данни, а сборка с домейнна логика, която съдържа само бизнес логика и е лишена от връзки с инфраструктурата. В същото време можем независимо да развиваме домейновата сборка, за да решим проблемите, свързани с фреймворците.

На този етап срещнахме първата сериозна проблема. Сервизът трябваше да се отнася към една домейнна сборка, логиката искахме да направим независима, но принципът DRY много ни пречеше. Разработчиците искаха да преиспользват класовете от съседни сборки, за да избегнат дублирането, и в резултат домените отново започнаха да се свързват помежду си. Анализирахме резултатите и решихме, че проблемът може да се крие и в устройството на хранилището на изходния код. Имахме голям репозиторий, в който бяха събрани всички изходни кодове. Решението за целия проект беше много трудно да се събере на локалната машина. Затова за частите на проекта се създаваха отделни малки решения и никой не забраняваше да добавим в тях някаква обща или домейна сборка и да я преиспользваме. Единственият инструмент, който не ни позволяваше да правим това, беше рецензията на кода. Но понякога и той даваше сбои.

Тогава започнахме да преминаваме на модел с отделни репозитории. Бизнес логиката спря да протича от сервиз на сервиз, домените наистина стана независими. Ограничените контексти се поддържат по-ясно. Как обаче преиспользваме инфраструктурните библиотеки? Отделихме ги в отделен репозиторий, след това ги поставихме в Nuget пакети, които сложихме в Artifactory. При всяко изменение, сборката и публикацията се извършват автоматично.

Нашите сервизи започнаха да се отнасят към вътрешни инфраструктурни пакети точно както и към външни. Външните библиотеки сваляме от Nuget. За работа с Artifactory, където поставяхме тези пакети, приложихме два пакетни мениджъра. В малките репозитории също използвахме Nuget. В репозиториите с няколко сервиза използвахме Paket, който осигурява повече съгласуваност на версиите между модулите.

По този начин, работейки по изходния код, малко променяйки архитектурата и разделяйки хранилищата, ние правим нашите услуги по-независими.

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

Повечето недостатъци при преминаването към микросервизи са свързани с инфраструктурата. Ще ви е необходимо автоматизирано разгръщане, ще са ви нужни нови библиотеки за работа с инфраструктурата.

Ръчна инсталация в среди

Първоначално настройвахме средите ръчно. За да автоматизираме този процес, създадохме CI/CD конвейер. Избрахме процеса за непрекъснато доставяне, защото непрекъснатото разгръщане все още не е приемливо за нас от гледна точка на бизнес процесите. Затова разгръщането в експлоатация се извършва с натискане на бутон, а тестването — автоматично.

Използваме Atlassian, Bitbucket за съхранение на изходния код и Bamboo за компилиране. Харесва ни да пишем скриптове за компилиране на Cake, защото това е същият C#. В Artifactory идват вече готови пакети, а Ansible автоматично попада на тестовите сървъри, след което могат веднага да бъдат тествани.

Разделно логиране

Преди време една от идеите на монолита беше осигуряване на съвместно логване. Трябваше също да разберем какво да правим с отделните логове, които са на дисковете. Логовете ни се записват в текстови файлове. Решихме да използваме стандартния ELK стек. Не се опитахме да записваме в ELK директно през доставчиците, а решихме, че ще доработим текстовите логове и ще записваме в тях ID на трасировката под формата на идентификатор, добавяйки името на услугата, за да може след това тези логове да бъдат анализирани.

С помощта на Filebeat получаваме възможност да събираме нашите логове от сървъри, след което да ги преобразуваме, с помощта на Kibana да изграждаме заявки в UI и да наблюдаваме как е протичал извикването между услугите. В това много помага ID на трасировката.

Тестване и отстраняване на грешки в свързаните сервисите

В началото не разбирахме напълно как да отстраняваме грешки в разработваните услуги. С монолита всичко беше просто, стартирахме го на локалната машина. Първоначално също опитвахме да правим същото и с микросервисите, но понякога за пълноценен старт на един микросервис е нужно да стартираме и няколко други, което е неудобно. Разбрахме, че е необходимо да преминем към модел, в който оставяме на локалната машина само услугата или услугите, които искаме да отстраняваме. Останалите услуги се използват от сървъри, които съвпадат по конфигурация с прод. След отстраняване на грешки, при тестването, за всяка задача на тестовия сървър се издават само променените услуги. По този начин, решението се тествува в такава форма, в каквато в бъдеще ще бъде на продукция.

Има сървъри, на които са инсталирани само продукционните версии на услугите. Тези сървъри са необходими за случаи на инциденти, за проверка на доставките преди разгръщането и за вътрешно обучение.

Добави се процес на автоматично тестване с помощта на популярната библиотека Specflow. Тестовете се стартират автоматично с NUnit веднага след разгръщането от Ansible. Ако покритие на задачата е напълно автоматично, то няма нужда от ръчно тестване. Въпреки това, понякога все пак се изисква допълнително ръчно тестване. За да определим кои тестове да стартираме за конкретна задача, използваме тагове в Jira.

Допълнително нарасна нуждата от натоварващо тестване, което преди се извършваше само в редки случаи. За стартиране на тестовете използваме JMeter, за тяхното съхранение — InfluxDB, а за построяване на графики на процеса — Grafana.

Какво постигнахме?

На първо място, се отървахме от понятието "релиз". Изчезнаха двемесечните монструозни релизи, когато тази машина се разгръщаше в продукционна среда, нарушавайки временно бизнес процесите. В момента разгръщаме услуги средно на всеки 1,5 дни, групирайки ги, тъй като в експлоатация те излизат след съгласуване.

В нашата система няма фатални сривове. Ако пуснем микросервис с грешка, свързаната с него функционалност ще е счупена, а цялата останала функционалност не ще пострада. Това значително подобрява потребителското изживяване.

Можем да управляваме схемата за разгръщане. Можем да отделим групи от услуги от цялостното решение, ако е необходимо.

Освен това значително намалихме проблема с голямото количество остарели задачи. Имаме отделни продуктови екипи, които работят независимо с част от услугите. Тук вече добре работи процесът Scrum. Конкретен екип може да има отделен собственик на продукта, който поставя задачи.

Резюме

• Микросервисите са подходящи за декомпозиция на сложни системи. По време на процеса започваме да разбираме какво има в нашата система, какви са ограничените контексти и къде минават техните граници. Това позволява правилно разпределение на задачите по модулите и предотвратяване на заплитане на кода.
• Микросервисите предлагат организационни предимства. Често говорят за тях само като архитектура, но всяка архитектура е необходима за решаване на бизнес нужди, а не сама по себе си. Затова можем да кажем, че микросервисите са подходящи за решаване на задачи от малки екипи, имайки предвид, че в момента Scrum е много популярен.
• Разделянето е итеративен процес. Невъзможно е просто да вземеш приложение и да го разделиш на микросервизи. Полученият продукт едва ли ще бъде работещ. При отделяне на микросервизи е изгодно да пренапишем съществуващото legacy, т.е. да го преобразуваме в код, който ни харесва и по-добре задоволява бизнес нуждите по отношение на функционалност и бързина.

  Небольшо предупреждение: разходите за преход към микросервизи са доста значителни. Само за решаване на инфраструктурния проблем отне много време. Затова, ако имате малко приложение, което не изисква специфично мащабиране, и ако няма голямо количество клиенти, които се борят за вниманието и времето на вашия екип, то може би микросервисите не са нещото, от което се нуждаете в момента. Това е сравнително скъпо. Ако започнете процеса с микросервизи, разходите в началото ще бъдат по-големи, отколкото ако същият проект започне с разработката на монолит.

  P.S. По-емоционална история (и сякаш лично за вас) – по връзка.
  Тук е пълната версия на доклада.

Източник: habr.com