Публикувано на: 9 май, 2025В света на съвременната софтуерна разработка микросървисите често се смятат за златния стандарт за мащабируема архитектура — но невинаги са оптималното решение.
Илия Погудин, back-end разработчик в Artesia, споделя откровен поглед зад кулисите на решението на екипа да премине от раздробена система от над 30 сървиса към по-уеднаквена домейн архитектура. Този преход, продиктуван от нарастващата сложност и неефективност, носи ценни поуки за всеки технологичен екип, изправен пред подобни предизвикателства.
Независимо дали разширявате платформа или обмисляте рефакторинг, историята на Илия е едновременно поучителна и прозрачно честна.
Каква беше архитектурата на Artesia преди промяната – колко микросървиса поддържахте?
Преди преминаването имахме над 30 различни услуги. Те бяха изградени на прост принцип – всяка задача, която може логически да се обособи, си имаше отделен сървис. Например за всеки доставчик на данни (vendor) – а те бяха 11 – имахме отделна услуга (наричахме ги адаптери). Също така за всеки вид вътрешни данни, с които работехме – като потребители или статии – имаше съответен сървис.
Не бихме ги нарекли микросървиси в строгия смисъл – не бяхме раздробили всичко до крайност – но те бяха независими, управляеми единици. Услугите комуникираха помежду си чрез gRPC и асинхронно през Kafka.
В даден момент започнахме да преминаваме към оркестрация за управление на асинхронните потоци, но спряхме навреме, осъзнавайки в какъв ад бихме се вкарали. (За това ще разкажа друг път. 😊)
Какво ви подтикна да преосмислите подхода си?
Основната причина бяха нарастващите трудности при поддръжката на толкова фрагментирана кодова база. Дори прости промени отнемаха твърде много време.
Ако например трябваше даден сървис да вземе ново поле от vendor-a, процесът изглеждаше така:
- Работиш минимум с два сървиса (таргет сървис и vendor услуга);
- Ъпдейтваш или обновяваш услугите от двете страни, с цел комуникация;
- Поддръжка и тестване на двете услуги;
- Промяна в интеграцията и от страна на vendor-a;
- Дефинираш всяко от съобщенията два пъти – за заявка и за отговор.
В крайна сметка прекарвахме твърде много време в „механично прехвърляне на данни“, което е оправдано при огромни екипи, но не и за нас.
Loading …Имаше ли ранни признаци, че микросървисната архитектура не е устойчива?
Да. Все по-често се чуваха коментари от рода на: „Защо правя едно и също по 2–3 пъти в различни сървиси? Това ми губи времето.“ Явно се натрупваха умора и раздразнение.
С какви основни предизвикателства се сблъсквахте при работа с микросървиси (деплоймънт, дебъгване, забавяне)?
Типичните проблеми:
- Повече код = по-голям шанс за бъгове;
- По-голямо натоварване върху CI/CD;
- По-голямо когнитивно натоварване за екипа;
- Дори малка промяна изискваше разгръщане на 5–6 сървиса с внимателно следене за сривове.
Как междусървисната комуникация (API, опашки) повлия на продуктивността на екипа?
След като намалихме броя на сървисите, ефективността осезаемо се повиши. Трудно е да се измери точно, но със сигурност спестихме време от монотонни задачи и планирането стана по-лесно.
Разгръщането на нови функционалности вече не беше болезнено.
Explore more
Какво се подобри най-забележимо след промяната – скоростта на разработка, надеждността на системата, въвеждането на нови хора?
Няколко явни подобрения:
- Времето за разработка и поддръжка значително намаля;
- Когнитивната и алгоритмична сложност спадна → по-малко грешки;
- Общият обем на кода намаля → по-малко сървиси за поддръжка.
Разбира се, щом няколко сървиса вече можеха да се свързват с един и същи доставчик, възникна риск от дублиране на логиката за заявки. Решението беше да изградим SDK за всеки vendor, които съхранявахме в споделено хранилище. Всеки сървис просто включваше нужния SDK, подаваше credential-и и инициализираше – навсякъде по един и същи начин.
Имаше ли неочаквани последици след миграцията?
Да – основно по отношение на времето. Някои процеси не можеха да се мигрират поетапно и изискваха едновременен преход.
Оценките ни за времето се оказаха твърде оптимистични – отне ни повече време за стабилизиране и отстраняване на бъгове, което забави и част от планираните функционалности в backlog-a.
Ако друг екип обмисля преход от микросървиси към домейн сървиси, какво бихте ги посъветвали?
Трудно е да се даде универсален съвет, защото всеки проект и екип е уникален. Но, ако можех да върна времето назад, бих казал:
- Обмислете сериозно рефакторинг, ако сегашната архитектура натоварва инфраструктурата ви и влияе на стабилността и скоростта на доставка.
- Бъдете реалисти – миграцията почти винаги отнема повече време от планираното.
От по-широка перспектива нашият случай всъщност противоречи на популярната препоръка: „Започнете с монолит, после разделяйте на сървиси и микросървиси, когато проектът порасне.“
В реалността, когато проектът започне да расте бързо, бизнесът рядко отделя ресурси за голям рефакторинг. Добавянето на нови сървиси успоредно с монолита е скъпо и малко вероятно. А, когато вече се наложи да се разделя монолита, процесът е бавен, рисков и пълен с нови бъгове.
Поддръжката на голям legacy монолит винаги е болезнена – дори ъпгрейд на основния език може да стане кошмар заради хилядите зависимости.
Когато започнахме новия си проект, заложихме още от началото на архитектура, базирана на сървиси. Не скочихме директно в микросървиси – това е архитектура, която има смисъл при много специфични, мащабни случаи.
Но все пак допуснахме една грешка – раздробихме услугите повече, отколкото беше нужно.
Днес по-големите домейн сървиси работят много по-добре за нас. По-лесни са за изграждане, за мащабиране и – при нужда – могат да бъдат разбити допълнително без много трудности.
