Разработчики социальной сети "ВКонтакте" отказались от применения в коде микросервисов, отдав предпочтение монолитной архитектуре. Команда разработчиков считает, что микросервисы сложны в обслуживании и настройке. В то же время другие веб-архитекторы отмечают более стабильную работу решений, использующих микросервисы. 
Денис
Тельманов
© ComNews
25.09.2023

О различиях между монолитным кодом и модульной структурой с микросервисами говорили участники панельной дискуссии на технологической конференции SmartDev 2023 для разработчиков, инженеров, аналитиков и других представителей техносообщества. Микросервисы - вариант сервис-ориентированной архитектуры ПО, который обеспечивает взаимодействие независимых друг от друга небольших, слабо связанных и легко изменяемых модулей. Монолитная архитектура представляет собой единый модуль, работающий автономно, независимо от других приложений.

"У нас в компании принято микросервисы не обсуждать - аппетит портится. Я из VK, и весь бэкенд "ВКонтакте" - это один гигантский монолит. Пока я работаю во "ВКонтакте", микросервисов не будет", - сказал Александр Кирсанов, руководитель команды KPHP VK. KPHP (KittenPHP) - это транслятор PHP-кода в C++, который разработала VK.

По словам Александра Кирсанова, многие разработчики считают, что микросервисы обязательны для применения, поскольку позволяют создавать решения на разных языках программирования, запускать их на разных серверах и автономно осуществлять поддержку.

"Почему-то они думают, что микросервисы - это панацея, которая решит все накопившиеся проблемы. Но те, кто считает, что проблемы можно решить с помощью микросервисов, неправы. Они не смотрят на другую сторону. Микросервисы, если их неправильно использовать - а большинство именно так и делают, - создают больше проблем, чем решают. Это и лишняя нагрузка на сети и базу данных, и необходимость отладки ПО, мониторинга трафика, deploy (развертывание приложения и запуск в рабочей среде). В общем, микросервисы - это сложно", - считает руководитель команды KPHP "ВКонтакте".

Он сравнил использование микросервисов с перекредитованием. "Решать проблемы с помощью микросервисов - это примерно как брать кредит у одного банка, чтобы отдать долг другому банку. А еще же это надо и поддерживать, и администрировать. А чем проще администрировать систему, тем лучше - админов не пугать, пол бетонный", - добавил Александр Кирсанов.

"Да, создавать высоконагруженные проекты сложно, писать большие проекты сложно, писать большие высоконагруженные проекты сложно в квадрате. И у нас именно такой случай. И поэтому новички, когда приходят и когнитивно не могут понять, что происходит, видят там кучу кода и прочее, они думают, ну, надо все переписать, развязать, разнести на микросервисы, и будет проще. Нет, не будет проще это вообще никогда", - подчеркнул Александр Кирсанов.

Только сбоку

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

"Возможно мы изобрели микросервисы значительно раньше, чем это стало мейнстримом. Мы не используем стандартные базы данных, вместо этого у нас собственные движки, написанные на C++ хардкорными олимпиадниками. И по факту все данные, которые мы храним, мы храним в движках - движок лайков для постов, движок самих постов, рекламный движок, движок денег и т.д.", - рассказал Александр Кирсанов.

При этом он сравнил движки кода "ВКонтакте" с микросервисами, созданными в одном стиле и на одном языке программирования. "С одной стороны, их можно назвать микросервисами, но мы их такими не считаем, потому что с точки зрения инфраструктуры и эксплуатации - это примерно одно и то же. Это просто слой хранения данных и все, а весь наш код, все наши 9 млн строк компилированного PHP - это сплошной монолит, и его мы не разделяем", - отметил Александр Кирсанов.

Монолит сложней для мозга

Глава команды Architecture Governance в "Авито" Павел Лакосников отметил, что при работе с монолитным кодом когнитивная нагрузка на разработчиков значительно выше, чем при написании и отладке микросервиса.

"В какой-то момент большие, нагруженные проекты перерастают тот объем, когда в одного человека, каким бы он ни был, влезает вся предметная область. У нас такие люди начали очень быстро заканчиваться. В какой-то момент, когда осталось несколько человек, которые могли хоть как-то охватить всю предметную область, у нас появились микросервисы, и эти ребята выдохнули, потому что тот самый пресловутый bus factor (количество участников проекта, после потери которых проект не сможет быть завершен - прим. ComNews): им можно теперь попадать под автобус, а "Авито" не бахнется", - сказал Павел Лакосников.

Он отметил, что при работе с монолитным кодом очень важно постоянно контролировать разработчиков. "Ты уйдешь в отпуск, вернешься, а у тебя уже доменные области не очень друг на дружку походят. Во всяком случае так было в мой предпоследний отпуск: я ушел, вышел, и пара доменов разъезжаются прямо очень глубоко", - признался глава команды Architecture Governance в "Авито".

При этом он подчеркнул, что микросервисы должны быть именно изолированными приложениями и не сводиться к "крудам" (CRUD - акроним четырех базовых функций при работе с базами данных: создание, чтение, модификация, удаление).

"Микросервис - это небольшое приложение, которое отвечает на конкретную бизнес-задачу и несет в себе бизнес-логику. Основная часть ребят, которые создают микросервисы, на самом деле делают "круды". Но если твой микросервис делает "круд", то это плохой микросервис, лучше так не делать. Мы так не делаем и вам не советуем", - отметил Павел Лакосников.

Надежное взаимодействие процессов

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

"Кто-то себя обнаружил уже в ситуации, когда его приложение состоит из большого количества сервисов, распределенных по разным серверам, и все это не очень хорошо работает. И для меня микросервисы - это простая идея построения распределенных информационных систем. Я думаю, все мы так или иначе сталкиваемся с системами, в которых много процессов, и эти процессы между собой как-то взаимодействуют", - отметил Павел Лакосников.

"Микросервисы - это концепция собирания сервисов определенным безопасным способом для того, чтобы эти потенциально рискованные взаимодействия не приходились поверх ненадежной сети. Все остальное из этой идеи так или иначе вытекает, и 10 лет развития микросервисов - это просто обдумывание этой идеи", - заключил Максим Смирнов.

Просто инструмент

Корпоративный архитектор "Сбера" Дмитрий Дубилет призвал относиться к микросервисам как к инструменту для решения определенных задач.

"Есть разные классы задач, мы разные классы задач решаем разными инструментами - это нормально. Говорить, что мы все задачи решаем через призму монолитной архитектуры - это, наверное, хорошо, но, возможно, не для всех задач этот инструмент подходит. Также и микросервисный подход - это же просто инструмент. Для задач определенного класса вполне можем разделить ответственность и попробовать эти же задачи решать параллельно или как-то пытаться управлять сложностью решения", - подчеркнул Дмитрий Дубилет.

По его словам, выбор архитектуры проекта также во многом зависит от системы управления, которая существует в компании. "В большой организации важно не только, как решение выглядит технически, но и какие акторы решения принимают. В нашей организации, как и в любой другой большой, если в ней много бизнесов, то бизнес-акторы пытаются быть независимыми сами по себе. Поэтому архитектура так или иначе пытается найти ответ, как разным бизнес-акторам существовать в едином пространстве. И когда вы говорите про разделение технологической ответственности - это одна из сторон, а есть разделение управленческой ответственности. И здесь подходы к уменьшению связности компонентов дают большое value", - резюмировал корпоративный архитектор "Сбера".

Новости из связанных рубрик