Итак, вы решили создать высоконагруженное ИТ-решение для бизнеса. Разработка сложного продукта, как и строительство многоэтажного дома, начинается с планирования. В этой статье мы разберем, какие бывают методологии разработки, чем они отличаются и как владельцу бизнеса выбирать архитектуру приложения.
В современной разработке ИТ-продуктов существует два подхода: монолитная архитектура и микросервисы. Кроме того, существует гибридная архитектура — это промежуточный вариант на стыке двух вышеперечисленных подходов. У каждого подхода есть свои плюсы, минусы, особенности и сторонники и противники.
Монолитная архитектура
Является классическим подходом к разработке, когда приложение построено как один цельный продукт и упаковано в виде одного WAR-файла или Node с одной точкой входа. При монолитной архитектуре все стандартные модули, пользовательский интерфейс (UI), бизнес-логика и дата-слой выступают как единый сервис. Возможны следующие способы взаимодействия с сервисом: API REST и веб-интерфейс.
Монолитная архитектура предполагает, что при обработке пользовательского запроса система прогоняет его по всем уровням.
В сущности, любой стандартный интернет-магазин выстроен как монолитное приложение.
Преимущества
+ Позволяет быстрее разработать минимально жизнеспособный продукт (MVP) и получить конечную версию продукта.
+ Проще развернуть.
+ Проще и выгоднее поддерживать.
Недостатки
— Ошибка или проблема может замедлить или разрушить все приложение.
— Сложнее масштабировать.
— Сложно изменить или переформатировать.
Микросервисная архитектура
Микросервисная архитектура предполагает принципиально иной подход к разработке, при которой все приложение собрано из отдельных независимых модулей, составленных из небольших объемов кода. У каждого модуля своя собственная логика и база данных, а их взаимодействие осуществляется через сеть по протоколонезависимой технологии.
Распространенный пример микросервисной архитектуры — это популярные онлайн-маркетплейсы вроде Avito. Каталог товаров, рейтинг пользователей, чат, отзывы — это все отдельные микросервисы в рамках одного продукта.
Приложение на базе микросервисной архитектуры дает больше возможностей, однако устроено оно сложнее.
Преимущества
+ Больше разнообразных функций.
+ Повышенная отказоустойчивость. Если один сервис «отвалился», другой может взять на себя весь его функционал.
+ Возможность обновлять по частям.
+ Независимость модулей. Проблемы с работой одного модуля меньше сказываются на работе всего приложения.
+ Проще перестраивать и масштабировать.
Недостатки
— Более требовательно к ресурсам.
— Сложнее в эксплуатации.
— Выше накладные расходы.
— Команды разработчиков должны иметь релевантный опыт и уметь работать с различными языками программирования.
Почему для разработки сложных высоконагруженных приложений для бизнеса более актуален микросервисный подход?
Микросервисный подход помогает ускорить разработку. Такой подход позволяет отдельным командам со своей узкой специализацией параллельно работать над несколькими модулями. Меньшие размеры микросервисов дают преимущества, когда речь идет о компиляции, времени запуска и сроках, необходимых на тесты.
С другой стороны, зачастую поддержкой приложений с микросервисной архитектурой занимается та же команда, которая его разработала, поскольку только она знает все нюансы.
Несмотря на более высокие накладные расходы, главная сила микросервисного подхода — адаптивность. Рассмотрим интернет-магазин. В горячий сезон для этого типа бизнеса, нагрузка на модули, которые завязаны на продажи, будет выше. И, соответственно, понадобится больше серверов. Но когда сезон закончится, дополнительные серверные мощности можно будет отключить и перенаправить на поддержку других функций.
Стоит также учитывать горизонтальное масштабирование. Если монолитное приложение рассчитано на среднюю посещаемость в 1000 пользователей, то с ним возникнут проблемы, когда бизнес и посещаемость приложения начнут расти. При микросервисной архитектуре эта проблема легко решается добавлением новых модулей и серверов.
Приложения с микросервисной архитектурой работают быстрее, поскольку пользовательский запрос происходит не к большой общей базе данных, а к одному конкретному модулю. Кроме того, микросервисы могут получать запросы не только от пользователя, но и друг от друга. Это позволяет не прогонять каждый запрос через весь массив базы данных.
Например, если в банковском приложении с микросервисной архитектурой нужно проверить кредитную историю клиента, запрос отправляется не ко всей массивной базе данных, а к модулю, отвечающему за кредитную документацию. Такой запрос система обработает значительно быстрее.
Можно ли перейти с монолита на микросервисы?
А можно ли превратить двухэтажный дом в девятиэтажку? Теоретически — да. Но на практике это означает переделывать все, начиная с фундамента. Это долго и не всегда оправданно. Поэтому, если ваша бизнес-задача предполагает создание сложного высоконагруженного приложения с перспективой масштабирования, рекомендуем остановиться на микросервисной архитектуре. В долгосрочной перспективе это будет выгоднее для компании, в том числе с финансовой точки зрения
Как насчет гибрида?
Есть и третий вариант, некий компромисс — гибридная архитектура. Когда базовый функционал реализуется в виде монолитного приложения, а отдельные функции — в виде микросервисов. В последние годы именно такой подход выбирают наши партнеры из числа крупных B2B- и B2C-компаний. Гибридная архитектура позволяет объединить надежность монолитных приложений с гибкостью и функциональностью микросервисов, чтобы минимизировать недостатки каждого из подходов.
Если вы планируете разработку веб-сервиса, сайта или приложения, прежде чем выбрать архитектуру стоит четко сформулировать ожидания от продукта: посещаемость, интеграцию с другими учетными системами, масштабируемость и другие важные факторы. Постарайтесь уже на этапе планирования привлечь опытных разработчиков, чтобы грамотно заложить основы будущего продукта на годы вперед.
