В ноябре OTUS запускает новую образовательную программу «Архитектор ПО», в связи с этим подготовили серию публикаций для будущих студентов курса и читателей нашего блога.
Создание нового продукта всегда связано с риском. И выбор правильной архитектуры — важный шаг на пути успеху. Если вы выбираете между монолитной, сервис-ориентированной, микросервисной и бессерверной архитектурой, этот пост поможет вам сделать правильный выбор.
Монолитная архитектура
Монолит — это древнее слово, обозначающее огромный каменный блок. Хотя этот термин широко используется сегодня, представление остается одинаковым во всех областях. В программной инженерии монолитная модель относится к единой неделимой единице. Концепция монолитного программного обеспечения заключается в том, что различные компоненты приложения объединяются в одну программу на одной платформе. Обычно монолитное приложение состоит из базы данных, клиентского пользовательского интерфейса и серверного приложения. Все части программного обеспечения унифицированы, и все его функции управляются в одном месте. Давайте посмотрим на структуру монолитного программного обеспечения в деталях.
Монолитная архитектура удобна для работы небольших групп, поэтому многие стартапы выбирают этот подход при создании приложения. Компоненты монолитного программного обеспечения взаимосвязаны и взаимозависимы, что помогает программному обеспечению быть самодостаточным. Эта архитектура является традиционным решением для создания приложений, но некоторые разработчики считают ее устаревшей. Тем не менее, мы считаем, что монолитная архитектура является идеальным решением при некоторых обстоятельствах.
Несмотря на то, что у нас был положительный опыт использования микросервисов в Google, мы [в Scaylr] пошли по монолитному маршруту, потому что наличие одного монолитного сервера предполагает меньше работы для нас как для двух инженеров.
Стивен Червински, руководитель отдела проектирования в Scaylr
Чтобы выяснить, подходит ли это решение для вашего бизнеса, давайте рассмотрим его плюсы и минусы.
Плюсы монолитной архитектуры
Упрощенная разработка и развертывание
Есть много инструментов, которые вы можете интегрировать для облегчения разработки. Кроме того, все действия выполняются с одним каталогом, что упрощает развертывание. Благодаря монолитному ядру разработчикам не нужно развертывать изменения или обновления по отдельности, поскольку они могут сделать это сразу и сэкономить много времени.
Меньше сквозных проблем
Большинство приложений зависят от множества межкомпонентных задач, таких как контрольные журналы, ведение логов, ограничение скорости и т. д. Монолитные приложения гораздо легче учитывают эти вопросы благодаря своей единой кодовой базе. К этим задачам проще подключать компоненты, когда все работает в одном приложении.
Лучшая производительность
При правильной сборке монолитные приложения обычно более производительны, чем приложения на основе микросервисов. Например, приложению с микросервисной архитектурой может потребоваться выполнить 40 вызовов API для 40 различных микросервисов чтобы загрузить каждый экран, что, очевидно, приводит к снижению производительности. Монолитные приложения, в свою очередь, обеспечивают более быструю связь между программными компонентами благодаря общему коду и памяти.
Минусы монолитной архитектуры
Кодовая база со временем становится громоздкой
С течением времени большинство продуктов продолжают разрабатываться и увеличиваются в объеме, а их структура становится размытой. Кодовая база начинает выглядеть действительно громоздко и становится трудной для понимания и изменения, особенно для новых разработчиков. Также становится все труднее находить побочные эффекты и зависимости. С ростом кодовой базы ухудшается качество и перегружается IDE.
Сложно внедрять новые технологии
Если в ваше приложение необходимо добавить какую-то новую технологию, разработчики могут столкнуться с препятствиями для на пути внедрения. Добавление новой технологии означает переписывание всего приложения, что является дорогостоящим и требует много времени.
Ограниченная гибкость
В монолитных приложениях каждое небольшое обновление требует полного повторного развертывания. Таким образом, все разработчики должны ждать, пока это не будет сделано. Когда несколько команд работают над одним проектом, гибкость может быть значительно снижена.
В итоге
Монолитная модель не устарела, и в некоторых случаях она по-прежнему прекрасно работает. Некоторые гигантские компании, такие как Etsy, остаются монолитными, несмотря на сегодняшнюю популярность микросервисов. Архитектура монолитного программного обеспечения может быть полезной, если ваша команда находится на начальной стадии, вы создаете непроверенный продукт и не имеете опыта работы с микросервисами. Монолит идеально подходит для стартапов, которым необходимо как можно быстрее запустить продукт в эксплуатацию. Однако некоторые проблемы, упомянутые выше, идут рука об руку с монолитной архитектурой.
SOA
Сервис-ориентированная архитектура (далее SOA — service-oriented architecture) — это стиль архитектуры программного обеспечения, который предполагает модульное приложение, состоящее из дискретных и слабосвязанных программных агентов, которые выполняют конкретные функции. SOA разделяет компоненты по двум основным ролям: поставщик и потребитель сервисов. Обе эти роли могут играть программные агенты. Концепция SOA заключается в следующем: приложение может быть спроектировано и построено таким образом, что его модули легко интегрируются и могут быть легко использованы повторно.
Плюсы SOA
Повторное использование сервисов
Из-за автономной и слабо связанной природы функциональных компонентов в сервис-ориентированных приложениях эти компоненты можно повторно использовать в нескольких приложениях, без влияния на другие сервисы.
Легкость в сопровождении
Поскольку каждая служба программного обеспечения является независимой единицей, ее легко обновлять и поддерживать, не затрагивая другие службы. Например, крупными корпоративными приложениями легче управлять, когда они разбиты на службы.
Более высокая надежность
Службы легче отлаживать и тестировать, чем огромные куски кода, как в монолитах. Это, в свою очередь, делает продукты на основе SOA более надежными.
Параллельная разработка
Поскольку сервис-ориентированная архитектура разбита на прослойки, она поддерживает параллелизм в процессе разработки. Независимые сервисы могут разрабатываться параллельно и быть завершены одновременно.
Минусы SOA
Сложность в управлении
Основным недостатком сервис-ориентированной архитектуры является ее сложность. Каждый сервис должен обеспечивать своевременную доставку сообщений. Количество этих сообщений может превышать миллион за один раз, что затрудняет управление всеми службами.
Высокие инвестиционные затраты
Разработка SOA требует значительных предварительных инвестиций в человеческие ресурсы, технологии и разработку.
Дополнительная нагрузка
В SOA все входные данные проверяются до того, как один сервис взаимодействует с другим сервисом. При использовании нескольких сервисов это увеличивает время отклика и снижает общую производительность.
В итоге
SOA лучше всего подходит для сложных корпоративных систем, например банковских. Банковскую систему чрезвычайно сложно разделить на микросервисы. Но монолитный подход также не годится для банковской системы, так как одна часть может повредить все приложение. Лучшее решение — использовать подход SOA и организовать сложные приложения в изолированные независимые сервисы.
На этом мы завершаем первую часть перевода, а о микросервисах и бессерверной архитектуре поговорим во второй части материала.
Автор: MaxRokatansky
