Сегодня мы рассмотрим вопрос, который рано или поздно возникает в головах всех дизайнеров и разработчиков приложений. Вопрос заключается в том, когда для построения приложений использовать стандартную N-уровневую архитектуру, в отличие от широко разрекламированной микросервисной архитектуры. В последнее время ведется много дискуссий о проектировании, разработке и общих преимуществах использования микросервисной архитектуры. Однако создание таких приложений сопряжено с определенными затратами. Всегда ли эти затраты оправдывают себя? Проанализируем это в данной статье.

N-уровневая архитектура

Я уверен, что все знают об N-уровневой архитектуре. Эта архитектура используется уже много лет, особенно с появлением веб-приложений. Позже N-уровневая архитектура была реализована и в других приложениях. Вкратце напомним, что в N-уровневой архитектуре мы делим наше приложение на три или четыре основные области. UI – пользовательский интерфейс, отображается для конечного пользователя. Средний уровень, иногда называемый бизнес-уровнем, – это тот, в котором мы добавляем функции для бизнес-логики, доступа к данным и т.д. Иногда уровень доступа к данным может быть упомянут отдельно. Последний уровень – это уровень данных, на котором мы сохраняем наши данные с помощью какого-либо хранилища, например, реляционной или нереляционной базы данных. Это очень мощная конструкция, которая пользуется большим успехом на протяжении многих лет.

Микросервисная Архитектура

В мире разработок появилось новое слово – микросервисы, а вместе с тем и многочисленные преимущества, которые они дают. Микросервисы – это независимые сервисы, подобные приложениям, которые существуют сами по себе. Они имеют собственную логику, состояние и деплой. Они взаимодействуют друг с другом через вызовы API, очереди и т.д., в зависимости от требований. Эти микросервисы объединяются для создания общего прикладного решения. Поскольку они очень слабо связаны между собой, микросервисы можно поддерживать, масштабировать и обновлять независимо друг от друга. Разные команды могут работать над ними в одно и то же время. Также хотелось бы отметить, что для проектирования и разработки отдельных сервисов можно использовать N-уровневую архитектуру.

Нужно ли переводить все на микросервисы?

Поскольку N-уровневая архитектура представляет собой некую группу, которая в основном обновляется и деплоится вместе, а микросервисы независимы и очень слабо связаны друг с другом, должны ли мы перенести все или строить все новые приложения только с использованием микросервисов? Для меня – ответ "нет". Мы должны проанализировать каждую ситуацию, тип и масштаб приложения, прежде чем решить, какой дизайн использовать. Для небольших приложений, которые имеют несколько тысяч пользователей, мы можем построить приложение с помощью стандартной N-уровневой архитектуры, используя принципы SOLID. Эти принципы сделают наше приложение масштабируемым, обслуживаемым и высокопроизводительным. С помощью новых облачных решений, таких как службы приложений в Microsoft Azure, мы можем разворачивать приложения и обеспечивать их масштабирование с использованием инфраструктуры. Таким образом, N-уровневая архитектура предоставляет нам очень жизнеспособное решение. Это решение также очень экономически эффективно, поскольку обычно над приложением работает одна команда, и координация между командами не становится проблемой.

Однако если мы создаем очень большое приложение для обслуживания сотен тысяч пользователей или более, где требуется высокий уровень надежности, мы можем использовать микросервисную архитектуру. Помните, что при создании микросервисов необходимо гораздо больше планирования. Мы не можем запустить процесс гибкой разработки так быстро, как это можно сделать в стандартном N-уровневом приложении. Может понадобиться создать разные команды для работы с разными микросервисами, а также поработать над методом координации между ними и провести обширную работу по проектированию методологии взаимодействия между различными сервисами. Аналогичным образом, на этапе разработки потребуется еще много работы, чтобы проект шел гладко. В облаке у нас есть несколько отличных сервисов для микросервисов. Например, в Microsoft Azure есть AKS (Azure Kubernetes Services) и Service Fabric. Эти сервисы также требуют гораздо больше работы по планированию, проектированию, деплою и обслуживанию, в отличие от сервисов службы приложений, о которых мы говорили ранее.

Итак, когда же использовать микросервисы? Простой ответ: когда мы можем оправдать большие затраты на проектирование и разработку по сравнению со стандартным n-уровневым приложением. Как мы можем это обосновать? Во-первых, очень большой пользовательской базой. Во-вторых, если у нас есть приложение, которому нужны независимые компоненты, которые создаются и поддерживаются отдельно, в отличие от единого решения.

Заключение

В этой статье мы рассмотрели сценарии, в которых мы можем проектировать и разрабатывать приложение с N-уровневой архитектурой в отличие от приложения с микросервисной архитектурой. Это зависит от того, чего мы хотим достичь, и можем ли мы оправдать большие усилия, время и затраты, которые идут на планирование, проектирование, разработку, деплой и поддержку приложения с микросервисной архитектурой. Это обоснование может быть представлено в виде количества пользователей, надежности, масштаба или масштабируемости, требуемых от приложения. Не рекомендуется создавать приложение, основываясь только на том, что это новшество. Если эти пункты не обоснованы, мы можем построить простое N-уровневое приложение с применением принципов SOLID, которое будет использоваться в течение многих лет.