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

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

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

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

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

Съдържание

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

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

Първоначално архитектурата изглеждаше така: потребителският интерфейс е отделно приложение, монолитната част е написана на 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. Това означава раздел от модела на домейн, в който всички термини на един език са уникално дефинирани. Нека да разгледаме контекста на застраховката и сметките като пример. Имаме монолитно приложение и трябва да работим с акаунта в застраховката. Очакваме разработчикът да намери съществуващ клас Account в друга сборка, да го направи справка от класа Insurance и ще имаме работещ код. Принципът 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 за изграждане. Обичаме да пишем скриптове за изграждане на Cake, защото е същият като C#. Готовите пакети идват в Artifactory, а Ansible автоматично стига до тестовите сървъри, след което могат да бъдат тествани веднага.

Отделно регистриране

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

С Filebeat можем да събираме лог файловете си от сървъри, след което ги трансформирайте, използвайте Kibana за изграждане на заявки в потребителския интерфейс и вижте как повикването е било маршрутизирано между услугите. Идентификаторите на проследяване са много полезни за това.

Услуги, свързани с тестване и отстраняване на грешки

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

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

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

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

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

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

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

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

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

Обобщение

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

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

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

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