Про микросервисы

Показать описание

00:00 О книге Production Ready Microservices
02:00 Что такое микросервисы и монолит
03:00 Рост операционных расходов
04:58 Увеличение количества кода и технического долга
06:53 Масштабирование
09:41 Производительность
10:47 Доступность
11:09 Service Level Agreement
12:53 Timeouts
15:14 База данных

Рекомендации по теме

Комментарии

Спасибо большое, пересматриваю спустя несколько лет, а если пересматриваю, значит ценно =)

slavapinchuk

Спасибо за видос по архитектуре!

Хорошо, что такие люди как ты бесплатно делятся своим опытом в таком понятном формате

professorpirog

Классное видео, спасибо. Давно тебя не было.
По поводу проблем с микросервисами: мой опыт показывает, что все беды из-за человеческого фактора.
Основная проблема большинства это создание микросервисов ради создания микросервисов (что прослеживается и по примерам в видео).
В этом случае почти любая новая фича выносится в отдельный сервис особо не задумываясь, а надо ли ее выносить в отдельный сервис.
На моей практике микросервисы далеко не всегда такие микро, как все думают. И кстати RPC или REST далеко не самые хорошие способы коммуникации между сервисами. Вообще тема огромная конечно, могу говорить о ней бесконечно :D

Я бы еще добавил, что у идеальных микросервисов довольно высокий порог входа для бизнеса:
1. Нужны инженеры, которые в теме про всякие саги, транзакционность, брокеры сообщений и так далее
2. Нужна devops культура в компании и штат devops инженеров
3. Нужен сильный архитектор, который будет в состоянии за этим следить
4. Критически важно иметь хороших product managers особенно для проработки спецификаций
Для небольших компаний, увы, этот подход чаще всего не является выгодным.

TheHardcoreSpider

Отличный анализ, поддерживаю идею о том что начинать нужно с монолита, а микросервисы внедрять по мере необходимости. Да и приставка микро мне кажется тут лишняя. Я считаю что бить приложения на части нужно в двух случаях, о первом вы рассказали в видео, когда растет нагрузка на какую-то часть и ее нужно срочно масштабировать, второй когда над приложением работает большая команда, тогда можно вынести часть бизнес контекстов в отдельное приложение и разделить команду. Что касается баз данных то я считаю что крупный монолит тоже должен работать на нескольких базах данных, отдельная база данных для каждого boundary context (DDD). Проблему кучи мелких запросов может решить паттерн CQRS. Коммуникацию между контекстами лучше изначально делать асинхронной используя event driven архитектуру. Монолит спроектированный таким образом очень легко разбивается на сервисы по границам бизнес-контекстов.

mikeshapovalov

Какая вы классная) я в восторге! Спасибо за труд.

ekaterinashu

1) монолит лучше микросервиса
2) в микросервисе упрощается обслуживание гита
3) правильно распиленный по ddd микросервис отлично борется с техдолгом
4) микросервисы - это от безысходности, а не от того, что лучше

SerZab

Посмотрел залпом несколько Ваших видео. Класс! Спасибо большое!

FroL_Onn

Привет, большое спасибо за видео, посмотрел почти все взахлеб, не пропадай надолго!

donutduck

Очень интересно! ждем вашего возвращения.

Art-ubsg

Благодарю вас Ксения за такое видео! впервые слушаю и все понимаю, очень хорошо ложится ваше изложение :) У вас отличный канал!

kairgeldi

Приятно слушать думающего человека. Спасибо и удачи! Абсолютно так и есть, и честно говоря, все еще хуже, и просвет не намечается. Какую технологию не возьми, монолит, трехзвенку, микросервесы и т.п., если критическое количество разработчиков с кривыми ручками превосходит порог выносливости системы, то никакая архитектура не спасет. Программер должен всю жизнь учиться, иначе выходит только г**нокод. Я сам программер 25+ лет, и все встречавшиеся проблемы были только в квалификации и прилежности программеров, не в архитектуре. Один раз правильно написанный код работает десятилетиями.

Sokolyuk

С праздником! Мне очень нравится твой видео, я на втором курсе в Румынии и мне твой видео очень помогают. Можешь сделать и видео про алгоритмы и структуры данных? Спасибо!

catalinstratu

Был опыт не совсем микросервис, но делили написание функционала по языкам: На golang стримили видео, а взаимодействие с базой полностью на python. Такой вот микро-микро сервис был. Спасибо за интересный разбор интересной темы.

nafisaisrail