В современной экономике создание программного обеспечения (ПО) — это целая индустрия, которая, с одной стороны, оказывает помощь бизнесу в автоматизации и цифровизации всех процессов, а с другой стороны, самостоятельно приносит прибыль и создает виртуальные активы. В настоящее время проектирование в сфере R&D усложнилось, количество программистов постоянно растет, задачи для них становятся все более сложными. Эти причины привели к появлению новых методологий разработки ПО и видов архитектуры.
Современные веб-приложения многофункциональны, а цифровая трансформация, которая происходит сейчас со многими бизнесами, повышает требования к ПО. Приложение должно быть: легко масштабируемым, гибким и кроссплатформенным, быстро изменяемым под задачи пользователей. Данные требования задаются постановщиками задач уже на этапе разработки такого софта.
Для создания программного обеспечения, которое соответствует всем требованиям современного бизнеса необходимо предварительно серьезно изучить сам процесс разработки софта и выбрать правильную архитектуру.
Выбор архитектуры при разработке ПО
Как правило, ранее все приложения разрабатывались на базе монолитной архитектуры. Рассмотрим подробнее, что такое приложение-монолит.
Монолитные приложения разрабатываются, как единое целое, логика по обработке запросов помещается внутри одного процесса.
Приложения-монолиты могут быть структурированы в виде модулей и блоков. При разработке их используются отдельные классы, функции и т.д., в зависимости от применяемого языка программирования. Но построенные связи между модулями очень сильные. Из этого следует такой вывод: изменение любого модуля будет сильно отражаться на работе всего приложения.
В качестве примера можно рассмотреть типовое приложение по управлению корпоративным обучением (англ. learning management system, LMS).
Данное ПО имеет трехуровневую архитектуру, которая включает в себя:
1. интерфейс пользователя;
2. серверную часть, отвечающую за бизнес-логику ПО и доступ к данным;
3. базу данных.
Бизнес-функции такого приложения самые разные. Оно включает в себя следующие блоки: «Курсы и обучение», «Каталог курсов», «Организационная структура компании», «Календарь событий», «Отчеты», «Сообщения», «Новости» и т.д., однако, все они объединены в единый монолитный блок и расположены на одном сервере. Такое приложение масштабировать и изменять достаточно сложно. Выделим недостатки монолитной архитектуры:
Даже небольшое изменение любого функционала приложения приводит к сборке и развертыванию новой версии всего ПО.
Масштабировать можно только все приложение, отдельный блок масштабировать невозможно.
Если откажет любой модуль приложения, то в следствии этого, может быть нарушена работа всего приложения.
Средства разработки всегда ограничены выбранным сразу стеком технологий.
Сложность в управлении большой командой квалифицированных разработчиков. Каждый разработчик должен разбираться во всем функционале приложения, а не только в своем модуле.
Любое обновление затрагивает весь функционал приложения, это приводит к рискам отказа приложения после обновлений. Поэтому производятся только редкие выпуски обновлений.
Любые изменения в базе данных могут сказываться на работе всего приложения и нуждаются в изменениях в коде.
В случае, если это небольшая бесплатная программа для обучения каким-то отдельным навыкам для обычного пользователя, да еще и обновляемая достаточно редко, то монолитная архитектура вполне подойдет для такой разработки.
Если же речь идет о корпоративном приложении (о полноценной LMS, к примеру), да еще и часто обновляемом, то необходимо выбирать микросервисную архитектуру.
Микросервисная архитектура — это оптимальный подход к разработке программного обеспечения. В микросервисной архитектуре приложение делится на небольшие и автономные компоненты (микросервисы) с определенными интерфейсами. Свое применение такая архитектура нашла в сфере облачных вычислений.
В чем же ее отличие от монолитной архитектуры? В микросервисной архитектуре приложение разрабатывается в виде набора небольших и малосвязанных между собой компонентов, которые и называются — микросервисы. Микросервисы разрабатываются, развертываются и поддерживаются почти независимо друг от друга.
Если взять наш пример с приложением для LMS, то каждый микросервис нацелен на решение только своей конкретной бизнес-задачи, имеет свою базу данных, а контакт с другими микросервисами происходит через API. Таким образом, для приложения по управлению корпоративным обучением, необходимо будет разработать следующие микросервисы: «Курсы и обучение», «Каталог курсов», «Организационная структура компании», «Календарь событий», «Отчеты», «Сообщения», «Новости» и т.д.,
Необходимо отметить, что есть еще один тип архитектуры — это сервис-ориентированная архитектура (SOA, service-oriented architecture). Иногда ее путают с микросервисной. Кажется, что отличия между микросервисной архитектурой и SOA не так очевидны. Но существуют различия между микросервисами и SOA, это проявляется в отношении роли сервисной шины предприятия (ESB).
SOA представляет собой архитектуру в масштабах компании, ее цель в стандартизации взаимодействия и интеграции веб-сервисов компании. Назначение микросервисной архитектуры — в разработке конкретного приложения. К SOA имеют отношение следующие шаблоны: CORBA, web-сервисы, очереди сообщений, ESB и т.д.
Ниже подробно расскажем о преимуществах именно микросервисов для создания веб-приложений.
Основные преимущества микросервисной архитектуры
Преимущества микросервисов будем оценивать по сравнению с монолитной архитектурой.
Простота и независимость в развертывании приложения. В случае с микросервисами, можно развернуть только один какой-нибудь модуль приложения. Например, в нашем случае с LMS, можно развернуть только один модуль («Календарь событий»), оставив без изменений остальные компоненты приложения. Если нужно переписать пару строчек кода в модуле «Отчеты», то нет необходимости получать множество разрешений. Этот компонент («Отчеты») — отдельный и независимый микросервис.
Точность и эффективность масштабирования. Для начала, необходимо определиться, какие микросервисы будут требовать частого масштабирования, а какие — нет. Модули, которые не нужно часто масштабировать можно расположить на более слабых серверах, а часто масштабируемые — масштабировать отдельно от всего остального ПО.
Повышенная отказоустойчивость приложения. Рациональное проектирование приложения и выстраивание независимых связей между модулями дает следующее преимущество: отказ одного из модулей не приводит к отказу всего программного обеспечения. Например, если отказал модуль «Сообщения», то пользователь получит оповещение о временной недоступности данного блока. Все остальные блоки приложения будут работать.
Выбор стека технологий. Разрабатывая каждый микросервис, можно подобрать наиболее соответствующий его функциям и удобству разработки стек технологий.
Гибкость в управлении командами разработчиков. Можно привести простой пример: команда № 1 разрабатывает сервис «Каталог курсов», команда № 2 — «Календарь событий», а команда № 3 — «Новости». Новому специалисту проще быстрее войти в работу, так как не нужно долго изучать функционал всего приложения, достаточно освоить стек технологий для конкретного микросервиса.
Возможность использования функционала повторно (для различных целей и различными способами).
Замена или удаление ненужных заказчику сервисов решается быстро и легко. Например, конкретный заказчик не будет пользоваться блоком «Новости» в LMS, тогда этот модуль можно просто удалить, без глобальных изменений во всем ПО.
Каждый микросервис использует собственную БД. Этот факт приводит к независимости моделей данных. К примеру, если программист изменил модель данных в одном конкретном сервисе, то это не повлияет на работу других сервисов.
Как мы видим, микросервисная архитектура имеет значительные преимущества и все больше и больше привлекает разработчиков. Однако, перед тем как выбрать архитектуру для разработки ПО, стоит посмотреть и на недостатки микросервисов, которые будут перечислены ниже.
Недостатки микросервисов
Система работы микросервисов является распределенной. С одной стороны, это преимущество в работе софта. С другой стороны, если микросервисов слишком много и каждый из них обращается с запросами к другим сервисам, то результирующее время отклика будет увеличиваться и появятся «точки отказа». Для решения этой проблемы существуют два пути:
1) изменение детализации вызовов, которое может привести к снижению их количества;
2)внедрение асинхронности, отзывы выполняются параллельно, в результате это приводит к тому, что конечное время отклика — это самое медленное время из всех, а не суммарное время всех задержек.
Постоянное усложнение процесса разработки, что приводит к повышению требований к квалификации программистов. В микросервисной архитектуре роль интеграционных процессов и процессов непрерывной доставки велика. И поэтому достаточно трудно обрабатывать множество процессов без автоматизации тестирования и развертывания сервисов. Это факторы требуют внедрения DevOps в компании и тесного сотрудничества разработчиков с системными инженерами, тестировщиками, службой тех. поддержки и т.д.
Децентрализация в микросервисной архитектуре порождает проблемы с согласованностью микросервисов. Например, в монолитном приложении за одну транзакцию возможно выполнение множества изменений, но и возможен откат назад, если произошел сбой, с сохранением согласованности данных. При применении микросервисов, возможна следующая ситуация: в случае нарушения работы одного из сервисов, перестает отвечать другой микросервис. В таком случае — это вопрос приоритетов разработчика: можно дать приоритет доступности компонентов (в случае выхода из строя одного сервиса, другие продолжат функционирование). В общем, разработчики должны находить баланс между согласованностью сервисов и их доступностью и делать это необходимо очень осторожно.
Выводы
Перед тем как выбирать микросервисную архитектуру для разработки веб-приложений, разработчикам стоит оценить как ее преимущества, так и недостатки. Ведь неправильный выбор архитектуры, может отразиться в будущем на работоспособности и функциональности ПО. При неправильном применении микросервисной архитектуры у разработчиков могут возникнуть большие проблемы, которые нивелируют все преимущества микросервисов.
В следующей части статьи, будет рассмотрен технический инструментарий, которым должен овладеть разработчик, который собирается использовать микросервисную архитектуру в разработке ПО.