Что такое микросервисы: простое объяснение для бизнеса и разработчиков

Микросервисы давно перестали быть экзотикой крупных IT-компаний. В исследовании O'Reilly «Microservices Adoption in 2020» около 77% из 1502 опрошенных организаций сообщили, что уже используют микросервисы. Но полностью или в основном успешным внедрение назвали лишь 55%, ещё 37% говорят о частичном успехе. Сам термин закрепился после статьи Мартина Фаулера и Джеймса Льюиса «Microservices» 2014 года, которую до сих пор считают базовым определением подхода.

Разрыв между «используем» и «довольны» — главное, что нужно знать о микросервисах. Мы в YuSMP Group каждый месяц обсуждаем архитектуру с заказчиками в рамках услуги по разработке веб-приложений. Часто к нам приходят с запросом «хотим микросервисы, как у Netflix», хотя продукту на этой стадии нужен аккуратный модульный монолит. Бывает и наоборот: система давно переросла один большой код, и команды мешают друг другу на каждом релизе.

В этой статье объясним без лишнего жаргона, что такое микросервисы и микросервисная архитектура, из чего она состоит, как сервисы общаются и хранят данные, какие технологии для этого нужны. Отдельно разберём плюсы, минусы, отличие от SOA и случаи, когда микросервисы вам не нужны.

Что такое микросервисы простыми словами

Микросервисы (микросервисная архитектура) — это подход, при котором приложение строится как набор небольших независимых сервисов. Каждый сервис решает одну бизнес-задачу, работает в своём процессе, хранит свои данные и общается с остальными через чётко описанный API. Фаулер и Льюис формулируют это так: подход к разработке одного приложения как набора небольших сервисов, каждый из которых работает в собственном процессе и общается лёгкими механизмами, чаще всего через HTTP API.

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

Теперь перенесём это на интернет-магазин. В микросервисной архитектуре у него могут быть отдельные сервисы:

• каталог — товары, цены, характеристики, поиск;
• корзина — что пользователь собирается купить;
• заказы — оформление и статусы заказа;
• оплата — работа с платёжным шлюзом и возвратами;
• доставка — расчёт стоимости, интеграция со службами доставки;
• уведомления — письма, SMS и push-сообщения.

Каждый из них можно разрабатывать, тестировать, выкатывать и масштабировать отдельно. В распродажу нагрузка растёт на каталог и корзину — добавляем экземпляры только этих сервисов. Упал сервис уведомлений — заказы всё равно оформляются, письма уйдут, когда он поднимется.

Что такое «микросервис» — один сервис

Микросервис — это одна самостоятельная программа внутри большой системы. У хорошего микросервиса пять признаков:

• одна бизнес-возможность — он отвечает, например, только за оплату, а не за «всё понемногу»;
• свой процесс — запускается и падает отдельно от других сервисов;
• своё хранилище — данные сервиса не читает и не пишет никто, кроме него самого;
• свой API — остальные части системы общаются с ним только через публичный контракт;
• отдельный деплой — новую версию можно выкатить, не пересобирая всё приложение.

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

Откуда взялся подход

Идея разбивать систему на независимые части не нова, но слово «микросервисы» закрепилось в 2011–2014 годах. В 2014 году Фаулер и Льюис описали подход и его девять характеристик — от организации вокруг бизнес-возможностей до проектирования под отказ. Пионерами называют Netflix, который после крупного сбоя базы данных в 2008 году перенёс платформу в облако AWS и разделил её на сотни сервисов, и Amazon.

В Amazon подход был связан не только с технологиями, но и с устройством команд. Известное «правило двух пицц» Джеффа Безоса гласит: команда должна быть такой, чтобы её можно было накормить двумя пиццами, то есть примерно до 8–10 человек. Маленькой команде нужен свой небольшой продукт с понятными границами — и микросервис оказался удобной формой такого продукта.

Чем микросервисы отличаются от монолита

Монолит — это приложение, в котором весь код собран в одну программу с общей базой данных и единым процессом выпуска. Микросервисы делят ту же функциональность на независимые сервисы. Коротко различия выглядят так:

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

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

Как устроена микросервисная архитектура

Микросервисная архитектура — это не только сами сервисы, но и инфраструктура вокруг них: входная точка, механизм поиска сервисов, каналы обмена сообщениями и система наблюдения. Без этих компонентов набор сервисов быстро превращается в хаос. Типичная схема включает:

• клиентов — веб-приложение, мобильное приложение, внешние партнёры;
• API Gateway — единую точку входа для всех запросов;
• бизнес-сервисы — каталог, заказы, оплата и другие;
• базы данных сервисов — у каждого своя;
• брокер сообщений — для асинхронного обмена событиями;
• service discovery и балансировку — чтобы сервисы находили друг друга;
• наблюдаемость — логи, метрики и трассировку.

Как это работает вместе, видно на примере одного заказа в интернет-магазине:

1. Клиент отправляет запрос «оформить заказ» на API Gateway.
2. Gateway проверяет токен пользователя и передаёт запрос сервису заказов.
3. Сервис заказов синхронно спрашивает у сервиса каталога актуальные цены и сохраняет заказ в своей базе.
4. Сервис заказов публикует в брокер сообщений событие «Заказ создан».
5. Сервисы оплаты, склада и уведомлений получают событие и каждый делает свою часть работы: списывает деньги, резервирует товар, отправляет письмо.

API Gateway — единая точка входа

API Gateway — это сервис-посредник, через который проходят все внешние запросы к системе. Он маршрутизирует запросы к нужным сервисам, проверяет авторизацию, ограничивает частоту запросов, собирает ответ из нескольких сервисов в один. Клиенту не нужно знать адреса десятков сервисов — он работает с одним адресом. Подробнее об устройстве шлюза и популярных решениях — в статье «Что такое API Gateway и зачем он нужен».

Service discovery и балансировка

Service discovery (обнаружение сервисов) — механизм, который позволяет сервисам находить друг друга, не зная заранее IP-адресов. Экземпляры сервисов постоянно создаются и удаляются: при масштабировании, обновлении, сбое. Реестр сервисов вроде Consul или встроенный DNS Kubernetes хранит актуальный список живых экземпляров, а балансировщик распределяет между ними запросы.

Брокер сообщений

Брокер сообщений — это посредник, через который сервисы обмениваются событиями и задачами, не вызывая друг друга напрямую. Сервис публикует сообщение, а брокер доставляет его всем подписчикам, даже если кто-то из них сейчас недоступен. Самые распространённые брокеры — Apache Kafka (поток событий с хранением истории) и RabbitMQ (классические очереди с гибкой маршрутизацией).

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

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

• логи — централизованно собранные записи всех сервисов с общим идентификатором запроса;
• метрики — задержки, число ошибок, нагрузка; обычно Prometheus и дашборды в Grafana;
• распределённая трассировка — путь каждого запроса через все сервисы; стандарт OpenTelemetry, визуализация в Jaeger.

Как микросервисы общаются между собой

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

Синхронно: REST и gRPC

Синхронное взаимодействие — это прямой запрос «вопрос — ответ». Сервис заказов спрашивает у каталога цену и ждёт ответа, прежде чем продолжить. Чаще всего для этого используют REST поверх HTTP с данными в JSON: он прост, понятен и поддерживается любым языком. Для внутреннего трафика между сервисами всё чаще выбирают gRPC: он работает поверх HTTP/2, передаёт данные в компактном бинарном формате Protocol Buffers и строго типизирует контракты. Какой протокол когда выгоднее, разбираем в статье «gRPC vs REST: что выбрать».

Минус синхронной связи — зависимость по доступности. Если каталог отвечает медленно, тормозит и сервис заказов. Поэтому для таких вызовов ставят таймауты, повторные попытки и circuit breaker — «предохранитель», который временно перестаёт отправлять запросы в сломанный сервис и не даёт сбою расползтись по системе.

Асинхронно: события и очереди

Асинхронное взаимодействие строится на событиях: сервис сообщает «что-то произошло» и не ждёт, кто и как на это отреагирует. Такой стиль называют событийно-ориентированной архитектурой (event-driven). Сервис заказов публикует «Заказ создан», а оплата, склад и уведомления реагируют сами. Добавить новый сервис, например аналитику, можно без изменений в сервисе заказов — достаточно подписать его на то же событие.

Асинхронность делает систему устойчивее: если сервис уведомлений упал, сообщения подождут в брокере. Цена — усложнение: данные становятся согласованными не мгновенно, а через какое-то время (eventual consistency), а отладку цепочки событий без трассировки вести трудно.

Оркестрация и хореография

Когда бизнес-процесс затрагивает несколько сервисов, нужно решить, кто им управляет. Есть два подхода:

Оркестрация	Хореография
Есть центральный сервис-оркестратор, который по шагам вызывает остальные	Центра нет: каждый сервис реагирует на события и публикует свои
Процесс легко прочитать и отследить в одном месте	Логику процесса приходится собирать по нескольким сервисам
Оркестратор становится точкой связности и потенциальным узким местом	Сервисы слабо связаны, новые участники добавляются без правок
Подходит для сложных процессов с множеством условий	Подходит для простых цепочек и широкого оповещения

Как микросервисы хранят данные

В микросервисной архитектуре действует принцип «база данных на сервис» (database per service): каждый сервис владеет своими данными, и никто другой не обращается к ним напрямую — только через API сервиса. Это один из самых важных и самых неудобных принципов подхода.

Почему нельзя просто оставить одну общую базу? Потому что общая база связывает сервисы крепче любого кода. Команда каталога переименовала колонку — и сломались заказы, о которых она даже не знала. Выкатить сервисы независимо уже не получится, а значит, пропадает главное преимущество микросервисов. Отдельная база к тому же позволяет выбрать подходящее хранилище: PostgreSQL для заказов, Elasticsearch для поиска по каталогу, Redis для корзины.

Распределённые транзакции и паттерн Saga

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

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

CQRS и Event Sourcing

CQRS (Command Query Responsibility Segregation) — разделение модели записи и модели чтения. Сервис пишет данные в одном виде, а для быстрых запросов и отчётов строит отдельные представления, которые обновляются по событиям. Event Sourcing идёт дальше: вместо текущего состояния хранится вся история событий, из которой состояние можно восстановить на любой момент. Оба паттерна мощные, но заметно усложняют систему, поэтому применяются точечно. Каталог паттернов с подробными описаниями ведёт Крис Ричардсон на microservices.io.

Какие принципы лежат в основе микросервисов

Принципы микросервисов — это набор правил, которые отличают настоящую микросервисную архитектуру от просто «много мелких программ». Опираясь на характеристики из статьи Фаулера и Льюиса, выделим главные:

1. Организация вокруг бизнес-возможностей. Сервисы нарезают не по техническим слоям («фронтенд», «база»), а по частям бизнеса. Для этого используют предметно-ориентированное проектирование (DDD) и понятие ограниченного контекста (bounded context) — области, внутри которой термины и правила однозначны.
2. Одна ответственность. Сервис делает одно дело и делает его хорошо. Если для описания сервиса нужно слово «и», стоит задуматься о границах.
3. Независимый деплой. Любой сервис можно выкатить, не согласовывая релиз с другими командами. Если выкатить можно только всё сразу, это не микросервисы.
4. Децентрализованные данные. У каждого сервиса своё хранилище, обмен данными — только через API и события.
5. Умные сервисы, «глупые» каналы. Бизнес-логика живёт внутри сервисов, а транспорт — HTTP или брокер — просто доставляет сообщения, ничего не решая за сервисы.
6. Автоматизация инфраструктуры. Сборка, тесты, деплой и откат выполняются автоматически. При десятках сервисов ручные релизы невозможны.
7. Проектирование под отказ. Сеть и соседние сервисы когда-нибудь откажут, поэтому каждый сервис должен уметь переживать их недоступность: таймауты, повторы, circuit breaker, резервные сценарии.
8. Эволюционный дизайн. Архитектуру не проектируют раз и навсегда: сервисы выделяют, объединяют и заменяют по мере того, как меняется бизнес.

Отдельно стоит сказать о командах. Закон Конвея гласит, что структура системы повторяет структуру коммуникаций в организации, которая её создаёт. Поэтому микросервисы работают, когда под каждый сервис или группу сервисов есть команда, которая владеет им целиком: от кода до продакшена. В опросе O'Reilly организации, где команды владеют полным жизненным циклом сервиса, чаще сообщали об успехе внедрения, чем те, где разработка и эксплуатация разделены.

Какие технологии нужны для микросервисов

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

Задача	Инструменты
Контейнеризация	Docker, Podman
Оркестрация	Kubernetes, в том числе управляемый в облаке
CI/CD	GitLab CI, GitHub Actions, Argo CD
Брокеры сообщений	Apache Kafka, RabbitMQ, NATS
API Gateway	Kong, NGINX, Envoy
Service mesh	Istio, Linkerd
Мониторинг и трассировка	Prometheus, Grafana, OpenTelemetry, Jaeger
Языки и фреймворки	Go, Java (Spring Boot), Node.js, Python (FastAPI), .NET

Контейнеры — фактический стандарт упаковки микросервисов: сервис вместе со всеми зависимостями запускается одинаково на ноутбуке разработчика, в тестовой среде и в продакшене. В том же опросе O'Reilly использование контейнеров было связано с более успешным внедрением микросервисов. Когда сервисов становится много, их запуском, перезапуском и масштабированием управляет оркестратор, чаще всего Kubernetes. Как устроены эти инструменты, мы подробно разбирали в статье «Контейнеризация и оркестрация: Docker, Kubernetes».

Инфраструктура для микросервисов — отдельная экспертиза, и именно на ней чаще всего спотыкаются команды без опыта. Если своих сил не хватает, закажите DevOps-сопровождение: настройку CI/CD и Kubernetes — пайплайны, кластер, мониторинг и алерты стоит поставить до того, как сервисов станет двадцать.

Преимущества микросервисной архитектуры

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

• Независимые релизы и быстрый time-to-market. Команда оплаты выпускает новый способ платежа, не дожидаясь, пока другие закончат свои задачи. Релизы идут часто и небольшими порциями, а значит, с меньшим риском.
• Точечное масштабирование. Под нагрузкой масштабируют только те сервисы, которым тяжело. Это экономнее, чем копировать весь монолит ради одного горячего модуля.
• Изоляция отказов. Ошибка в сервисе рекомендаций не должна мешать оформлению заказа. При правильном проектировании система работает с частичной деградацией, а не падает целиком.
• Свобода технологий. Для поиска можно взять одну базу, для аналитики — другую, для тяжёлых вычислений — более быстрый язык. Выбор делается под задачу сервиса, а не под всю систему.
• Параллельная работа команд. Несколько команд развивают свои сервисы, не конфликтуя в общем коде и не блокируя друг друга на слияниях.
• Проще заменять части. Устаревший сервис можно переписать целиком, сохранив его API, и остальная система этого даже не заметит.

Недостатки и подводные камни микросервисов

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

• Сложность распределённой системы. Сервисов, связей, конфигураций и точек отказа становится в разы больше. Нужно думать о версиях API, совместимости и порядке выкатки.
• Сетевые задержки. Каждый вызов между сервисами — это сеть, сериализация и возможный таймаут. Длинная цепочка синхронных вызовов заметно замедляет ответ пользователю.
• Согласованность данных. Без общей базы нет простых транзакций. Приходится проектировать саги, компенсации и принимать отложенную согласованность.
• Дорогая инфраструктура и DevOps. Оркестрация, мониторинг, трассировка, CI/CD для каждого сервиса стоят денег и требуют специалистов.
• Сложная отладка и тестирование. Воспроизвести ошибку, которая возникает на стыке пяти сервисов, намного труднее, чем в монолите. Нужны контрактные и интеграционные тесты.
• Риск «распределённого монолита». Если сервисы делят базу, вызывают друг друга по цепочке и выкатываются только вместе, вы получаете все минусы микросервисов без их плюсов. Это самый частый антипаттерн.
• Накладные расходы для маленькой команды. Пять разработчиков, которые обслуживают двадцать сервисов, тратят больше времени на инфраструктуру, чем на продукт.

Кейс Prime Video. Команда Prime Video из Amazon построила сервис мониторинга качества видео и звука на распределённых компонентах: AWS Step Functions, Lambda и S3 для передачи данных между этапами. При росте нагрузки такая схема упёрлась в стоимость оркестрации и передачи данных. Команда объединила компоненты в один процесс и, по данным самой команды (разбор кейса), снизила затраты на инфраструктуру этого сервиса на 90%. Речь об одном сервисе мониторинга, а не обо всём Prime Video, но вывод общий: архитектура должна соответствовать нагрузке, а не моде.

Когда микросервисы нужны, а когда нет

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

Микросервисы подходят, если:

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

Микросервисы не подходят, если:

• вы делаете стартап или MVP и ещё проверяете гипотезы — границы сервисов будут постоянно меняться;
• в команде меньше 8–10 разработчиков;
• предметная область пока неясна, и вы не знаете, где проходят естественные границы;
• нет бюджета и людей на инфраструктуру, мониторинг и автоматизацию;
• нагрузка небольшая и равномерная, а монолит с ней спокойно справляется.

В этих случаях разумная альтернатива — модульный монолит: одно приложение, но с чётко разделёнными модулями и границами между ними. Когда какой-то модуль действительно потребует отдельной жизни, его можно аккуратно вынести в сервис. Для систем, которые уже переросли свой монолит, мы выделяем сервисы постепенно, по одному, — это часть работы с унаследованным кодом.

Чем микросервисы отличаются от SOA

SOA (сервис-ориентированная архитектура) — предшественник микросервисов: она тоже делит систему на сервисы, но делает это крупнее и с центральной шиной, через которую идёт весь обмен. Микросервисы часто называют «SOA, сделанной правильно», и различия в основном касаются масштаба и степени децентрализации:

Параметр	SOA	Микросервисы
Размер сервисов	Крупные, часто на уровне целых корпоративных систем	Небольшие, по одной бизнес-возможности
Связь	Корпоративная шина ESB с логикой маршрутизации и преобразований	Лёгкие протоколы: HTTP/REST, gRPC, брокеры; «глупые» каналы
Данные	Часто общие хранилища на несколько сервисов	Своя база у каждого сервиса
Управление	Централизованные стандарты и общий стек	Децентрализованное, команды выбирают инструменты
Деплой	Нередко связанными релизами	Независимый для каждого сервиса

Примеры компаний, которые используют микросервисы

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

• Netflix. После сбоя базы данных в 2008 году компания перенесла платформу в AWS и разделила её на сотни сервисов. Netflix известен своими инструментами надёжности, в первую очередь Chaos Monkey, который намеренно отключает сервисы в продакшене, чтобы проверить устойчивость системы.
• Amazon. Ещё в начале 2000-х компания перешла к небольшим командам по «правилу двух пицц» и к правилу, по которому команды общаются между собой только через сервисные интерфейсы.
• Uber. Начинал с монолита и по мере роста разделил систему на большое число сервисов: поездки, расчёт стоимости, оплата, геолокация.
• Spotify. Известен организационной моделью с небольшими автономными командами (squads), каждая из которых отвечает за свою часть продукта.
• Российские компании. Крупные продукты вроде Яндекс Go, Ozon и Авито публично рассказывают на конференциях и в технических блогах о том, как развивают микросервисные платформы с большим числом команд.

Обратный пример — уже упомянутый сервис мониторинга Prime Video, где отказ от распределённой схемы в пользу одного процесса снизил расходы. Оба типа историй важны: микросервисы — инструмент под определённый масштаб, а не обязательный атрибут современной разработки.

FAQ — частые вопросы о микросервисах

Что такое микросервис простыми словами?

Микросервис — это небольшая самостоятельная программа, которая отвечает за одну бизнес-задачу: например, только за корзину или только за оплату. У неё свой код, своя база данных и свой API, её можно обновить и перезапустить отдельно от остальных частей приложения. Приложение из таких программ и называют микросервисным.

Чем микросервисы отличаются от монолита?

Монолит — это одно приложение с общей кодовой базой, общей базой данных и единым релизом. Микросервисы делят систему на независимые сервисы, каждый со своими данными и своим циклом выпуска. Монолит проще и дешевле на старте, микросервисы удобнее для крупных продуктов и нескольких команд, но требуют зрелой инфраструктуры.

Сколько должно быть микросервисов в приложении?

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

Обязательно ли нужен Kubernetes для микросервисов?

Нет. Несколько сервисов можно запускать в Docker Compose, на обычных виртуальных машинах или в serverless-функциях. Kubernetes становится оправданным, когда сервисов много, нужны автомасштабирование, самовосстановление и единые правила выкатки. До этого момента он часто добавляет больше работы, чем снимает.

Можно ли писать микросервисы на разных языках?

Да, это одно из преимуществ подхода: сервисы общаются по сети через API или сообщения, поэтому один можно написать на Go, другой на Java, третий на Python. На практике команды ограничивают набор двумя-тремя языками, иначе растут расходы на поддержку, найм и общие библиотеки.

Когда стоит переходить с монолита на микросервисы?

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

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