> Какие доводы и обстоятельства влияют на решение о делении или объединении сервисов (Go)

На решение о делении или объединении сервисов в Go-микросервисной архитектуре влияют несколько ключевых доводов и обстоятельств.

Доводы за деление:

• Независимость развертывания и масштабирования. Если разные части системы требуют разного количества ресурсов (например, один сервис - CPU-интенсивный, другой - I/O-bound), их разделение позволяет масштабировать их по отдельности. В Go это особенно актуально из-за легковесных горутин, но разный профиль нагрузки всё равно требует изоляции.
• Разные требования к надежности и SLA. Критичные сервисы (например, платежи) должны быть изолированы от менее важных (например, логов), чтобы сбой одного не затронул другой.
• Разные команды и владельцы. Если над разными модулями работают разные команды, деление упрощает CI/CD, code review и снижает конфликты в коде.
• Технологическая разнородность. Хотя в Go-стеке это редкость, иногда часть сервиса выгоднее переписать на другом языке (например, для ML-моделей на Python). Деление позволяет это сделать без переписывания всего.

Доводы за объединение:

• Снижение сетевых накладных расходов. Каждый вызов между сервисами добавляет задержку (сериализация/десериализация, сеть). В Go, где производительность высока, излишнее деление может свести на нет преимущества языка.
• Упрощение транзакционной целостности. Если операции требуют атомарности (например, создание заказа и списание товара), в монолитном сервисе проще использовать транзакции БД, чем распределённые саги.
• Снижение сложности оркестрации. Меньше сервисов - меньше нужно управлять очередями, балансировщиками, мониторингом. Для небольших команд это критично.
• Общая память и кэш. В одном процессе Go можно использовать общие структуры данных (например, sync.Map) без дополнительных протоколов.

Обстоятельства, влияющие на решение:

• Текущий размер команды и её зрелость. Для стартапа из 5 человек 10 микросервисов - избыточная сложность.
• Частота изменений. Если два модуля почти всегда меняются вместе (например, user и profile), их объединение уменьшает количество релизов.
• Нагрузка и профиль производительности. Если сервис уже работает на пределе (например, 1000 rps на одном инстансе), деление может помочь, но сначала стоит оптимизировать код Go (профилирование pprof, улучшение аллокаций).
• Будущие планы. Если планируется внедрение gRPC, деление упростит контракты. Если же сервис - временный прототип, объединение ускорит разработку.

В итоге, в Go-проектах я рекомендую начинать с монолита или нескольких крупных сервисов, а делить только при явных проблемах с производительностью, командой или SLA.