Dimax GroupЦентр AI-трансформации
Разобрать задачу

Микросервисная архитектура и высоконагруженные системы: проектируем под вашу нагрузку

Микросервисы нужны не каждой системе, а высокая нагрузка не всегда требует их. Мы начинаем не с выбора технологий, а с замеров: где система упирается сейчас, какая нагрузка будет через год и какой простой вам действительно дорого стоит. После этого проектируем границы модулей, очереди и события, разделение данных и порядок перехода от старой системы к новой. Где хватит модульного монолита, так и скажем. Исходники лежат в вашем репозитории с первого коммита.

Разобрать задачу Как идёт работа

Обследование и замеры — от 200 000 ₽, 2–3 неделиСначала нагрузочная модель, потом схема сервисовПереход этапами: старая система работает, пока новая не принята

С чем приходят

Когда архитектуру пора менять, а когда достаточно настройки

Система тормозит в часы пик

Днём нормально, в пик отчёты и заказы идут минутами. Прежде чем делить систему на сервисы, нужно найти узкое место: часто это один запрос, одна блокировка или одна внешняя система, а не вся архитектура.

Одна ошибка роняет всё

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

Релиз раз в квартал и страшно

Команды мешают друг другу в одном репозитории, любая правка требует полной проверки. Это проблема границ модулей и процесса выпуска, и она решается не только микросервисами.

Унаследованная система, которую боятся трогать

Код писали разные люди, документации нет, тестов мало. Переписывать целиком дорого и рискованно, оставлять как есть нельзя. Нужен план постепенной замены.

Выбор подхода

Монолит, модульный монолит или микросервисы: что подходит при какой ситуации

Выбор записывается в обследовании с причинами. О том, как принимать это решение самостоятельно, написано в статье «Микросервисы или монолит».

Подход
Когда подходит
Что получаете
Что платите
ПодходНастроенный монолитузкое место найдено
Когда подходитОдна команда, одна база, нагрузка растёт умеренно, а тормозит конкретное место
Что получаетеИндексы, переписанные запросы, кэш, вынос тяжёлых операций в фоновые задачи, горизонтальное копирование приложения за балансировщиком
Что платитеПотолок остаётся: если рост продолжится, придётся возвращаться к архитектуре
ПодходМодульный монолитчёткие границы внутри одного приложения
Когда подходитОдна команда или две, домен крупный, нужен порядок в коде и подготовка к разделению
Что получаетеМодули с явными интерфейсами, запрет на прямое обращение к чужим таблицам, отдельные очереди для тяжёлых задач
Что платитеДисциплина границ: без проверок в сборке модули снова срастаются
ПодходНесколько сервисов по границамвыделяем только то, что требует отдельной жизни
Когда подходитРазные скорости изменений, разные требования к нагрузке и надёжности, несколько команд
Что получаетеНезависимые релизы и масштабирование выделенных частей, изоляция сбоев
Что платитеСеть вместо вызова функции, распределённые данные, трассировка, версии контрактов
Метод

Как мы проектируем границы сервисов

Границы проводятся по предметной области и по скорости изменений, а не по слоям приложения.

Начинаем с карты предметной области

Записываем, из каких деловых понятий состоит система: заказ, клиент, склад, платёж, документ. Для каждого понятия выясняем, кто его владелец, какие правила его меняют и кому нужны его данные. Модуль или сервис получается там, где у понятия есть собственный владелец и собственные правила. Если два «сервиса» постоянно меняются вместе и обращаются друг к другу на каждом шаге, это один сервис, разрезанный неудачно.

Три проверки перед тем, как выделять сервис

  • Данные. У сервиса должна быть собственная база или схема, и другие читают её только через его интерфейс. Если для ответа на один запрос нужно собирать данные из пяти сервисов, границы проведены неверно.
  • Скорость изменений. Часть, которую меняют каждую неделю, и часть, не менявшаяся полгода, выигрывают от раздельных релизов. Две части, которые меняются вместе, выигрывают от того, что остаются вместе.
  • Нагрузка и надёжность. Выделяется то, что требует другого масштаба или другого отношения к сбоям: приём событий от оборудования, формирование документов, отправка уведомлений.

Порядок выделения

Первым выделяют самое независимое: уведомления, формирование файлов, приём вебхуков. Ядро с заказами и деньгами трогают в последнюю очередь.

Нагрузка

От чего зависит нагрузка и как её оцениваем

Слово «высоконагруженная» без цифр ничего не значит, поэтому первым результатом работы становится нагрузочная модель.

Что измеряем
Что узнаём
Типичная находка
Чем проверяем
Что измеряемПрофиль запросовжурналы приложения и балансировщика
Что узнаёмКакие операции вызываются чаще всего, какие самые тяжёлые, как распределены по часам и дням
Типичная находкаТри-четыре операции дают почти всю нагрузку, остальное не важно
Чем проверяемНагрузочный сценарий строится по реальному профилю, а не по равномерному потоку
Что измеряемВремя ответа по операциямтрассировка или журнал медленных запросов
Что узнаёмГде тратится время: приложение, база, внешняя система, сеть
Типичная находкаОсновное время уходит на один запрос без индекса или на ожидание чужого сервиса
Чем проверяемПовторный замер после исправления на тех же данных
Что измеряемРост данных и пользователейпрогноз бизнеса и история системы
Что узнаёмЧто будет через год, если рост продолжится, и какой запас нужен на пиковые дни
Типичная находкаТаблица, которая растёт быстрее всех остальных, и отчёты, читающие её целиком
Чем проверяемИспытание на объёме данных, увеличенном до прогнозного
Что измеряемПоведение при перегрузкенагрузочные испытания на стенде
Что узнаёмДеградирует ли система плавно или падает; где первый предел: процессор, память, соединения с базой, очередь
Типичная находкаПредел задаёт пул соединений с базой или одна блокировка, а не процессор
Чем проверяемНагрузка растёт ступенями до отказа, фиксируется, что отказало первым
Что измеряемЗависимости от чужих системсхема обменов
Что узнаёмЧто останавливается, если недоступна 1С, платёжный провайдер или почтовый сервис
Типичная находкаПрямой синхронный вызов внешней системы стоит в середине основного сценария
Чем проверяемОтключаем зависимость на стенде и смотрим, что работает дальше
События

Очереди и события: когда они нужны и чем опасны

Event-driven подход не лечит медленную систему сам по себе, он решает конкретные задачи.

Очередь нужна там, где отправитель не должен ждать получателя: приём заказа не должен зависеть от того, доступна ли сегодня 1С. События нужны там, где одно изменение интересно многим: смена статуса заказа важна и клиенту, и складу, и аналитике. Всё остальное можно оставить обычными вызовами, и это проще.

Что нужно, чтобы очередь не создавала новых проблем

  • Повторы без дублей. Сообщение может прийти дважды, и обработчик должен давать тот же результат: у каждого события свой идентификатор, и обработанные запоминаются.
  • Недоставленное видно. Сообщения, которые не удалось обработать после нескольких попыток, попадают в отдельный список. Человек видит их и может повторить обработку.
  • Согласованность данных. Запись в базу и отправка события должны происходить вместе или не происходить вовсе. Для этого применяем «исходящий ящик»: событие записывается в ту же транзакцию, а отдельный процесс передаёт его в очередь.

Брокер выбирается по задаче. Для небольших потоков хватает очереди на PostgreSQL, для заметных нагрузок берём RabbitMQ, для потока событий с повторным чтением по журналу рассматриваем Kafka. Выбор записывается в обследовании вместе с тем, кто будет этим брокером управлять после сдачи.

Отказоустойчивость

Что делаем, чтобы сбой одной части не останавливал остальные

Тайм-ауты и повторы с паузой

Каждый вызов чужой системы имеет предел ожидания и ограниченное число повторов с нарастающей паузой. Иначе один медленный сервис занимает все соединения и останавливает остальных.

Деградация вместо падения

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

Копии и восстановление

Копия, из которой ни разу не восстанавливались, не считается. Проверка восстановления проводится на отдельном стенде, время восстановления измеряется и записывается.

Наблюдаемость

Журналы с общим идентификатором запроса, метрики по ключевым операциям и трассировка через сервисы. Без неё распределённую систему невозможно отлаживать.

Legacy

Рефакторинг legacy: стратегии замены и риск каждой

Старая система кормит бизнес, поэтому «остановить и переписать» почти никогда не годится. Состояние кода оцениваем на аудите кода и архитектуры.

Стратегия
Как идёт
Когда подходит
Главный риск
СтратегияДушитель (замена по частям)новый функционал рядом со старым
Как идётПеред старой системой ставится прослойка, и функции по одной переезжают в новые модули; старый код отключается, когда не остаётся вызовов
Когда подходитСистема большая, живая, переписать целиком нельзя
Главный рискДве системы работают одновременно, и данные нужно синхронизировать; без плана отключения старое живёт вечно
СтратегияВынос границ внутри монолитапорядок без смены платформы
Как идётВводятся модули и запреты на обходные обращения, добавляются тесты на текущее поведение
Когда подходитКод работает, но тяжело меняется; платформа ещё поддерживается
Главный рискБез тестов на текущее поведение рефакторинг ломает то, что работало
СтратегияПереписывание с нулякрайний случай
Как идётСистема небольшая, поведение описано, остановка допустима
Когда подходитСтарый код не поддаётся пониманию, а область узкая
Главный рискТеряются правила, которые никто не записал; сроки почти всегда растут
Что делаем

Из чего состоит работа и сколько она стоит

Цены совпадают с тарифами. Названа точная цена только у обследования, дальше вилка, которая сужается по его результатам. Остановиться можно после любой ступени.

Обследование: один контур

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

200 000 ₽ · 2–3 недели

Обследование: несколько систем

То же с картой обменов и матрицей источников данных, когда система окружена учётными и внешними сервисами.

350 000 ₽ · 3–4 недели

Пилот: один шаг архитектуры

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

150 000–400 000 ₽ · 2–8 недель

Пилот: несколько частей

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

400 000–1 200 000 ₽ · 2–3 месяца

Вывод в эксплуатацию

Поэтапный переход, опытная эксплуатация, нагрузочные испытания, регламент обновлений и восстановления, передача документации. Этапы с отдельной приёмкой.

от 1 500 000 ₽ этапами по 300 000–700 000 ₽ · от 3 месяцев

Сопровождение

Мониторинг, разбор инцидентов, плановые доработки с пакета на 60 000 ₽. Сверх пакета — 5 000 ₽ в час.

20 000 / 60 000 / 120 000 ₽ в месяц
Процесс

Как идёт работа

2–4 недели — Обследование и замеры

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

До разработки — Целевая схема и порядок перехода

Какие части выделяются и в каком порядке, что остаётся в монолите, как данные переезжают и как откатиться на каждом шаге.

Первый шаг — Пилот

Самое независимое: очередь, приём событий или один сервис. Проверяем развёртывание, наблюдаемость и поведение при отказе до того, как трогать ядро.

Этапами — Перенос и опытная эксплуатация

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

Дальше — Передача или сопровождение

Документация, схемы, регламенты, обучение вашей команды работе с развёрнутым. Либо сопровождение помесячно.

Цена

Что двигает цену внутри вилки

Число границ и связей между ними

Работа растёт не по числу сервисов, а по числу связей: каждая связь — контракт, версии, тесты и поведение при отказе.

Состояние данных

Если одну таблицу читают десять модулей напрямую, разделение данных превращается в отдельный проект. Это самая частая причина, по которой вилка уезжает вверх.

Требования к доступности

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

Контроль

Что остаётся у вас и чего мы не делаем

Остаётся у вас

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

Мы этого не делаем

  • Не дежурим круглосуточно и не подписываем договорённости о доступности и времени реакции вне пакетов сопровождения.
  • Не внедряем платформы на сотни сервисов и не строим платформенные команды: мы работаем над одним контуром или участком.
  • Не защищаем от распределённых атак на доступность и не предоставляем SIEM, WAF или IDS как услугу.
  • Не размещаем вашу систему у себя и не оказываем хостинг.
  • Не берём работы дешевле 150 000 ₽ и не проводим аттестацию; лицензии ФСТЭК у нас нет.
Граница

Когда вам нужна другая услуга

Если система уже работает и вы не уверены, что её стоит менять, начните с аудита кода и архитектуры: он даёт заключение без обязательств по разработке. Если нужно построить серверную часть с нуля, смотрите разработку API и бэкенда. Если вы делаете продукт для многих организаций, SaaS-платформа включает разделение данных клиентов и тарифы, а выбор схемы изоляции описан в статье про мультиарендность.

Если проблема в обмене с учётной системой, начинать нужно с интеграции с ERP. Слова о доступности в договоре разобраны в статье «Что означает доступность три девятки».

Инструменты

На чём собираем

Серверная часть и данные
  • Python (Django, FastAPI) или Go для сервисов с высокой нагрузкой
  • PostgreSQL, репликация для чтения, при необходимости секционирование таблиц
  • Redis или совместимое хранилище для кэша и блокировок
  • RabbitMQ или очередь на PostgreSQL; Kafka, если нужна журнальная модель событий
Развёртывание и наблюдение
  • Docker, Nginx или HAProxy, GitLab CI
  • Kubernetes только если у вас есть кому его эксплуатировать; иначе Docker Compose или systemd
  • Prometheus и Grafana для метрик, централизованные журналы
  • OpenTelemetry для трассировки, нагрузочные испытания на k6 или Locust
Материалы

Материалы по теме

Статья

Микросервисы или монолит: как выбрать

Критерии решения, цена распределённости, признаки того, что пора выделять сервис, и типичные ошибки.

  • Критерии выбора
  • Цена распределённости
  • Порядок выделения
Читать →
Статья

Что означает доступность «три девятки» и как её проверять

Сколько простоя допускает каждый уровень, что считать недоступностью и как измерять.

  • Простой в минутах
  • Что считается сбоем
  • Как проверять
Читать →
Статья

Проектирование API для интеграций

Версии, идемпотентность, ошибки и ограничение частоты: то, на чём держатся обмены между сервисами.

  • Версии и контракты
  • Повторы без дублей
  • Единый формат ошибок
Читать →
Заявка

Разберём, где система упирается и что менять первым

Сорок минут созвона: что за система, как ведёт себя в пик, какие у неё границы и где болит. По итогам скажем, нужны ли сервисы вообще, с какой ступени начинать и в какую вилку это укладывается.

Спасибо, заявка отправлена. Ответим в течение рабочего дня.

Не удалось отправить. Напишите в телеграм или позвоните.

Вопросы

Частые вопросы: микросервисы и высоконагруженные системы

Сколько стоит проектирование микросервисной архитектуры?

Начинается с обследования: 200 000 ₽ за один контур (2–3 недели), 350 000 ₽ за несколько систем, 500 000 ₽ за контур с оборудованием или жёсткими требованиями. На выходе нагрузочная модель, карта границ и вилка бюджета. Пилот одного шага стоит 150 000–400 000 ₽, вывод в эксплуатацию начинается от 1 500 000 ₽ этапами по 300 000–700 000 ₽. Обследование вычитается из первого этапа, если продолжаете с нами.

Нужны ли мне микросервисы?

Часто нет. Если одна команда, одна база и тормозит конкретное место, обычно достаточно настройки и фоновых задач. Если границы внутри системы размыты, сначала вводим модули внутри монолита. Отдельные сервисы выделяем там, где нужны независимые релизы, другой масштаб или изоляция сбоев. Вывод записываем в обследовании с причинами.

Как вы определяете, что система высоконагруженная?

Не по названию, а по замерам: профиль запросов, время ответа по операциям, рост данных, поведение при перегрузке. Испытания проводим на стенде с данными, похожими на боевые.

Можно ли переписать систему, не останавливая бизнес?

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

Гарантируете ли вы определённую доступность?

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

Где будет работать система и кому принадлежит код?

На вашем оборудовании или у выбранного вами хостера. Исходный код лежит в вашем репозитории с первого коммита. Результат работ передаётся вам по акту, порядок передачи прав записывается в договоре; открытые компоненты остаются под своими лицензиями. Персональные данные граждан России обычно должны храниться на серверах в России.

Возьмёте ли вы систему на сопровождение после перехода?

Да, помесячно: 20 000, 60 000 или 120 000 ₽ в месяц, до 4, 12 или 25 часов. Часы сверх пакета стоят 5 000 ₽ в час и согласуются до начала работ. Круглосуточного дежурства нет, об этом говорим до договора.

Вы работаете только в Ростове-на-Дону?

Мы в Ростове-на-Дону, работаем с заказчиками по всей России: удалённо и в вашем контуре. Доступ к системам и обследование согласуем на старте с вашей службой безопасности.

Смежное

Что посмотреть рядом