Mockingbird Shares | Доля підкинула шанс посидіти на співбесідах бекенд інженерів, а там од...

Доля підкинула шанс посидіти на співбесідах бекенд інженерів, а там одне з питань "шо ви думаєте про мікросервіси", а я багато різного думаю, і вирішив поділитись з вами.Так от: наприклад, якщо сервісу Orders треба інформація про користувача, якою опікується сервіс Users, то як то краще реалізувати?Класичний сценарій це звісно REST виклик до потрібного сервісу. Для команд — створити замовлення, провести оплату — синхронний виклик це нормально, тут питань нема. Але коли мова про читання чужих даних, і Orders ходить в Users щоб дістати ім'я, адресу, ще щось — починаються проблеми. Users приляже — Orders відпочиватиме разом з ним. Може навіть статись, що впав сервіс, який викликався сервісом, який викликав ваш сервіс (так, це складно прочитати, але ще складніше траблшутити). Додайте сюди ризик зламати щось оновленням сусіднього сервісу. Поміняли контракт, не врахували зворотню сумісність — і ваш сервіс впав. Налажали суміжники, а вночі прокинулись ви... тут важко знайти позитив. Є спокуса піти напряму в базу і забрати ті чортові дані. Книжка пише шо це антипатерн — shared database. Але давайте чесно: нерідко одна команда хендлить обидва сервіси, шарить інстанс бази, спільні бібліотеки. Зв'язаність вже є, просто замість мережевої маєте залежність на рівні даних, яку ще важче відстежити. І без жодного контракту — бо "ми ж і так знаємо структуру". Розподілений моноліт, в якому певні речі табу, бо тоді його не можна назвати мікросервісами.А от шо реально працює — коли сервіс сам тримає все, що йому треба. Наприклад, Users публікує зміни в топік Kafka. Orders підписаний, читає, тримає свою локальну проекцію потрібних даних. Коли приходить замовлення — Orders нікуди не ходить, він вже все знає. Users впав? Orders працює далі, йому байдуже. Так, Kafka теж не панацея. Це додаткова інфраструктура, моніторинг лагу консюмерів, дебаг івентів що десь загубились. Але це складність, яку ви контролюєте, а не складність, яка вас будить о третій ночі.Тут є звісно eventual consistency, і це лякає людей. "А шо якщо дані не актуальні?" Ну а скільки разів за рік у вас реально був кейс, де юзер змінив ім'я і в ту ж мілісекунду зробив замовлення? А тепер порівняйте це з кількістю разів, коли один сервіс тягнув за собою інший на дно. Трейдоф очевидний, просто один ризик теоретичний, а інший — щоп'ятниці на проді.Якщо у вас бомбануло на попередньому абзаці, то це я спеціально :) Насправді зазвичай лаг між оновленнями дійсно доволі малий, аби спричинити реальні проблеми. А якщо його треба враховувати, то є різні патерни, що стануть у пригоді — знайти їх можна в книжці з кабанчиком, наприклад. І головне — це саме той підхід, де ваші сервіси реально автономні. Не на слайдах, не на архітектурній діаграмі, а в продакшені о третій ночі, коли щось горить. Якщо ваш сервіс не може обробити запит через проблемного сусіда — у вас не мікросервіси. У вас моноліт, який складніше дебажити. Kafka — не срібна куля, але хоча б ваші сервіси будуть падати незалежно один від одного. А це вже щось.