Обсудить задачу

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

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

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

Go · gRPC · Kafka · Kubernetes · ArgoCD · GitLab CI

Что мешало

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

Что сделали

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

Что стало

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

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

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

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

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

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

Обсудить задачу Услуга: Backend на Go