Микросервисы
нужны ли
они всем
Микросервисы — популярная архитектура, но не лекарство от всего. Разбираем, что это, какие плюсы и минусы показала практика Shopify, Segment и Prime Video и как понять, нужны ли они вашему магазину или B2B-порталу.
Коротко
- Микросервисы — стиль, при котором приложение собрано из небольших сервисов: каждый работает в своём процессе, отвечает за свою бизнес-функцию и разворачивается независимо [1].
- У них есть цена: распределённая система, согласованность данных, развёртывание и мониторинг многих сервисов. Мартин Фаулер называет её «премией за микросервисы» [1][2].
- Окупается она, когда система слишком велика и сложна для одного приложения: большие команды, независимо развивающиеся функции, разная нагрузка на части системы [2].
- Большинство успешных микросервисных систем начиналось с монолита, который вырос, а не с микросервисов с нуля [3]. Сэм Ньюман, автор книги о микросервисах, говорит, что они не должны быть выбором по умолчанию [8].
- Для большинства интернет-магазинов и B2B-порталов достаточно хорошо структурированного монолита. Важнее другое: чтобы платформа была готова к переходу, когда он понадобится.
Это обзор опубликованных инженерных материалов и нашего опыта, а не универсальное правило. Для вашего проекта решение зависит от нагрузки, команды и планов роста.
Три способа собрать систему
Монолит
Одно приложение: один код, одно развёртывание, одна база. Просто запускать, тестировать и менять, пока проект небольшой. Со временем части системы начинают мешать друг другу.
Микросервисы
Набор небольших независимых сервисов по бизнес-функциям: каталог, корзина, поиск, обмен с 1С. Каждый можно развернуть, масштабировать и обновлять отдельно, у каждого может быть свой стек и хранилище [1]. Взамен — цена распределённой системы.
Модульный монолит с поддержкой микросервисов
Одно приложение с модулями по бизнес-функциям: у каждого чёткий интерфейс и свои данные. Просто запускать и менять, как монолит, а когда нагрузка или команда вырастут, нужный модуль выносится в самостоятельный сервис без переписывания всего проекта [3][5]. Так устроена AXIOMA: платформа собирается из модулей под проект, а её архитектура поддерживает микросервисы.
Плюсы микросервисов
Масштабирование по частям
Если поиск или обмен с учётной системой нагружены сильнее остальных, масштабируют только их, а не всё приложение целиком [2].
Независимые релизы
Сервис разворачивают отдельно: правка корзины не требует выпускать весь сайт. Это снимает очередь на общий релиз, когда команд несколько [1].
Изоляция отказов
Сбой одного сервиса не обязан останавливать остальные. У Segment именно это стало причиной выбрать микросервисы: медленный партнёр больше не задерживал всех [4].
Свобода технологий
Для каждого сервиса можно выбрать подходящие язык и хранилище, а команды могут развивать свои части независимо [1].
Минусы: цена микросервисов
Распределённая система
Вызов по сети дороже вызова внутри процесса, а сбои сети и сервисов становятся обычным делом, их нужно предусматривать [1].
Согласованность данных
Распределённые транзакции сложны, поэтому данные согласуются «в конечном счёте», а ошибки исправляют компенсирующими операциями [1].
Эксплуатация
Нужны автоматическое развёртывание, мониторинг и разбор сбоев на многих сервисах. Без этого команда замедляется [1][2].
Рост числа сервисов
У Segment каждый новый партнёр добавлял сервис и очередь, их стало больше 140. Общие библиотеки разошлись по версиям, а правка общего кода превращалась в развёртывание десятков сервисов [4].
Границы трудно угадать
Хорошие и устойчивые границы между сервисами сложно провести в начале, а переносить функции между сервисами труднее, чем внутри одного приложения [3].
Нужны навыки команды
Результат сильно зависит от опыта: сложность не исчезает, а может переехать в менее заметные связи между сервисами [1].
Что показала практика
- Segment (2018): обратно к одному сервису. Микросервисы появились не зря: у каждого партнёрского направления был свой сервис и очередь, и медленный партнёр не тормозил остальных. Но по мере роста до 140+ сервисов три инженера почти всё время поддерживали систему, а изменения в общих библиотеках стали дорогими. Команда собрала код в один сервис и один репозиторий: развёртывание заняло минуты. Цена: слабее изоляция отказов, один сбой может затронуть всех [4].
- Shopify (2019): модульный монолит. Кодовая база, выросшая за десять лет и написанная более чем тысячей разработчиков, стала слишком связанной: правка расчёта налогов могла сломать расчёт доставки. Вместо микросервисов команда оставила один код и одно развёртывание, но выстроила в нём компоненты по бизнес-доменам: у каждого свой публичный интерфейс и свои данные. Это дало возможность заменить налоговый движок, что раньше было почти невозможно [5].
- Prime Video (2023): когда сервисы мешают одной задаче. Команда сообщила, что при переходе сервиса мониторинга качества видео с распределённой схемы на единое приложение затраты на инфраструктуру упали больше чем на 90%. Это относится к одному сервису и особенностям его нагрузки, а не ко всему Prime Video [7].
Вывод не в том, что микросервисы плохие. Они дают результат, когда решают реальную проблему и когда команда умеет с ними работать; без этого сложность съедает выгоду.
Когда нужны микросервисы, а когда достаточно монолита
Микросервисы стоит рассмотреть, если
- монолит стал настолько большим, что его трудно менять и разворачивать [2];
- части системы нагружены очень по-разному, например поиск и каталог в пики распродаж;
- несколько команд мешают друг другу общим релизом [2];
- функции развиваются в разном темпе и им нужна независимая жизнь;
- есть автоматизированное развёртывание, мониторинг и команда с опытом [1].
Лучше остаться на монолите, если
- это один магазин или портал, команда небольшая, нагрузка предсказуема;
- продукт ещё ищет свою модель, и границы модулей неясны [3];
- нет автоматического развёртывания и мониторинга [2];
- главная причина «так принято»: микросервисы не должны быть выбором по умолчанию [8];
- проблемы лежат в медленном коде или базе, а не в архитектуре: их решает оптимизация.
Как переходить безопасно
Начать с хорошего монолита
Один код, но с модулями по бизнес-доменам и чёткими интерфейсами. Так границы проверяются на практике, пока их ещё дёшево менять [3][5].
Выносить по одному сервису
Брать ту часть, где есть реальная боль: нагрузка, частые независимые релизы, отдельная команда. Остальное оставлять в ядре [3].
Не переписывать с нуля
Шаблон «душитель» (strangler): новые компоненты растут рядом со старой системой и постепенно забирают на себя её функции, пока старую можно не отключить. Каждый шаг уже приносит пользу [6].
одна база
Монолит
Один код и одно развёртывание: просто запускать и менять.
Модули с границами
Чёткие интерфейсы и свои данные у каждого модуля. Для многих проектов можно остановиться здесь.
Первый сервис
Выносим модуль, где есть реальная боль: нагрузка или отдельная команда.
Ядро и сервисы
Сервисов ровно столько, сколько оправдано нагрузкой и командой.
На каждом шаге получается рабочая версия, продажи не останавливаются. Переход не обязателен: шаги 1–2 подходят большинству магазинов и порталов.
Наш подход и AXIOMA
- Мы не навязываем микросервисы. Начинаем с задачи: нагрузка, команда, планы роста. Если хватает хорошо структурированного монолита, мы не усложняем архитектуру.
- AXIOMA ECOM и AXIOMA B2B построены так, что архитектура поддерживает микросервисы: платформа готова к микросервисному внедрению, когда оно действительно нужно. Витрину, поиск, корзину и другие модули можно выносить в самостоятельные сервисы по мере роста нагрузки и команды, без переписывания всего проекта.
- Для существующих проектов делаем это постепенно: выносим модули из монолита по шаблону «душитель», без остановки продаж. Подробнее о том, как мы разрабатываем highload-проекты, — на странице «Разработка и интеграция».
Нужны ли микросервисы вам: восемь вопросов
- Есть ли у вас части системы, которые нагружены заметно сильнее остальных?
- Мешают ли общие релизы нескольким командам?
- Сколько времени занимает выпуск небольшой правки: часы или недели?
- Есть ли автоматическое развёртывание и мониторинг? Сможете ли вы разобраться в сбое среди десятка сервисов?
- Понятны ли границы бизнес-функций: что можно выделить, не разрывая данные?
- Может ли помочь оптимизация кода, кэша и базы вместо смены архитектуры?
- Есть ли в команде опыт распределённых систем или вы готовы его нанять?
- Какую проблему решает переход, и как вы поймёте, что она решена?
Если на большинство вопросов ответ «нет» или «не знаем», начните с аудита и модульного монолита. Если «да» — разберём, какие части выносить первыми.
Справка
Что такое микросервисы
Микросервисы — архитектурный стиль, при котором приложение строят как набор небольших сервисов. Каждый работает в своём процессе, общается с остальными лёгкими средствами (чаще всего через HTTP API), организован вокруг бизнес-функции и разворачивается независимо от других [1]. Противоположный подход — монолит: одно приложение с общим кодом и общим развёртыванием.
Кто такой Martin Fowler
Главный научный сотрудник (Chief Scientist) компании ThoughtWorks, работает в ней с 2000 года. Автор книги «Refactoring» (1999) и один из соавторов Манифеста гибкой разработки (2001). Статья «Microservices», написанная им вместе с Джеймсом Льюисом в 2014 году, — одна из самых цитируемых работ по теме, на неё ссылаются как на определение термина [9].
Откуда факты
- James Lewis, Martin Fowler — Microservices (martinfowler.com), 2014 ↗
- Martin Fowler — Microservice Premium, 2015 ↗
- Martin Fowler — Monolith First, 2015 ↗
- Segment Engineering — Goodbye Microservices: From 100s of problem children to 1 superstar, 2018 ↗
- Shopify Engineering — Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity, 2019 ↗
- Martin Fowler — Strangler Fig Application ↗
- DevClass — Reduce costs by 90% by moving from microservices to monolith: Amazon internal case study (пересказ материала Prime Video Tech, 2023) ↗
- The Register — Microservices guru says they should be a last resort (QCon London, Sam Newman), 2020 ↗
- ThoughtWorks — Martin Fowler, профиль (должность, книги, Манифест гибкой разработки) ↗
Частые вопросы
-
Нет. Для большинства магазинов и B2B-порталов хватает хорошо структурированного монолита: микросервисы добавляют сложность и окупаются, когда система слишком велика или нагружена для одного приложения.
-
Обычно монолит с хорошими модулями. Мартин Фаулер отмечает, что почти все успешные микросервисные системы начинались с монолита, который вырос, а не с микросервисов с нуля.
-
Да, если архитектура изначально модульная: сервисы выносят постепенно, по шаблону «душитель», без остановки продаж. Платформа AXIOMA готова к такому переходу.
-
Сами по себе нет: вызовы по сети дороже вызовов внутри приложения. Они помогают масштабировать нагруженные части отдельно. Если сайт медленный из-за кода, кэша или базы, начните с оптимизации.
-
Одно приложение, разделённое на модули по бизнес-функциям: у каждого чёткий интерфейс и свои данные. Один код и одно развёртывание, но без хаоса зависимостей. Именно так поступил Shopify.
