Microservices и Distributed Systems
Границы сервисов, владение данными, работа со сбоями и случаи, когда монолит лучше.
Эта программа планируется и ещё не включена в расписание. Дата, цена и группа не объявлены. Если вы оставите интерес, мы свяжемся, когда программа будет запланирована, или чтобы обсудить индивидуальный формат.
Цель
Программа разбирает основные трудности распределённых систем в рамках реальных решений: где проводить границы сервисов, как определять, кто владеет данными, и как жить с сетевыми сбоями. Открыто обсуждается и то, что микросервисы — не всегда ответ, и разбираются случаи, когда модульный монолит предпочтительнее.
Для кого
- Инженеры с хорошим опытом Spring Boot, которые работают или будут работать с многосервисными системами
- Кандидаты на уровень senior, участвующие в решениях о разделении монолита
- Backend-разработчики, которым нужно оценивать влияние своего сервиса на остальную систему
- Те, кто движется к архитектурной роли
Для кого не подходит
- Те, кто ещё осваивает Spring Boot и основы баз данных: начните с Java Backend Career Track
- Те, кому нужно только администрирование Kubernetes: программа охватывает лишь необходимые концепции
- Те, кто считает микросервисы готовым ответом на любую проблему: программа ставит эту идею под вопрос
Требования
- Опыт написания реальных сервисов на Spring Boot
- Понимание транзакций, индексов и SQL
- Дизайн REST API и основы HTTP
- Запуск контейнеров в Docker
- Общее представление о message broker
Что вы сможете делать
Что вы сможете делать
- Предложить и обосновать разделение на сервисы по границам предметной области
- Построить модель данных, где у каждого набора данных один владелец
- Выбрать между синхронным и асинхронным взаимодействием для конкретного сценария
- Корректно совместно настроить timeout, retry, backoff и circuit breaker
- Реализовать многосервисную операцию как saga с логикой компенсации
- Объяснить влияние eventual consistency на пользовательский опыт
- Проследить запрос через сервисы с помощью distributed tracing
- Упаковать сервис в контейнер и описать его концепциями Kubernetes (deployment, probe, resource limit)
Ни одна образовательная программа не может гарантировать трудоустройство или повышение.
Учебный план
Учебный план
- 01
Границы сервисов
Учимся делить сервисы по бизнес-возможностям, а не по техническим слоям.
- Bounded context и основы domain-driven design
- Признаки границы: частота изменений и владение командой
- Виды связности и ловушка распределённого монолита
- Постепенное разделение подходом strangler
- Модульный монолит как альтернатива
Практическая лабораторная: Предложить разделение на сервисы для заданной монолитной системы заказов и сравнить две альтернативы в таблице компромиссов.
- 02
Владение данными
Отвечаем на вопрос, как строить запросы и отчёты, когда каждый сервис владеет своими данными.
- База данных на сервис и риски общей базы
- Дублирование данных и read model
- API composition и введение в CQRS
- Жизнь без ссылочной целостности между сервисами
- Миграция данных и владение схемой
Практическая лабораторная: Разделить два сервиса, использующих общую таблицу: провести границу владения и написать поэтапный план переноса данных.
- 03
Синхронное и асинхронное взаимодействие
Сравниваем последствия выбора REST, gRPC или обмена сообщениями.
- REST и gRPC: различия контракта и производительности
- Обмен сообщениями и взаимодействие через события
- Временная связность и расчёт доступности
- Контрактные тесты (consumer-driven contract)
- Роль API gateway и BFF
Практическая лабораторная: Построить один и тот же рабочий процесс синхронно и асинхронно и сравнить доступность и задержку.
- 04
Работа со сбоями
Сеть ненадёжна; проектируем систему так, чтобы она правильно на это реагировала.
- Бюджет timeout и каскадный сбой
- Retry, exponential backoff и jitter
- Circuit breaker, bulkhead и load shedding
- Ключи идемпотентности
- Введение в chaos-эксперименты
Практическая лабораторная: Внедрить сбои в сервис и сравнить поведение системы без timeout и circuit breaker и с ними.
- 05
Saga и модели согласованности
Работаем с компенсирующими потоками и eventual consistency вместо распределённых транзакций.
- Strong и eventual consistency
- Saga: choreography и orchestration
- Компенсирующие действия и необратимые шаги
- Transactional outbox
- Как показывать пользователю частичное состояние
Практическая лабораторная: Построить saga для сервисов заказа, оплаты и склада и тестами проверить компенсацию при сбое оплаты.
- 06
Distributed tracing и наблюдаемость
Делаем видимым, что происходит, когда один запрос проходит через несколько сервисов.
- Trace, span и propagation контекста
- Инструментирование через OpenTelemetry
- Correlation ID между сервисами
- Карта сервисов и анализ зависимостей
- Алертинг на основе SLO
Практическая лабораторная: Настроить OpenTelemetry в потоке из трёх сервисов и найти по трейсу источник замедления.
- 07
Развёртывание: контейнеры и концепции Kubernetes
Концепции, нужные, чтобы упаковать и запустить сервис, без погружения в администрирование кластера.
- Слои Docker image и компактные image
- Концепции Deployment, Service и ConfigMap
- Liveness и readiness probe
- Resource request/limit и согласование памяти JVM
- Rolling update и откат
Практическая лабораторная: Контейнеризировать сервис, написать манифест deployment и понаблюдать последствия неверно настроенных probe.
- 08
Когда модульный монолит лучше
Честно оцениваем реальную цену выбора микросервисов и альтернативы.
- Цена операционной сложности
- Размер команды и закон Конвея
- Дисциплина границ внутри модульного монолита
- Запись архитектурного решения (ADR)
Практическая лабораторная: Для заданного сценария компании сравнить монолит, модульный монолит и микросервисы в формате ADR и записать решение.
Практические задания
- Предложение по разделению на сервисы с таблицей компромиссов
- Тест устойчивости с внедрением сбоев
- Реализация saga с тестом компенсации
- Расследование замедления по трейсу
- Запись архитектурного решения (ADR)
Результаты для портфолио
- Учебная система из трёх сервисов с архитектурной диаграммой
- Отчёт по результатам теста устойчивости
- Поток saga с тестами компенсации
- ADR с обоснованием выбора между монолитом и микросервисами
Как оценивается обучение
- Защита архитектурного дизайна
- Code review ментором
- Письменный разбор сценария сбоя
- Обратная связь по ADR
Инструменты и технологии
- Spring Boot
- Docker
- Kubernetes (на уровне концепций)
- OpenTelemetry
- Resilience4j
- PostgreSQL
- Kafka или RabbitMQ
- gRPC
- Grafana
Последовательность уровней
- До
- До этого: Enterprise Spring Boot или сильный опыт уровня middle со Spring Boot.
- После
- После: Kafka и Event-Driven Architecture, System Design.
- Длительность и формат
- Длительность и формат ещё не определены; программа планируется и не включена в расписание.
Частые вопросы
Частые вопросы
Доступна ли программа сейчас?
Нет. Программа планируется и пока не стоит в расписании. Даты и цены не объявлены. Вы можете оставить интерес или запросить консультацию.
Нужно ли знать Kubernetes?
Заранее не нужно. Программа объясняет лишь концепции вроде deployment, probe и resource limit; администрирование кластера не входит.
Программа продвигает микросервисы?
Нет. Ценность и цена микросервисов обсуждаются в равной мере, а случаи, когда выигрывает модульный монолит, разобраны в отдельном модуле.
Есть ли сертификат или обещание работы?
Нет. Ни сертификат, ни результат не обещаются. Оценка проходит в форме защит дизайна и обратной связи ментора и носит рекомендательный характер.
Статьи по теме программы
- Облачная архитектураCloud architecture basics for backend engineers
- Распределённые системыFailure handling in distributed systems
- DockerDocker for Java services
- Распределённые системыIdempotency patterns for safe retries
- МикросервисыDrawing microservice boundaries
- ObservabilityObservability: logs, metrics and traces