Микросервисы на GO 3.0 [Тариф Стандарт] [Олег Козырев]

Rphoenix · 4 апр 2026

Складчина: Микросервисы на GO 3.0 [Тариф Стандарт] [Олег Козырев]

Освой backend на Go и выйди на уровень BigTech
Научись разрабатывать высоконагруженные, масштабируемые микросервисы, как в VK, Yandex, Ozon, Сбере и Тинькофф — и увеличь свои шансы на оффер или повышение грейда.

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

Для кого этот курс

Хочешь перейти на Go
Быстро адаптируешься к новому стеку и перестанешь писать «как на старом языке».

Пишешь на Go, но упёрся в потолок
Разберёшься в продакшен-практиках и начнёшь решать сложные инженерные задачи.

Готовишься к собеседованиям
Получишь системное понимание архитектуры и уверенно будешь отвечать на вопросы уровня BigTech.

Что ты освоишь
Разберёшь внутреннее устройство Go и микросервисной архитектуры:

HTTP / OpenAPI / gRPC

Kafka и асинхронное взаимодействие

Redis (кеширование)

PostgreSQL

Observability: Prometheus, Grafana, Jaeger, OpenTelemetry

Elasticsearch, Kibana

Envoy Gateway

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

Вся подкапотная микросервисов в одном обучении

шаг 1. Разработаешь 5 микросервисов, связанных между собой через Kafka и gRPC, с изоляцией от внешнего мира с помощью Envoy Gateway

шаг 2. Обеспечишь мониторинг сервиса по стандарту OpenTelemetry с юнит-тестами, чтобы исключить ошибки в работе

шаг 3. Освоишь кеширование данных с помощью Redis и асинхронное взаимодействие между микросервисами с помощью Kafka

шаг 4. Освоишь работу с PostgreSQL, напишешь свою платформенную библиотеку, упрощающую разработку

шаг 5. Реализуешь межсервисное взаимодействие, систему аутентификации и авторизации

шаг 6. На практике научишься применять архитектурные подходы построения микросервисов

Программа
8 недель. 5 микросервисов. Production-ready стек.

Неделя 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. HTTP и gRPC: два протокола, которые должен знать каждый Go-разработчик

Блок 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-определения, общие зависимости, единый репозиторий

Домашнее задание
Реализовать 3 микросервиса: OrderService (HTTP), InventoryService (gRPC), PaymentService (gRPC). Связать их через gRPC-клиенты — заказ обращается к складу и платёжке.

Результат недели
Ты с нуля напишешь 3 работающих сервиса на двух протоколах, освоишь кодогенерацию API из контрактов и научишься связывать микросервисы между собой. Это фундамент, на котором строится всё остальное.

Неделя 2. Clean Architecture и тесты: пишем код, как в BigTech-компаниях

Блок 4. Слоистая архитектура — структура, которую поймёт любой разработчик

API → Service → Repository → Client — чёткое разделение ответственности

Три модели данных — модель API, доменная модель, модель хранилища: зачем их разделять и как конвертировать между собой

Инверсия зависимостей — интерфейсы определяет тот, кто использует, а не тот, кто реализует

Стратегия обработки ошибок — единые ошибки-маркеры на каждом слое, понятная цепочка от базы до клиента

Блок 5. Unit-тесты — от нуля до полного покрытия за 7 шагов

Первый тест на чистом Go** — `testing.T`, никаких фреймворков

Табличные тесты — один тест, десять сценариев: описываем входы и ожидаемые результаты

testify — читаемые проверки вместо ручных `if err != nil`

Стабы: подменяем зависимости вручную — простая реализация в памяти вместо реальной базы

mockery — генерируем моки автоматически — задаём ожидания, проверяем вызовы

Тесты в Clean Architecture — мокаем репозиторий, тестируем бизнес-логику изолированно

Параллельные тесты — запускаем тесты одновременно и не ловим гонки

Домашнее задание
Рефакторинг всех 3 сервисов в Clean Architecture. Unit-тесты с моками на сервисный и API-слой. Покрытие ≥40%.

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

Неделя 3. Docker и PostgreSQL: сервисы обретают настоящее хранилище

Блок 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 — оборачиваем несколько операций в транзакцию, не протаскивая объект транзакции через все слои

Прозрачные транзакции — репозиторий даже не знает, что работает внутри транзакции — всё скрыто в контексте

Домашнее задание
Поднять PostgreSQL через Docker Compose для OrderService и InventoryService. Написать миграции, заменить хранение в памяти на реальные SQL-запросы. Интегрировать Transaction Manager для атомарного создания заказа

Результат недели
Хранилище в памяти заменено на PostgreSQL. Ты умеешь поднимать инфраструктуру через Docker Compose, делать миграции, писать запросы и проектировать хранилища. Паттерн Transaction Manager — один из самых частых вопросов на собеседованиях

Неделя 4. Конфигурация, DI и Domain-Driven Design

Блок 9. Конфигурация — параметры сервиса без хардкода

YAML + переменные окружения через cleanenv — один конфиг-файл, переопределения через переменные окружения для каждого стенда

Профили: local / production / docker — переключаем поведение без изменения кода

Блок 10. DI-контейнер — управление зависимостями без магии

Ручной DI на Go — создаём зависимости лениво: только когда понадобятся

Корректное завершение работы — ресурсы закрываются в обратном порядке: что открыли последним — закрываем первым

Платформенная библиотека — проверка здоровья сервиса, логгер, менеджер закрытия ресурсов: переиспользуемые компоненты для всех сервисов

Блок 11. JSONB — гибкие структуры в PostgreSQL

JSONB-колонки — храним разнородные данные (характеристики разных типов деталей) в одной колонке без раздувания схемы

Индексы по JSON — быстрый поиск внутри JSON-структур

Блок 12. Domain-Driven Design — бизнес-логика, которая сама себя защищает

Сущности с поведением — объекты сами знают свои правила, а не просто хранят данные

Value Objects — типизированные значения (например, «прочность корпуса»), которые нельзя создать в невалидном состоянии

Агрегаты — группа связанных объектов с единой точкой входа, которая контролирует целостность данных

Доменный сервис — проверка совместимости компонентов корабля перед заказом

Резервирование деталей — Reserve/Release с защитой от невалидных состояний

Домашнее задание
Внедрить конфигурацию и DI-контейнер во все сервисы. Создать платформенную библиотеку. Реализовать DDD: сущность Part с методами Reserve/Release, Value Objects для свойств компонентов в JSONB, сервис проверки совместимости при заказе

Результат недели
Сервисы конфигурируются через YAML и переменные окружения, зависимости собираются через DI-контейнер, ресурсы корректно освобождаются при завершении. Бизнес-логика защищена доменной моделью — невалидное состояние невозможно создать в принципе. Ты строишь не просто сервисы, а **платформу** — как это делают в BigTech-компаниях

Неделя 5. Kafka: асинхронная коммуникация между сервисами

Блок 13. Apache Kafka — шина событий для микросервисов

Синхронный и асинхронный продюсер — гарантия доставки каждого сообщения vs максимальная пропускная способность

Консюмер — читаем поток событий — смещения, партиции, чтение с начала или с конца

Consumer Groups — горизонтальное масштабирование — несколько экземпляров сервиса делят между собой поток сообщений, автоматически перераспределяя нагрузку

Обработка сообщений пачками — накапливаем и обрабатываем группой для производительности

Kafka в Clean Architecture — выделяем слои для асинхронных потоков так же, как для HTTP и gRPC

Блок 14. Select for update — блокировки в PostgreSQL

Блокировка строк при чтении — «заморозить» запись в базе, пока мы с ней работаем, чтобы другой запрос не изменил её параллельно

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

Повторная обработка событий без последствий — даже если Kafka доставит сообщение дважды, данные не сломаются

Домашнее задание
Поднять Kafka. Создать AssemblyService — новый микросервис, который слушает событие оплаты, «собирает корабль» и отправляет событие завершения сборки. OrderService публикует событие при оплате и обновляет статус при получении результата сборки. Блокировка строк для безопасного резервирования деталей.

Результат недели
Полная асинхронная цепочка: заказ → оплата → сборка → обновление статуса. Четвёртый микросервис (AssemblyService) работает через Kafka. Ты освоил событийную архитектуру — именно так обрабатывают миллионы событий в BigTech-компаниях вроде OZON, Яндекса и Тинькофф

Неделя 6. Аутентификация: IAM-сервис и Redis

Блок 15. Redis — быстрое key-value хранилище

Базовые операции — простые ключи, хеш-таблицы, хранение структур

Время жизни ключей (TTL) — данные автоматически удаляются через заданное время: идеально для сессий и кеша

Распределённая блокировка через Redis — когда несколько экземпляров сервиса должны по очереди работать с общим ресурсом

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

Redis в Clean Architecture — кеширующий слой как отдельный репозиторий

Блок 16. Аутентификация на сессиях — от логина до защиты API

bcrypt — хешируем пароли правильно — почему md5 и sha256 для паролей использовать нельзя

Сессии в Redis с временем жизни — создание, проверка, удаление

gRPC-интерцептор для проверки сессий — список открытых методов, извлечение токена из заголовка

HTTP middleware для аутентификации — проверяем сессию через IAM, пробрасываем ID пользователя в контекст запроса

Передача информации о пользователе между сервисами — gRPC metadata для пробрасывания идентификатора через цепочку вызовов

Домашнее задание
Создать IAM Service — пятый микросервис: Register, Login, Logout, Whoami, GetUser. Пользователи в PostgreSQL, сессии в Redis с ограниченным временем жизни. Добавить HTTP middleware в OrderService и gRPC-интерцептор в InventoryService для проверки сессий через IAM.

Результат недели
Пятый микросервис — полноценный IAM с регистрацией, аутентификацией и хранением сессий в Redis. Каждый запрос проходит проверку — API больше не открыт всему миру. Плюс ты освоил распределённые блокировки и защиту от лавинных запросов — паттерны, которые спрашивают на каждом Senior-собеседовании.

Неделя 7. Observability: логи, метрики и распределённые трейсы

Блок 17. Логирование — от println до Kibana

Структурированные логи через slog + OpenTelemetry — логи отправляются в единый коллектор телеметрии

Запись сразу в два места — одновременно в консоль и в Elasticsearch, чтобы видеть логи и локально, и в централизованном хранилище

Kibana — ищем и анализируем логи всех сервисов в одном интерфейсе

Устойчивость к сбоям — если Elasticsearch упал, сервис продолжает работать и писать логи в консоль

Блок 18. Метрики — Prometheus и Grafana

Счётчики, гистограммы и другие типы метрик — считаем количество запросов, замеряем время ответа, отслеживаем текущую нагрузку

Автоматический сбор метрик gRPC — подключается в одну строку, сразу видим latency и количество ошибок

Prometheus — собирает метрики со всех сервисов через единый коллектор

Grafana-дашборды — красивые графики бизнес-метрик: заказы, выручка, время сборки

Блок 19. Распределённый трейсинг — видим путь запроса насквозь

Сквозной идентификатор запроса — один trace-id проходит через все сервисы, позволяя восстановить полный путь

Автоматический сбор трейсов для gRPC — подключается без изменения бизнес-кода

Добавляем бизнес-контекст к трейсам — видим не только «запрос прошёл», но и «какой заказ, какой пользователь»

Jaeger — визуализация полного пути запроса через все сервисы на одном таймлайне

Инструментация Redis — подключаем трейсы, метрики и логи для каждого вызова кеша через систему хуков

Домашнее задание
Развернуть полный стек наблюдаемости: коллектор телеметрии, Elasticsearch + Kibana, Prometheus + Grafana, Jaeger. Настроить логи всех сервисов в Kibana. Бизнес-метрики (заказы, выручка) в Grafana. Трассировка полного пути запроса через Order → Inventory → Payment. Вынести инструменты наблюдаемости в платформенную библиотеку.

Результат недели
Полноценная система наблюдаемости: Grafana с метриками, Kibana с логами, Jaeger с трейсами. Ты видишь каждый запрос от входа до ответа через все сервисы. Это уровень, который отличает Middle от Senior.

Неделя 8. Контейнеризация, балансировка и распределённый Rate Limiting

Блок 20. Контейнеризация и Nginx — всё в Docker, балансировка нагрузки

Многоэтапная сборка Docker-образа для каждого сервиса — сначала компилируем, затем берём только бинарник в минимальный образ

Docker Compose для всей системы — 5 сервисов + вся инфраструктура поднимаются одной командой

Nginx как балансировщик — запросы равномерно распределяются между репликами OrderService

Горизонтальное масштабирование — запускаем несколько копий сервиса, Nginx сам находит их по имени

Блок 21. Паттерны отказоустойчивости — чтобы сервис выжил в продакшене

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

Retry с нарастающей задержкой — клиент автоматически повторяет запрос при временных сбоях, каждый раз ожидая чуть дольше (плюс случайный разброс, чтобы все клиенты не повторили одновременно)

Circuit Breaker — если сервис начал падать, автоматически прекращаем к нему обращаться, даём восстановиться, затем аккуратно проверяем: заработал ли

Распределённый Rate Limiter через Redis — единый лимит на все копии сервиса, настройка лимитов отдельно для каждого метода, если Redis недоступен — пропускаем запросы, а не блокируем

Блок 22. Нагрузочное тестирование — проверяем, что всё работает под давлением

vegeta — заливаем HTTP-трафиком, замеряем время ответа и пропускную способность

ghz — то же самое для gRPC, проверяем rate limiter под реальной нагрузкой

Домашнее задание
Контейнеризировать все сервисы. Собрать единый Docker Compose со всей инфраструктурой. Настроить Nginx для балансировки OrderService на 3 реплики. Реализовать распределённый Rate Limiter через Redis — единый лимит на все экземпляры. Провести нагрузочное тестирование

Результат недели
Микросервисная система полностью собрана — от API до мониторинга, от аутентификации до балансировки нагрузки. 5 сервисов в Docker-контейнерах за Nginx, распределённый rate limiter защищает от перегрузки, нагрузочные тесты подтверждают работоспособность. Это готовый проект для портфолио и уверенный ответ на любой вопрос собеседования про микросервисы.

Результат

Уверенно работаешь с Go в продакшене

Понимаешь, как устроены микросервисы в крупных компаниях

Имеешь сильный проект в портфолио

Готов к собеседованиям и росту зарплаты

Преподаватель и автор курса — Олег Козырев
Senior Engineer в BigTech
Все, как на работе — контрактное программирование, DI, тесты, docker-compose, observability. Это сложный проект, где придётся много писать руками, разбираться в зависимостях и реально прокачиваться как инженер

Тариф Стандарт

Цена: 74990 руб.
Скрытая ссылка