# Монолит разобран на 15 сервисов на Go

> Монолит разобран на 15 сервисов на Go: контракты в отдельных репозиториях, Kafka для событий, выкатка через ArgoCD без ручных шагов.

Майнинговый пул · высоконагруженная платформа

Разобрать монолит на сервисы так, чтобы выкатка одной части перестала останавливать всю платформу, а команда могла работать над разными кусками одновременно.

**Стек:** Go · gRPC · Kafka · Kubernetes · ArgoCD · GitLab CI

## Что мешало

- Любая правка означала выкатку всего приложения целиком
- Отказ одной подсистемы задевал остальные — общий процесс, общая память
- Нагрузка на статистику и на личный кабинет разная, а масштабировать приходилось всё вместе
- Границы между частями существовали только в головах: код звал код напрямую
- Выкатка была ручной операцией, а значит редкой и страшной

## Что сделали

- Разрезали по зонам ответственности, а не по слоям: авторизация, пользовательские настройки, отзывы, новости, обучение, файлы, статистика, справочники, CMS
- Договоры между сервисами описали в отдельных репозиториях контрактов — protobuf лежит отдельно от реализации, и его нельзя поменять «по-тихому»
- Синхронное взаимодействие — по gRPC, поток событий — через Kafka: то, что можно обработать позже, не держит запрос пользователя
- Наружу сервисы не торчат: перед ними шлюз, который знает про авторизацию и маршрутизацию
- Каждый сервис — свой репозиторий, свой Dockerfile, своя сборка в CI
- Развёртывание перевели на подход «состояние описано в git»: ArgoCD сам приводит кластер к тому, что записано в манифестах
- Разделили окружения: дев и прод — разные кластеры и разные корневые приложения ArgoCD

## Что стало

- **15** — сервисов вместо одного приложения
- **14** — репозиториев с контрактами
- **2** — независимых окружения: дев и прод
- **0** — ручных шагов при выкатке

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

## Чему это научило

Разрезать монолит по слоям — то есть отдельно «база», отдельно «логика» — самый частый способ получить распределённый монолит: сервисов много, а выкатывать всё равно приходится всё сразу. Резать надо по зонам ответственности, и проверка простая: если для одной пользовательской задачи приходится менять три сервиса, границы проведены неверно.

## Другие разборы

- [Миграция справочников 1С → Битрикс24 без дублей](https://it-zarya.ru/cases/1c-b24-migration/) — Перенос справочников из 1С в Битрикс24: 639 компаний, 9 202 контакта, 15 024 реквизита — без ошибок и дублей. Повторный запуск дублей не создаёт.
- [Сквозная аналитика считала неправильно: где терялись заявки](https://it-zarya.ru/cases/analytics-crm-gap/) — 8 826 визитов за неделю и ноль отправок форм в отчётах. Нашли четыре разрыва в связке сайт — сквозная аналитика — CRM и закрыли их на четырёх сайтах.
- [CRM интернет-магазина на 11 000 сделок](https://it-zarya.ru/cases/crm-delicacies/) — Обязательные поля по стадиям, автокопирование данных клиента и починенный робот уведомлений. 2 816 сделок заполнены задним числом без рассылок клиентам.

## Похожая задача

Если узнали свою ситуацию — расскажите, что происходит у вас. Вернёмся с оценкой в часах и планом работ.

[Обсудить задачу](https://it-zarya.ru/contacts/) [Услуга: Backend на Go](https://it-zarya.ru/services/golang/)

---

Источник: https://it-zarya.ru/cases/monolith-split/ · IT-агентство «Заря» · itzarya@mail.ru
Markdown-версия любой страницы сайта — тот же адрес с `.md` на конце. Индекс для ассистентов: https://it-zarya.ru/llms.txt