Различия между монолитным кодом и модульной структурой с микросервисами
На технологической конференции SmartDev 2023 участники панельной дискуссии обсуждали различия между монолитным кодом и модульной структурой с микросервисами.
Микросервисы
Микросервисы представляют собой вариант сервис-ориентированной архитектуры ПО, позволяющий обеспечить взаимодействие независимых, слабо связанных и легко изменяемых модулей.
Монолитная архитектура
Монолитная архитектура, напротив, представляет собой единый модуль, работающий автономно, независимо от других приложений.
Высказывания участников
По мнению Александра Кирсанова, руководителя команды KPHP VK, в компании VK используется гигантский монолит вместо микросервисов. Он подчеркнул, что микросервисы не являются панацеей и могут создавать больше проблем, чем решают. Неправильное использование микросервисов может привести к лишней нагрузке на сеть, базу данных и увеличить сложность отладки, мониторинга и развертывания ПО.
Аналогии
Александр Кирсанов сравнил использование микросервисов с перекредитованием, отметив, что это может усложнить администрирование системы. Он также отметил, что внутри монолитного кода ВКонтакте существуют отдельные автономные программы, напоминающие микросервисы.
Сложность проектов
Участники дискуссии согласились, что создание высоконагруженных проектов представляет собой сложную задачу, особенно при написании больших и сложных проектов. Переход от монолитной архитектуры к модульной структуре с микросервисами не всегда приводит к упрощению процесса разработки.
Пример из VK
Александр Кирсанов также упомянул, что в VK были разработаны собственные движки на C++, которые хранят всю необходимую для работы соцсети информацию. Данные движки выполняют схожие функции с микросервисами, что может означать, что концепция микросервисов применялась задолго до ее становления мейнстримом.
Translated into Russian by Svetlana MallyanovПри этом он сравнил движки кода ВКонтакте с микросервисами, созданными в одном стиле
и на одном языке программирования. С одной стороны, их можно назвать микросервисами,
но мы их такими не считаем, потому что с точки зрения инфраструктуры и эксплуатации -
это примерно одно и то же. Это просто слой хранения данных и все, а весь наш код,
все наши 9 млн строк компилированного PHP - это сплошной монолит, и его мы не разделяем,
- отметил Александр Кирсанов.
Монолит сложней для мозга
Глава команды Architecture Governance в Авито Павел Лакосников отметил, что при работе с
монолитным кодом когнитивная нагрузка на разработчиков значительно выше, чем при написании
и отладке микросервиса.
В какой-то момент большие, нагруженные проекты перерастают тот объем, когда в одного
человека, каким бы он ни был, влезает вся предметная область. У нас такие люди начали
очень быстро заканчиваться. В какой-то момент, когда осталось несколько человек,
которые могли хоть как-то охватить всю предметную область, у нас появились микросервисы,
и эти ребята выдохнули, потому что тот самый пресловутый bus factor (количество участников
проекта, после потери которых проект не сможет быть завершен - прим. ComNews): им можно
теперь попадать под автобус, а Авито не бахнется, - сказал Павел Лакосников.
Он отметил, что при работе с монолитным кодом очень важно постоянно контролировать
разработчиков. Ты уйдешь в отпуск, вернешься, а у тебя уже доменные области не очень
друг на друга похожи. Во всяком случае так было в мой предпоследний отпуск: я ушел,
вышел, и пара доменов разъезжаются прямо очень глубоко, - признался глава команды
Architecture Governance в Авито.
При этом он подчеркнул, что микросервисы должны быть именно изолированными приложениями
и не сводиться к крудам (CRUD - акроним четырех базовых функций при работе с базами данных:
создание, чтение, модификация, удаление).
Микросервис - это небольшое приложение, которое отвечает на конкретную бизнес-задачу и
несет в себе бизнес-логику. Основная часть ребят, которые создают микросервисы, на самом
деле делают круды. Но если твой микросервис делает круд, то это плохой микросервис,
лучше так не делать. Мы так не делаем и вам не советуем, - отметил Павел Лакосников.
Надежное взаимодействие процессов
ИТ-эксперт, архитектор информационных систем Максим Смирнов добавил, что у руководителя
проекта не всегда есть выбор, какую архитектуру использовать.
Кто-то себя обнаружил уже в ситуации, когда его приложение состоит из большого количества
сервисов, распределенных по разным серверам, и все это не очень хорошо работает. И для меня
микросервисы - это простая идея построения распределенных информационных систем. Я думаю,
все мы так или иначе сталкиваемся с системами, в которых много процессов, и эти процессы
между собой как-то взаимодействуют, - отметил Павел Лакосников.## Микросервисы в корпоративной архитектуре
Микросервисы - это концепция собирания сервисов определенным безопасным способом для того, чтобы эти потенциально рискованные взаимодействия не приходились поверх ненадежной сети. Все остальное из этой идеи так или иначе вытекает, и 10 лет развития микросервисов - это просто обдумывание этой идеи, - заключил Максим Смирнов.
## Роль микросервисов в решении задач
Корпоративный архитектор Сбера Дмитрий Дубилет призвал относиться к микросервисам как к инструменту для решения определенных задач.
Есть разные классы задач, мы разные классы задач решаем разными инструментами - это нормально. Говорить, что мы все задачи решаем через призму монолитной архитектуры - это, наверное, хорошо, но, возможно, не для всех задач этот инструмент подходит. Также и микросервисный подход - это же просто инструмент. Для задач определенного класса вполне можем разделить ответственность и попробовать эти же задачи решать параллельно или как-то пытаться управлять сложностью решения, - подчеркнул Дмитрий Дубилет.
## Выбор архитектуры и управления проектом
По его словам, выбор архитектуры проекта также во многом зависит от системы управления, которая существует в компании. В большой организации важно не только, как решение выглядит технически, но и какие акторы решения принимают. В нашей организации, как и в любой другой большой, если в ней много бизнесов, то бизнес-акторы пытаются быть независимыми сами по себе. Поэтому архитектура так или иначе пытается найти ответ, как разным бизнес-акторам существовать в едином пространстве. И когда вы говорите про разделение технологической ответственности - это одна из сторон, а есть разделение управленческой ответственности. И здесь подходы к уменьшению связности компонентов дают большое value, - резюмировал корпоративный архитектор Сбера.
