Если вы разработчик или специалист, ответственный за создание и функциональное развитие интернет-магазина, эта статья для вас. В ней технический директор Simtech Development Андрей Мягков расскажет об особенностях, достоинствах и недостатках каждого подхода, а также поможет понять, какой из них может стать оптимальным для вашего бизнеса.
Монолит и микросервисы ー в чем разница
Когда я говорю об архитектуре, то подразумеваю определенный подход к построению приложения.
В монолитной архитектуре база данных, бизнес-логика и пользовательский интерфейс собраны в единую кодовую базу.
У микросервисной модели наоборот: каждый компонент самостоятелен и представляет собой отдельное приложение с собственным набором файлов, библиотек, конфигураций, ресурсов и, конечно, кодовой базой.
Давайте разбираться детально.
Монолитная архитектура приложения
Что такое монолитная архитектура
Монолитная архитектура ー это приложение, построенное как цельный продукт с единой кодовой базой. Взаимодействие с сервисом при этом происходит через API или веб-интерфейс.
Если говорить о e-Commerce, то большинство интернет-магазинов ー монолиты. Хотя бы потому, что эта модель возникла первой (в 1990 ー 2010 гг.), и большинство предпринимателей, создавших свои сайты на этой архитектуре, годами развивают проекты в ее рамках.
Не стоит, однако, думать, что монолиты (или, как их еще называют, моносервисы) ー начальная ступень эволюции в проектировании сайтов и потому потеряли актуальность. Если бы это было действительно так, её бы не выбрали Wildberries, Shopify, ivi. Эти и многие другие гиганты Web являются наглядными примерами монолитной архитектуры. Так чем же хорош этот подход?
Применяя монолитную архитектуру приложения, разработчики получают преимущества в виде удобства сопровождения, простоты масштабирования и снижения сложности развертывания. Однако, стоит учитывать, что этот подход может столкнуться с ограничениями в гибкости и масштабируемости при долгосрочной перспективе. В современном мире тенденция перехода к микросервисной архитектуре свидетельствует о стремлении к более модульному и гибкому подходу к разработке, что позволяет эффективнее адаптироваться к изменениям и требованиям рынка.
Преимущества монолитной архитектуры
У монолитной архитектуры есть множество плюсов, перечислю основные:
Простота разработки и техподдержки
Единая кодовая база позволяет быстро запустить проект и по необходимости добавлять нужные модули. Разработчику не нужно волноваться о межпроцессном взаимодействии ー все компоненты находятся внутри монолита, в одном репозитории.
Упрощенное развертывание
Приложение разворачивается на одном сервере или виртуальной машине. Это делает процесс выпуска, установки и активации ПО быстрым и удобным.
Простая коммуникация
Внутри монолита коммуникация между компонентами может происходить напрямую, без использования удаленного вызова процедур (RPC) или межпроцессного взаимодействия (IPC). Высокая скорость взаимодействия дает сайту высокую производительность.
Вариативность масштабирования
Приложение на монолите можно наращивать и усложнять как горизонтальным путем ー через добавление дополнительных ресурсов, так и вертикальным ー улучшая производительность сервера и самого приложения.
Простота обновлений
Апгрейд программы на монолитной архитектуре может происходить легче, чем на микросервисной, ведь в первом случае потребуется обновить только одну кодовую базу, во втором ー базу каждого микросервиса.
Высокая экспертность команды
Когда команда разработчиков работает в монолитном стеке технологий и использует один язык программирования, она ежедневно оттачивает свои навыки и становится по-настоящему профессиональной ー даже если состоит из сотрудников разного уровня компетенций. Опытные Senior-специалисты тянут за собой мидлов, а те передают знания и опыт джунам. Поэтому владелец бизнеса может нанять команду из сотрудников разных грейдов.
Сайт на монолите прост в эксплуатации, но у него есть и недостатки. Рассмотрим подробно?
Недостатки монолитной архитектуры
Среди минусов монолитной архитектуры приложения можно выделить следующие:
Постепенное усложнение структуры проекта
Бывает так, что в проекте, который рос и развивался годами, становится непонятно, какие части кода отвечают за какую функциональность. И это в конечном счете может привести к чрезмерной взаимозависимости элементов, когда разработка новой фичи требует изменений в разных функциональных блоках.
Высокая уязвимость
В монолите практически нет изоляции: проблема или ошибка в одном из модулей может замедлить или привести к остановке работы всей программы. Такие инциденты приводят к перебоям в обслуживании и могут затронуть всех активных пользователей.
Ограниченная масштабируемость
Монолитная система не позволяет наращивать мощности для отдельных компонентов. Например, если из-за увеличения трафика снижается производительность коммуникационных функций приложения, придется предоставить дополнительные ресурсы для всего монолита. Это не рационально с точки зрения использование мощностей, но по-другому никак.
Сложность в обслуживании
Монолитные приложения часто имеют большой объем кода, что делает его сложным для понимания и обслуживания. Представьте, что на проект приходит новый разработчик, ему надо добавить фичу, а он видит в базе 10 тысяч строк кода. Как думаете, сколько времени он потратит на реализацию несложной, казалось бы, задачи?
Отсутствие выбора технологий
Возможности монолитных приложений ограничены стеком технологий, использованным в процессе разработки и развертывания приложения. Когда сайт создан на основе одного языка программирования или фреймворка, использовать другие будет сложно или вовсе невозможно.
Приложение построено как единое целое, где компоненты напоминают звенья замкнутой цепи. Связи между ними настолько сильны, что малейшие изменение будут влиять на работу всего приложения.
А теперь давайте перейдем к другому распространенному подходу к проектированию приложения. Я говорю о микросервисах, которые стали “антиподами” монолитов.
Микросервисная архитектура приложения
Что такое микросервисная архитектура приложения
Микросервисная архитектура ー это приложение, которое собрано из отдельных независимых модулей. У каждого из них своя логика, база данных, язык кода, а взаимодействуют они через сеть по протоколонезависимой технологии.
Микросервисы как архитектура возникли с опозданием от монолитов примерно на 10 лет (ориентировочно в начале 2010-х годов). Они полюбились разработчикам за то, что каждый из сервисов сосредоточен на конкретной функции, работать над которой может отдельная группа специалистов. Примеры сайтов развернутых на микросервисной архитектуре — Netflix, Uber, Airbnb и Amazon.
Давайте рассмотрим плюсы и минусы микросервисной архитектуры сайта.
Преимущества микросервисной архитектуры
Среди плюсов микросервисов можно отметить следующие:
Высокая скорость разработки и внедрения нового функционала
Микросервисы позволяют разработчикам работать над отдельными сервисами независимо друг от друга. На знакомство с приложением уходит пара дней: специалист получает задачу, быстро в нее погружается, делает продуктовую версию, тестирует, выпускает в релиз.
Отсутствие ограничений в стеке технологий
Микросервисы могут сочетать разные технологии и языки программирования. Один может быть написан на Java, другой – на Python.
Высокая масштабируемость
Микросервисы разбивают приложение на небольшие независимые компоненты, каждый из которых выполняет конкретную функцию. Это позволяет горизонтально масштабировать отдельные сервисы и гибко управлять ресурсами.
Высокая производительность приложения
Когда пользователи или запросы к приложению растут, микросервисы можно добавлять, размещая их на дополнительных серверах. Вы можете легко управлять нагрузкой и распределять трафик.
Экономия на найме сотрудников
Использование микросервисов позволяет отдать часть работы на аутсорсинг. Так получается больше пространства для маневра как в технологиях, так и в специалистах. Что это дает компании? Возможность оптимизировать расходы, связанными с подбором персонала и подрядчиков.
Недостатки микросервисной архитектуры
Помимо достоинств, микросервисы имеют и свои минусы.
Высокая стоимость разработки
Для успешного создания, развития и поддержки микросервисов необходимы приличные финансовые ресурсы: нужно учесть затраты на аренду серверов или облачные вычисления, лицензии на ПО, большое количество интеграций и настройку для связи между сервисами.
Сложность разработки и обслуживания
Создание архитектуры из нескольких микросервисов – технически более сложная задача, чем разработка монолитного приложения. Она требует координации, согласования данных, мониторинга работы всех сервисов по отдельности и вместе взятых. Возникает больше потенциальных уязвимостей, а на тестирование и отладку каждого компонента может уйти немало времени.
Представьте себе ситуацию – сломался один микросервис. И перед IT-специалистами тут же встает масса вопросов:
- как теперь обмениваться данными с другими сервисами?
- как восстановить потерянную информацию?
- как будут работать другие компоненты, если их данные гонялись через тот, который вышел из строя?
Владельцу бизнеса потребуется приличный штат высокоуровневых инженеров, которые будут знать логику каждого микросервиса, как свои пять пальцев.
Увеличение нагрузки на инфраструктуру
Так как каждый сервис архитектуры требует собственных ресурсов, то общая нагрузка становится внушительной. Это может привести к снижению производительности сайта, задержкам в обработке запросов и проблемам с доступностью сервисов.
Угроза потери данных
При передаче данных от одного микросервиса к другому по IP-протоколу возникает риск потери информации. Для связывания логов одной машины с логами запросов другой потребуется время и усилия команды DevOps-инженеров, которые должны обеспечивать настройку соединений между сервисами, мониторинг передачи данных, целостность и безопасность информации.
Необходимость иметь опытных разработчиков
Чтобы создать микросервис, понадобится команда компетентных специалистов, которые владеют разными языками программирования, знают, с помощью каких технологий и инструментов разрабатывать и поддерживать архитектуру.
Сервисы обмениваются данными через API и могут быть разработаны, развернуты и масштабированы независимо друг от друга.
Ключевые отличия между монолитной и микросервисной архитектурой
Перед тем, как вы остановитесь на том и или ином подходе, проведите анализ и оценку их ключевых характеристик. Чтобы вам было проще понять разницу монолитов и микросервисов, мы собрали их характеристики в таблицу.
| Монолит VS Микросервисы | |
| Монолит | Микросервисы |
| Функционал приложения представляет собой единый модуль | Функционал приложения разбит на независимые друг от друга микросервисы |
| Компоненты взаимодействуют друг с другом через встроенные механизмы одной системы | Микросервисы взаимодействуют друг с другом через API |
| Используется единый технологический стек для всего приложения | Каждый микросервис может использовать собственный технологический стек |
| Приложение написано в одной базе кода | Каждый модуль написан в своей базе кода |
| Разработка, тестирование и развертывание приложения выполняются как единое целое | Каждый микросервис разрабатывается, тестируется и развертывается независимо от других |
| Развертывание приложения происходит в одной среде | Развертывание приложения представляет собой пакет ПО с изолированным от платформы кодом |
| Любая модификация отражается на множестве функций и приложении в целом | Модифицируется только нужный сервис или функция, что не влечет изменений продукта |
| Единая точка отказа. Отказы влияют на все приложение | Изолированные отказы. Высокая отказоустойчивость |
| Прямые вызовы функций. Простая коммуникация и обмен данными | Понадобятся ресурсы для координации и согласованности данных |
| Масштабировать нужно все приложение сразу | Масштабировать можно отдельные микросервисы |
| Требует меньше планирования на начальном этапе, но управление и обслуживание с каждым годом будет усложняться | Требует больше планирования на начальном этапе, но управление и обслуживание со временем упрощаются |
| Невысокие инвестиции на старте, растущие суммы за техническое обслуживание в долгосрочной перспективе | Более серьезные инвестиции в разработку проекта, чем у монолита. Снижение затрат в долгосрочной перспективе |
| Подходит для разработки сайтов с простой централизованной структурой, прототипа, MVP для e-Commerce-проекта | Подходит для разработки больших приложений с необходимостью постоянно масштабироваться |
Гибридная архитектура
Кстати, а ведь есть еще одна модель, которая встречается в e-Com-проектах. Речь идет о гибридной архитектуре. Она становится некоторым компромиссом между микросервисами и монолитом и встречается в двух вариантах:
1. Гибридный монолит
Основная часть функционала приложения реализована в виде монолита, но для некоторых частей приложения используются микросервисы. Например, сайт может быть реализован в виде монолита, а мобильное приложение быть отдельным микросервисом. Так комбинируется удобство разработки и возможность масштабирования отдельных компонентов.
2. Микросервисные модули
Монолитное приложение разбивается на отдельные функциональные компоненты, которые реализованы в виде микросервисов. При этом некоторые функции или службы остаются внутри монолита.
Гибридная архитектура проекта позволяет комбинировать преимущества обоих подходов. Как правило, ее используют для постепенной миграции с монолита на микросервисную архитектуру.
Приведу пример: сейчас мы работаем с федеральной сетью салонов оптики. Интернет-магазин был создан на монолите более 10 лет назад, и в последнее время коммуникация с системами складского учета нарушилась, сайт стал “падать”.
С этой проблемой владельцы бизнеса пришли в Simtech Development и на встрече с экспертами озвучили: может, пора переходить на микросервисы? Решение модное, продвинутое, должно помочь (ох, уж мне этот хайп вокруг “набора самостоятельных сервисов”!).
А еще мы обсудили планы развития бизнеса: в ближайшие несколько лет клиенту хотелось запустить маркетплейс, и тоже на микросервисах. Пришлось раскладывать все по полочкам:
- Шумиха вокруг микросервисов не говорит об универсальности решения, перепроектирование не приводит к автоматическому устранению неполадок.
- Переезд с одной платформы на другую — трудозатратный, долгий и дорогой процесс, который в конечном итоге может не принести ожидаемого результата. Зачем все так усложнять, когда можно рядом с монолитом построить небольшой микросервис, вывести туда часть данных, и коммуникация компонентов будет налажена.
- В случае заказчика запускать маркетплейс на микросервисах нецелесообразно: с 20 тысячами товаров в каталоге (для примера, на Ozon их более 82 млн) и планами на постепенное масштабирование он просто не нужен. Сайту не потребуется столь мощная производительность, большое обилие компонентов и многочисленная команда разработчиков с DevOps-инженерами, как у микросервисов. Тогда зачем за это платить и обслуживать?
- Создать маркетплейс на монолите можно за полгода-год, а вот разработка сайта на микросервисах займет в два раза больше времени. Риск, что нишу займут конкуренты, крайне высок.
Чтобы свести его к минимуму, лучше запускать MVP (Minimal Viable Product, “минимально жизнеспособный продукт”). Базовой версии сайта хватит, чтобы проверить жизнеспособность проекта, собрать обратную связь от клиентов, отработать возражения и скорректировать стратегию, а когда этап адаптация будет успешно пройден, можно будет постепенно усложнять функционал.
Какая архитектура подходит вашему проекту?
Прежде чем выбрать архитектуру для своего проекта, сформулируйте ожидания от продукта: посещаемость, интеграцию с учетными системами, масштабируемость. Могу дать еще пару векторов для размышлений.
— с развертыванием проекта на одном сервере,
— с приоритетом в простой разработке и техподдержке,
— с желанием быстро запустить MVP, без сложных интеграций и множества сервисов.
— с технологической разнородностью компонентов;
— нуждающихся не только в стандартных интеграциях со сторонними сервисами (платежные системы, системы доставки, управления инвентарем, CRM), но и более сложными. Например, такими как: система возвратов и обмена товаров, управлением социальными медиа, рекламными кампаниями, программами лояльностями.
Итоги
При разработке крупного e-Commerce-проекта следует уделить особое внимание проектированию сайта. Он может быть построен на микросервисной архитектуре, а может на монолите. И у каждой из этих моделей есть свои плюсы и минусы.
Микросервисы предлагают масштабируемость, гибкость и технологическое разнообразие, однако разработчикам придется столкнуться со сложностями в коммуникации компонентов и непростом обслуживании системы.
Монолиты более просты и эффективны в разработке, идеальны для MVP, но придется учитывать сложности в масштабируемости и развертывании.
Что выбирать — решать вам. Ориентируйтесь на:
- бюджет компании,
- масштаб и бизнес-логику проекта,
- требования к доступности и масштабируемости,
- наличие собственной IT-команды и её опыт,
- готовность частично или полностью передать разработку проекта специалистам IТ-компании.
Если вам понадобится поддержка, свяжитесь с экспертами Simtech Development. Мы подскажем, какая архитектура будет оптимальной для вашего онлайн-бизнеса и создадим интернет-магазин или маркетплейс в соответствии с лучшими международными практиками.
