Микросервисы

Ключевое свойство микросервисов — не размер, а независимость. Сервис считается отдельным, если его можно выкатить, не трогая остальные, если у него своя ответственность и своё хранилище данных. Отсюда и типичное деление: каталог, заказы, платежи, уведомления, поиск. Взаимодействуют они либо синхронно через HTTP или gRPC, либо асинхронно через брокер сообщений вроде Kafka или RabbitMQ, что надёжнее для событий и хуже для сценариев «нужно прямо сейчас и с ответом».

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

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

Смежные термины

• МонолитМонолит — приложение, которое собирается и разворачивается одним куском: весь код лежит в общем репозитории и выполняется в одном процессе, работает с одной базой и выкатывается целиком, что даёт простоту разработки ценой связанности.
• APIAPI — зафиксированный набор правил, по которым одна программа запрашивает данные или действия у другой: адреса методов, формат запроса и ответа, авторизация и лимиты, описанные так, чтобы обе стороны могли меняться независимо.
• CI/CDCI/CD — конвейер, который на каждый коммит автоматически собирает проект, прогоняет тесты и проверки, а затем выкладывает прошедшую сборку на тестовый стенд или в продакшн, убирая ручной деплой вместе с человеческим фактором.
• Технический долгТехнический долг — накопленная разница между тем, как система устроена, и тем, как она должна быть устроена: каждое упрощение ради срока превращается в постоянную надбавку к стоимости и срокам всех последующих задач.
• SLASLA — соглашение об уровне сервиса: в нём зафиксированы доступность системы в процентах, время реакции и время устранения по классам инцидентов, часы работы поддержки и компенсации на случай, если подрядчик эти показатели не выдержал.

Услуги по теме

• Разработка веб-приложений и Telegram Mini AppКогда сайта уже мало и нужен продукт: личный кабинет, дашборд, внутренний сервис или Mini App внутри Telegram. Проектируем архитектуру, пишем бэкенд и фронтенд, доводим до релиза.
• IT-консалтинг и продуктовый аудитСамые дорогие ошибки в разработке делаются до первой строчки кода: неверно понятая задача, стек, выбранный по привычке подрядчика, и ТЗ, которого нет. Консалтинг нужен, чтобы разобраться до того, как начнётся счётчик разработки: что именно строить, из чего, за сколько и в каком порядке. Результат — документ, а не мнение на созвоне.

Почитать подробнее

• Как выбрать стек технологий для проекта: критерии, а не модаСтек выбирают на 3–5 лет вперёд, а решают за один созвон. Разбираем, в каком порядке принимать решения, какие критерии реально имеют вес, какие стеки работают для шести типов проектов и сколько стоит ошибка.
• Редизайн сайта без потери трафика: этапы, риски и SEO-чеклист переездаПоловина запросов на редизайн — это на самом деле проблемы контента, скорости или оффера. Разбираем, как отличить одно от другого, почему поэтапный вывод безопаснее большого запуска и что должно быть в чеклисте переезда, чтобы не потерять органику.