Артём Шумейко

⚡️ Последний день набора на курс по микросервисам

Сегодня до 23:59 МСК ты можешь успеть присоединиться к курсу "Микросервисная архитектура в продакшен разработке", а завтра, 10 ноября, мы начинаем обучение.

Вести его будет Станислав Клоков, который проводил открытый урок. В Яндексе он занимался разработкой ядра платформы микросервисов, сейчас руководит командой в высоконагруженном финтех-проекте, а также преподаёт в ВШЭ и МФТИ.

За шесть недель ты пройдёшь весь путь работы с микросервисами:
😊 определишь границы сервисов и владельцев данных
😊 спроектируешь API с учётом таймаутов, повторов и частичных отказов
😊 настроишь взаимодействие через Kafka, outbox и защиту от повторной обработки
😊 разберёшь распределённые бизнес-операции, саги и компенсации
😊 соберёшь данные нескольких сервисов для клиентского приложения
😊 добавишь тесты, логи, метрики и распределённую трассировку

На протяжении курса ты будешь развивать один большой проект на Python. Ты постепенно разделишь его на сервисы, наладишь взаимодействие между ними и проверишь поведение системы при задержках, сбоях и повторных запросах.

❗️ Каждую неделю ты будешь обучаться на онлайн-лекциях и отдельно на занятиях с практикой, все встречи останутся в записи. Также дополнительно разобрать вопросы можно будет в чате. На продвинутом тарифе Станислав лично проверит домашние задания и даст обратную связь по твоим решениям.

Если хочешь разобраться в работе микросервисов, присоединяйся сегодня, чтобы завтра начать обучение вместе со всеми

👉 Выбрать тариф

Зачем каждому микросервису своя база данных

На первый взгляд может показаться, что и с одной базой все ок, зачем же тогда каждому сервису своя база?) Давайте разбираться

Если все сервисы пилит один человек или маленькая команда, которая хорошо в них шарит, можно жить с общей базой. Договориться, кто с какими таблицами работает, аккуратно ходить за данными. Главное — не ломать чужие данные и учитывать зависимости от таблиц, которыми пользуются другие сервисы.

Но если команда большая, каждый разработчик пилит свой сервис и не знает про другой, начинаются проблемы... Разберем как обычно на сервисе музыки (писал статью про него тут). Например, сервис музыки и кабинет музыканта напрямую читают таблицу выпусков в общей БД, за которую отвечает сервис подкастов. Затем разработчик подкастов решил поменять название поля в БД, спокойненько релизит свой сервис, а затем оказывается, что сломались два чужих сервиса)

В таких случаях нас и выручает паттерн database per service (одна база на сервис): каждый сервис владеет своими данными, остальные ходят за ними в его API-шку. Кстати, для этого не надо поднимать отдельный кластер БД под каждый сервис: базы могут жить в одном кластере, а данные можно разделить по базам или схемам. Внутри своей базы меняем названия полей, переделываем таблицы — это наше дело, пока API остаётся совместимым. Ну а если меняем сам API, то нужно учитывать обратную совместимость, чтобы не сломать другие сервисы. Так команды могут деплоить свои сервисы без синхронного релиза остальных.

Но за это мы платим удобством. Как было раньше в монолите: собрал данные одним join-ом и пошёл дальше, а здесь нужно стучаться в другие сервисы и собирать всё по крупицам. С транзакциями тоже больше запар: локальная транзакция одного сервиса не охватывает изменения через апишки остальных. Если операция затрагивает несколько сервисов, нужно отдельно продумывать согласованность данных и что делать при частичном сбое (паттерн сага в помощь).

На деле, паттерн DB per serivce скорее нужен для независимой разработки команд, чем для разделения баз данных, чтобы разработчики могли спокойно менять свои сервисы, не боясь сломать чужие.

Как проходит обучение на курсе по микросервисам в продакшен разработке

Когда проектируешь микросервисы, каждое решение влияет на другие части системы и выбранные границы определяют взаимодействие сервисов, способ хранения данных влияет на бизнес-операции, а обработка отказов сказывается на поведении всего приложения.

Поэтому на курсе каждую неделю будет отдельное практическое занятие, где ты внедришь материал лекций, разберёшь архитектурные задачи и сравнишь варианты решений.

Все домашние задания складываются в один проект на Python, который ты будешь развивать на протяжении шести недель. Сначала определишь границы сервисов и владельцев данных, затем добавишь API, события и распределённые операции, а после настроишь тесты и наблюдаемость. Каждое следующее задание позволит проверить предыдущие решения в новых условиях и увидеть, как они влияют на систему по мере её развития.

На продвинутом тарифе твои домашние задания будет проверять тимлид высоконагруженного финтех-проекта, экс-техлид Яндекса. Ты получишь обратную связь по архитектуре и коду, сможешь обсудить выбранный подход, его ограничения и возможные альтернативы.

Вопросы по ходу обучения можно будет задавать в общем чате, а записи занятий останутся на платформе, чтобы возвращаться к нужным темам и использовать материалы в работе.

Стартуем 10 ноября, выбирай тариф на сайте