Микросервисы на GO 3.0

Name: Микросервисы на GO 3.0
Price: 2800 RUB
Availability: PreOrder

17 участников

О чём курс

Этот курс представляет собой интенсивную программу обучения, разработанную для backend-разработчиков, стремящихся освоить язык Go на уровне, соответствующем стандартам ведущих технологических компаний (BigTech). Программа сфокусирована на создании высоконагруженных, масштабируемых микросервисных систем, аналогичных тем, что используются в таких компаниях, как VK, Yandex, Ozon, Сбер и Тинькофф. Обучение построено исключительно на решении реальных инженерных задач, с которыми специалисты сталкиваются в продакшене, что позволяет студентам не просто изучить синтаксис языка, но и глубоко понять архитектурные принципы построения современных систем.

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

Формат обучения предполагает интенсивную практику: вы разработаете 5 микросервисов, которые будут взаимодействовать друг с другом через Kafka и gRPC, обеспечите их изоляцию с помощью Envoy Gateway, настроите мониторинг по стандарту OpenTelemetry, внедрите кеширование на Redis и работу с PostgreSQL. Вы научитесь писать платформенные библиотеки, реализовывать системы аутентификации и авторизации, а также применять архитектурные подходы, такие как Clean Architecture и Domain-Driven Design (DDD).

Почему стоит пройти этот курс? Во-первых, вы получите практический опыт работы с production-ready стеком технологий, включая HTTP, gRPC, Kafka, Redis, PostgreSQL, Prometheus, Grafana, Jaeger и Elasticsearch. Во-вторых, вы научитесь проектировать системы, которые легко масштабируются и поддерживаются. В-третьих, курс дает глубокое понимание того, как устроены микросервисы «под капотом», что позволит вам уверенно отвечать на вопросы уровня Senior на собеседованиях. На выходе вы будете обладать готовым портфолио из пяти связанных микросервисов и навыками, необходимыми для работы над сложными высоконагруженными системами, что значительно повысит ваши шансы на получение оффера в топовые компании или переход на более высокий грейд.

Программа обучения

Неделя 1. HTTP и gRPC: два протокола, которые должен знать каждый Go-разработчик
Неделя 2. Clean Architecture и тесты: пишем код, как в BigTech-компаниях
Неделя 3. Docker и PostgreSQL: сервисы обретают настоящее хранилище
Неделя 4. Конфигурация, DI и Domain-Driven Design
Неделя 5. Kafka: асинхронная коммуникация между сервисами
Неделя 6. Аутентификация: IAM-сервис и Redis
Неделя 7. Observability: логи, метрики и распределённые трейсы
Неделя 8. Контейнеризация, балансировка и распределённый Rate Limiting
Блок 1. gRPC — язык, на котором говорят микросервисы
Protocol Buffers с нуля — описываем контракт сервиса в ".proto"-файле
buf — генерируем Go-код одной командой вместо ручной возни с protoc
Поднимаем gRPC-сервер и клиент — полноценный CRUD для управления данными
Интерцепторы: перехватываем каждый запрос — логирование, перехват паник и кастомная логика
gRPC-Gateway + Swagger UI — один сервис, два протокола: REST снаружи, gRPC внутри
Валидация входных данных — отсекаем невалидные запросы ещё до попадания в бизнес-логику
Блок 2. HTTP — REST API на промышленном уровне
Chi — самый популярный Go-роутер — маршруты, цепочки middleware, таймауты и корректное завершение работы
Сначала контракт, потом код — описываем OpenAPI-спецификацию, получаем типизированный сервер с валидацией из коробки через Ogen
HTTP вызывает gRPC — связываем сервисы между собой: HTTP-фронтенд обращается к gRPC-бэкенду
Блок 3. Go Workspace — мультимодульный проект
go.work для нескольких сервисов — общие proto-определения, общие зависимости, единый репозиторий
Блок 4. Слоистая архитектура — структура, которую поймёт любой разработчик
API → Service → Repository → Client — чёткое разделение ответственности
Три модели данных — модель API, доменная модель, модель хранилища: зачем их разделять и как конвертировать между собой
Инверсия зависимостей — интерфейсы определяет тот, кто использует, а не тот, кто реализует
Стратегия обработки ошибок — единые ошибки-маркеры на каждом слое, понятная цепочка от базы до клиента
Блок 5. Unit-тесты — от нуля до полного покрытия за 7 шагов
Первый тест на чистом Go — testing.T, никаких фреймворков
Табличные тесты — один тест, десять сценариев: описываем входы и ожидаемые результаты
testify — читаемые проверки вместо ручных if err != nil
Стабы: подменяем зависимости вручную — простая реализация в памяти вместо реальной базы
mockery — генерируем моки автоматически — задаём ожидания, проверяем вызовы
Тесты в Clean Architecture — мокаем репозиторий, тестируем бизнес-логику изолированно
Параллельные тесты — запускаем тесты одновременно и не ловим гонки
Блок 6. Docker — упаковываем сервис в контейнер
Многоэтапная сборка Docker-образа — 800 МБ Go SDK превращаются в 10 МБ финальный образ
Запуск не от root — безопасно, как требуют в продакшене
Docker Compose — база данных, миграции и сервис поднимаются одной командой
Healthcheck и зависимости — контейнеры стартуют в правильном порядке
Блок 7. PostgreSQL — SQL на Go без боли
pgx — самый быстрый драйвер для PostgreSQL с пулом соединений (переиспользуем подключения, а не создаём новые на каждый запрос)
Squirrel — SQL-конструктор — собираем запросы программно, без склейки строк
Миграции через Goose — версионируем схему базы, накатываем изменения при деплое
Практические приёмы — получаем ID сразу при вставке, работаем с nullable-полями, избегаем SQL-инъекций
Блок 8. Транзакции — атомарность без компромиссов
Transaction Manager — оборачиваем несколько операций в транзакцию, не протаскивая объект транзакции через все слои
Прозрачные транзакции — репозиторий даже не знает, что работает внутри транзакции — всё скрыто в контексте
Блок 9. Конфигурация — параметры сервиса без хардкода
YAML + переменные окружения через cleanenv — один конфиг-файл, переопределения через переменные окружения для каждого стенда
Профили: local / production / docker — переключаем поведение без изменения кода
Блок 10. DI-контейнер — управление зависимостями без магии
Ручной DI на Go — создаём зависимости лениво: только когда понадобятся
Корректное завершение работы — ресурсы закрываются в обратном порядке: что открыли последним — закрываем первым
Платформенная библиотека — проверка здоровья сервиса, логгер, менеджер закрытия ресурсов: переиспользуемые компоненты для всех сервисов
Блок 11. JSONB — гибкие структуры в PostgreSQL
JSONB-колонки — храним разнородные данные (характеристики разных типов деталей) в одной колонке без раздувания схемы
Индексы по JSON — быстрый поиск внутри JSON-структур
Блок 12. Domain-Driven Design — бизнес-логика, которая сама себя защищает
Сущности с поведением — объекты сами знают свои правила, а не просто хранят данные
Value Objects — типизированные значения (например, «прочность корпуса»), которые нельзя создать в невалидном состоянии
Агрегаты — группа связанных объектов с единой точкой входа, которая контролирует целостность данных
Доменный сервис — проверка совместимости компонентов корабля перед заказом
Резервирование деталей — Reserve/Release с защитой от невалидных состояний
Блок 13. Apache Kafka — шина событий для микросервисов
Синхронный и асинхронный продюсер — гарантия доставки каждого сообщения vs максимальная пропускная способность
Консюмер — читаем поток событий — смещения, партиции, чтение с начала или с конца
Consumer Groups — горизонтальное масштабирование — несколько экземпляров сервиса делят между собой поток сообщений, автоматически перераспределяя нагрузку
Обработка сообщений пачками — накапливаем и обрабатываем группой для производительности
Kafka в Clean Architecture — выделяем слои для асинхронных потоков так же, как для HTTP и gRPC
Блок 14. Select for update — блокировки в PostgreSQL
Блокировка строк при чтении — «заморозить» запись в базе, пока мы с ней работаем, чтобы другой запрос не изменил её параллельно
Правильный порядок блокировок — всегда блокируем строки в одном и том же порядке, чтобы два запроса не заблокировали друг друга навечно
Повторная обработка событий без последствий — даже если Kafka доставит сообщение дважды, данные не сломаются
Блок 15. Redis — быстрое key-value хранилище
Базовые операции — простые ключи, хеш-таблицы, хранение структур
Время жизни ключей (TTL) — данные автоматически удаляются через заданное время: идеально для сессий и кеша
Распределённая блокировка через Redis — когда несколько экземпляров сервиса должны по очереди работать с общим ресурсом
Защита от лавины запросов — если тысяча пользователей одновременно запросила одно и то же, в базу уходит только один запрос
Redis в Clean Architecture — кеширующий слой как отдельный репозиторий
Блок 16. Аутентификация на сессиях — от логина до защиты API
bcrypt — хешируем пароли правильно — почему md5 и sha256 для паролей использовать нельзя
Сессии в Redis с временем жизни — создание, проверка, удаление
gRPC-интерцептор для проверки сессий — список открытых методов, извлечение токена из заголовка
HTTP middleware для аутентификации — проверяем сессию через IAM, пробрасываем ID пользователя в контекст запроса
Передача информации о пользователе между сервисами — gRPC metadata для пробрасывания идентификатора через цепочку вызовов
Блок 17. Логирование — от println до Kibana
Структурированные логи через slog + OpenTelemetry — логи отправляются в единый коллектор телеметрии
Запись сразу в два места — одновременно в консоль и в Elasticsearch, чтобы видеть логи и локально, и в централизованном хранилище
Kibana — ищем и анализируем логи всех сервисов в одном интерфейсе
Устойчивость к сбоям — если Elasticsearch упал, сервис продолжает работать и писать логи в консоль
Блок 18. Метрики — Prometheus и Grafana
Счётчики, гистограммы и другие типы метрик — считаем количество запросов, замеряем время ответа, отслеживаем текущую нагрузку
Автоматический сбор метрик gRPC — подключается в одну строку, сразу видим latency и количество ошибок
Prometheus — собирает метрики со всех сервисов через единый коллектор
Grafana-дашборды — красивые графики бизнес-метрик: заказы, выручка, время сборки
Блок 19. Распределённый трейсинг — видим путь запроса насквозь
Сквозной идентификатор запроса — один trace-id проходит через все сервисы, позволяя восстановить полный путь
Автоматический сбор трейсов для gRPC — подключается без изменения бизнес-кода
Добавляем бизнес-контекст к трейсам — видим не только «запрос прошёл», но и «какой заказ, какой пользователь»
Jaeger — визуализация полного пути запроса через все сервисы на одном таймлайне
Инструментация Redis — подключаем трейсы, метрики и логи для каждого вызова кеша через систему хуков
Блок 20. Контейнеризация и Nginx — всё в Docker, балансировка нагрузки
Многоэтапная сборка Docker-образа для каждого сервиса — сначала компилируем, затем берём только бинарник в минимальный образ
Docker Compose для всей системы — 5 сервисов + вся инфраструктура поднимаются одной командой
Nginx как балансировщик — запросы равномерно распределяются между репликами OrderService
Горизонтальное масштабирование — запускаем несколько копий сервиса, Nginx сам находит их по имени
Блок 21. Паттерны отказоустойчивости — чтобы сервис выжил в продакшене
Rate Limiter — ограничиваем количество запросов в секунду, чтобы сервис не захлебнулся под

Складчина создана 4 апреля 2026 г. · описание обновлено 19 июня 2026 г.

Теги курса

Другие материалы автора 2

ОК Олег Козырев Все материалы

System Design: от паники к алгоритму 2 454 ₽ 49 990 ₽ −95%

Go прорвемся. Подготовься к собеседованиям по всему циклу найма 970 ₽ 35 000 ₽ −97%

Отзывов пока нет. Будьте первым!

Как получить курс?

Влада Администратор сайта

Этот курс сейчас в процессе организации складчины. Нажмите кнопку «Записаться» и ожидайте старта — вам придёт уведомление. Когда складчина стартует, в карточке курса будет указан актуальный взнос. Текущая цена пока в процессе формирования и может отличаться от финальной.

Финальный взнос будет ниже, чем 74 990 ₽?

Влада Администратор сайта

Да, мы стремимся, чтобы финальный взнос был не больше ≈10% от оригинальной цены курса. Чем больше участников записывается в складчину, тем ниже выходит взнос для каждого.

Как я могу ускорить сбор складчины и уменьшить взнос?

Влада Администратор сайта

Нажмите кнопку «Записаться» и авторизуйтесь на сайте через email (через ту же почту, которую будете использовать для входа). В личном кабинете вас будут ждать инструкции, как пригласить других участников — чем больше людей записалось, тем быстрее стартует складчина и тем ниже взнос. Как только складчина готова к приобретению, вам придёт уведомление.