Складчина Каталог
Мои курсы

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

17 участников
ОК Автор Олег Козырев

О чём курс

Олег Козырев разбирает разработку микросервисов на Go: вы создадите пять связанных сервисов и настроите их взаимодействие, хранение данных, проверку доступа и наблюдаемость.

Для кого

Курс рассчитан на разработчиков, которые переходят на Go, уже пишут на нём и хотят разобраться с архитектурой сервисов, а также готовятся к техническим собеседованиям. Задания построены вокруг задач backend-разработки: разделения кода на слои, работы с базой данных, обмена событиями и настройки инфраструктуры. Программа рассчитана на восемь недель.

Что вы соберёте

Работа начинается с HTTP- и gRPC-сервисов для заказов, склада и платежей. Вы опишете контракты API, свяжете сервисы между собой, разделите транспортный, сервисный и репозиторный слои, напишете тесты. Затем добавите PostgreSQL, миграции, транзакции и конфигурацию через YAML и переменные окружения.

Следующий этап — событийное взаимодействие через Kafka: сервис сборки получает событие об оплате и сообщает о завершении работы. Для учётных записей вы создадите IAM-сервис с регистрацией и входом, а сессии разместите в Redis. В заданиях также есть кеширование, блокировки и защита от повторной обработки событий.

Инструменты и инфраструктура

Для работы с сервисами используются Docker и Docker Compose. Автор разбирает платформенную библиотеку с общими компонентами, управление зависимостями, доменную модель и работу с JSONB в PostgreSQL. На завершающих этапах вы настроите сбор логов в Elasticsearch и Kibana, метрик в Prometheus и Grafana, а также распределённую трассировку в Jaeger через OpenTelemetry.

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

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

  • Неделя 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 г. · описание обновлено 25 октября 2026 г.

Теги курса

Профессии
Backend-разработчикРазработчик
Инструменты
Go

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

ОК Олег Козырев Все материалы
System Design: от паники к алгоритму System Design: от паники к алгоритму 860 ₽ 31 990 ₽ −97%Go прорвемся. Подготовься к собеседованиям по всему циклу найма Go прорвемся. Подготовься к собеседованиям по всему циклу найма 970 ₽ 35 000 ₽ −97%

Ещё интересные курсы 12

Ещё интересные курсы

5 600 ₽ 74 990 ₽