Изглежда, че пикът на шума за микроуслугите е зад нас. Вече не четем публикации няколко пъти седмично „Как преместих монолита си на 150 услуги.“ Сега чувам повече здравомислещи мисли: „Не мразя монолита, просто ме интересува ефективността.“ Дори наблюдавахме няколко миграции от микроуслуги обратно към монолит. Когато преминавате от едно голямо приложение към множество по-малки услуги, ще трябва да решите няколко нови проблема. Нека ги изброим възможно най-кратко.

Обстановка: от основна химия до квантова механика

Създаването на основна база данни и приложение с фонов процес беше доста лесен процес. Публикувам readme в Github - и често след час, най-много няколко часа, всичко работи и започвам нов проект. Добавянето и стартирането на код, поне за първоначалната среда, се извършва в първия ден. Но ако се впуснем в микроуслугите, първоначалното време за стартиране скача до небето. Да, сега имаме Docker с оркестрация и клъстер от K8 машини, но за начинаещ програмист всичко това е много по-сложно. За много юноши това е бреме, което е наистина ненужно усложнение.

Системата не е лесна за разбиране

Нека се съсредоточим върху нашия младши за момент. При монолитни приложения, ако възникне грешка, беше лесно да я проследите и веднага да преминете към отстраняване на грешки. Сега имаме услуга, която говори с друга услуга, която поставя нещо на опашка в шина за съобщения, която обработва друга услуга - и тогава възниква грешка. Трябва да съберем всички тези части заедно, за да разберем в крайна сметка, че Услуга A работи с версия 11, а Услуга E вече чака версия 12. Това е много различно от моя стандартен консолидиран журнал: трябва да използвам интерактивен терминал/дебъгер за ходене през процеса стъпка по стъпка. Отстраняването на грешки и разбирането по своята същност станаха по-трудни.

Ако не може да се отстрани грешка, може би ще ги тестваме

Непрекъснатата интеграция и непрекъснатото развитие вече стават нещо обичайно. Повечето нови приложения, които виждам, автоматично създават и провеждат тестове с всяка нова версия и изискват тестове да бъдат направени и прегледани преди регистрация. Това са страхотни процеси, които не бива да се изоставят и са голяма промяна за много компании. Но сега, за да тествам наистина услугата, трябва да изтегля пълна работеща версия на моето приложение. Помните ли онзи нов инженер с клъстера K8 от 150 услуги? Е, сега ще научим нашата CI система как да изведе всички тези системи, за да провери дали всичко наистина работи. Това вероятно е твърде голямо усилие, така че просто ще тестваме всяка част изолирано: уверен съм, че спецификациите ни са достатъчно добри, API-тата са чисти и грешката в услугата е изолирана и няма да засегне другите.

Всички компромиси имат добра причина. нали

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

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

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