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