Microservices: Стоит ли проблемы?
16 августа 2025 г.Привет, я Stanislav Yablonskiy, ведущий разработчик сервера в Pixonic (my.games). И сегодня давайте обсудим микросервисы.
Микросервисы являются подходом к разработке программного обеспечения (в первую очередь разработки бэкэнд), где функциональность разбивается на наименьшие возможные компоненты, каждый из которых работает независимо. Каждый такой компонент имеет свой собственный API. Он может иметь свою собственную базу данных и может быть написан на своем собственном языке программирования. Они общаются по сети.
Микросервисы в настоящее время очень популярны, но их использование вносит значительные накладные расходы с точки зрения сети, памяти и процессора.
Каждый вызов превращается в необходимость сериализации, отправки и получения данных по сети. Кроме того, больше невозможно использовать классические транзакции базы данных, что приводит к распределенным транзакциям или возможной последовательности.
Распределенные транзакции являются медленными и дорогими, в то время как возможная согласованность означает, что результаты операций могут не появиться сразу, а данные могут быть временно непоследовательными.
Использование микросервисов заставляет разработчиков писать больше кода в каждой отдельной службе из -за трудностей доступа к уже написанной логике из других услуг. Иногда трудно повторно использовать существующий код, или вы можете даже не знать, что он существует - поскольку другие люди могут работать над другим проектом. Давайте поговорим больше о накладных расходах.
Накладные расходы микросервисов
Отладка накладных расходов
Отладка становится намного сложнее с микросервисами. Регулярный отладчик почти бесполезен в таких условиях, поскольку вы не можете отладить все услуги одновременно. Без правильно настроенной системы ведения журнала, трассировки и метрик отладка практически невозможна, пока проблема не будет локализована.
Это означает, что вам нужна специальная среда, в которой работает не только услуга, которая отлаживается, но и все его зависимости (другие услуги, базы данных, очереди и т. Д.).
HTTP накладные расходы
Протокол HTTP имеет много встроенных функций. Он поддерживает различные маршруты, методы передачи параметров, коды ответов и поддерживается многими готовыми к использованию услуг (включая прокси). Но это не легкий-он заставляет каждую службу реализовать много не очень эффективного кода для разбора и генерирования путей, заголовков и так далее.
Протобуф накладных расходов
Сериализация для сетевой коммуникации и пустыни при получении сообщений требуется.
При использовании ProtoBuf для обмена сообщениями вам нужно:
- Создать объекты,
- преобразовать их в байтовые массивы,
- и сразу же отбросьте их после использования.
Это создает много дополнительной работы для коллекционера мусора или динамического менеджера памяти.
Сетевые накладные расходы
Передача данных по сети увеличивает время отклика обслуживания. Он увеличивает потребление памяти и процессора, даже если микросервисы работают на одном хосте.
Память над головой
Отправка и получение сообщений требует поддержания дополнительных структур данных, с использованием отдельных потоков и их синхронизации. Каждый отдельный процесс, особенно один, работающий в контейнере, потребляет значительный объем памяти только существующим.
ЦП над головой
Естественно, вся эта межпроцессная и межконтравная связь требует вычислительных ресурсов.
База данных накладные расходы
Нормальные транзакции невозможны, когда операции охватывают несколько микросервисов. Распределенные транзакции намного медленнее и требуют сложной - часто ручной - координации. Это увеличивает временную стоимость как для разработки, так и для выполнения таких операций.
Сетевой диск накладные расходы
Контейнеры микросервиса часто запускаются на сетевых дисках. Это увеличивает задержку, снижает производительность (IOPS) и делает ее непредсказуемой.
Проект границ накладных расходов
Разработка и разработка микросервисов приводит к трудностям в развитии и рефактории проекта.
- Нелегко изменить зону ответственности услуги.
- Вы не можете просто переименовать или удалить что -то. Вы не можете просто перенести код из одного сервиса в другую.
Обычно это требует:
- много времени и усилий,
- Несколько версий API,
- и сложные миграции до функциональности могут быть перераспределены между услугами.
Кроме того, если вы хотите обновить или заменить библиотеку, вам нужно будет делать это по всем проектам, а не только с одним.
Инфраструктура накладные расходы
Вы не можете просто «делать микросервисы». Вам понадобится инфраструктура - нет, инфраструктура:
- контейнеры (каждая из которых содержит копии общих библиотек),
- Kubernetes,
- облачные сервисы,
- очереди (Rabbitmq, Kafka),
- Инструменты синхронизации конфигурации (Zookeeper и т. Д., Консул) и т. Д.
Все это требует огромных ресурсов как у машин, так и от людей.
Независимое развертывание накладных расходов
Поддержка независимых развертываний означает:
- Каждая услуга должна быть развернута отдельно,
- каждый должен иметь свой собственный трубопровод CI/CD,
- И самая сложная часть -API версииПолем
Каждая служба должна будет одновременно поддерживать несколько версий API. И абоненты должны будут отслеживать эти версии и обновлять свои вызовы во времени.
Распределенный мяч
Существует почти 100% шанс, что вы не получите границы своих услуг с самого начала. Вместо чистых микросервисов вы получите распределенный шарик грязи - где функциональность плохо распределена, внешние вызовы запускают целые цепочки внутренних вызовов обслуживания, и все это ужасно медленное.
Монолит действительно такой страшный?
Модульные монолиты
Модульные монолиты позволяют избежать большей части накладных расходов микросервиса - при этом при этом предоставляя разделение, которое можно использовать позже, если это необходимо.
Этот подход включает в себя написание приложения (в первую очередь бэкэнд) в виде единой службы, разделенной на отдельные модули с:
- четко определенные границы и
- Минимальные взаимозависимости.
Это позволяет разделить их на услуги, если масштабирование действительно требует этого.
Подожди, ты можешь это сделать?
Многие преимущества, приписываемые архитектуре микросервиса, могут быть достигнуты в монолите:
- Модульностьможет быть реализован с языковыми функциями: классы, пространства имен, проекты и сборки;
- Несколько баз данных- возможно, если по -настоящему необходимо;
- Несколько языков-также возможно, например, сочетание C/C ++/C#/Java с языками сценариев, такими как JavaScript, Python или Erlang для разработки более высокого уровня;
- Меж- Многие платформы поддерживают вызов C/C ++ из Java, C#, Python, JavaScript или Erlang;
- Очереди сообщения- Просто используйте соответствующую структуру данных.
И когда вы хотите отладить - одно ключ, и все приложение у вас под рукой.
Актерские фреймворки
Актерские фреймворки позволяют создавать микросервисы - без микросервисов.
Вся логика разделена на классы (актеров), которые общаются только через шину сообщения (очереди).
Эти актеры могут:
- существуют в пределах одного процесса, или
- распределять по нескольким процессам.
Таким образом, вы получаете модель программирования микросервиса, но большая часть инфраструктуры обрабатывается самой структурой.
Заключение
Архитектура должна быть выбрана на основе:
- Требования к проекту,
- доступные ресурсы,
- и командный опыт.
Микросервисы не серебряная пуля. Они полезны для огромных проектов и команд - но монолит не устарел и не является техническим долгом по умолчанию.
Больше всего важно баланс между гибкостью и сложностью, масштабируемостью и обслуживаемостью - так что система, которую вы строите, была эффективной и устойчивой.
Оригинал