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

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

Проектът започна историята си доста отдавна, в началото на 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 000 реда код. Това е доста голямо решение и вторият проблем. Просто да го вземем и разделим на микросервиси не представляваше възможно.

Третата пробема — липса на необходимата инфраструктура. Всъщност ние се занимавахме с ръчно копиране на изходния код на сървърите.

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

Извеждане на микросервиси

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

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

Първи начин — да се извършва изнасяне на съществуващите модули като услуги. В това отношение имахме късмет: вече имаше оформени услуги, които работиха по протокол 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 слоя. Основното ни UI приложение е десктопно и е написано на C#, както и бекендът. Разработчиците понякога правят грешки и изнасят в UI части от логиката, които трябва да съществуват в бекенда и да могат да се преизползват.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Работа с БД

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разделно логване

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

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

Тестване и отстраняване на проблеми с взаимосвързани услуги

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

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

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

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

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

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

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

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

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

Резюме

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

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

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

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