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

В последнее время я видел довольно много сообщений о вакансиях разработчиков, в которых есть предложение, которое выглядит примерно так: «Должен иметь опыт работы с архитектурой N-уровня» или «Должен иметь возможность разрабатывать приложения N-уровня».

Это заставляет меня спросить, что такое архитектура N-уровня? Как можно получить опыт с этим?

Википедия :

В разработке программного обеспечения многоуровневая архитектура (часто называемая n-уровневой архитектурой) представляет собой архитектуру клиент-сервер, в которой представление, обработка приложений и управление данными являются логически отдельными процессами. Например, приложение, которое использует промежуточное программное обеспечение для обслуживания запросов данных между пользователем и базой данных, использует многоуровневую архитектуру. Наиболее распространенное использование «многоуровневой архитектуры» относится к трехуровневой архитектуре.

Это спорно , что считается «ярусах» , но , на мой взгляд, необходимо , по крайней мере пересечь границу процесса. Или это называется слоями. Но это не должно быть в физически разных машинах. Хотя я не рекомендую это делать, вы можете разместить логический уровень и базу данных в одном блоке.

Редактирование : Одним из следствий этого является то, что уровень представления и уровень логики (иногда называемый уровнем бизнес-логики) должны пересекать границы машины «по проводам», иногда по ненадежной, медленной и / или небезопасной сети. Это сильно отличается от простого настольного приложения, в котором данные находятся на том же компьютере, что и файлы, или веб-приложения, где вы можете напрямую обращаться к базе данных.

Для n-уровневого программирования вам необходимо упаковать данные в какую-то переносимую форму, называемую «набор данных», и передать их по проводам. Класс DataSet .NET или протокол веб-сервисов, такие как SOAP, - это лишь немногие из таких попыток переместить объекты по проводам.

Он основан на том, как вы отделяете уровень представления от основной бизнес-логики и доступа к данным ( Википедия )

• Трехуровневый означает уровень представления + уровень компонента + уровень доступа к данным.
• N-уровень - это когда дополнительные слои добавляются за их пределы, обычно для дополнительной модульности, конфигурируемости или взаимодействия с другими системами.

Это модное слово, относящееся к вещам, подобным обычной веб-архитектуре, например, Javascript - ASP.Net - Middleware - Уровень базы данных. Каждая из этих вещей является «ярусом».

N-уровневые приложения данных - это приложения данных, которые разделены на несколько уровней. Также называемые «распределенные приложения» и «многоуровневые приложения», n-уровневые приложения разделяют обработку на отдельные уровни, которые распределяются между клиентом и сервером. Когда вы разрабатываете приложения для доступа к данным, у вас должно быть четкое разделение между различными уровнями, составляющими приложение.

Типичное n-уровневое приложение включает в себя уровень представления, средний уровень и уровень данных. Самый простой способ разделить различные уровни в n-уровневом приложении - это создать отдельные проекты для каждого уровня, который вы хотите включить в свое приложение. Например, уровень представления может быть приложением Windows Forms, тогда как логика доступа к данным может быть библиотекой классов, расположенной на среднем уровне. Кроме того, уровень представления может связываться с логикой доступа к данным на среднем уровне через службу, такую ​​как служба. Разделение компонентов приложения на отдельные уровни повышает удобство обслуживания и масштабируемость приложения. Это достигается за счет более легкого внедрения новых технологий, которые могут применяться на одном уровне без необходимости перепроектирования всего решения. К тому же,

Взято с сайта Microsoft .

Если я понимаю вопрос, то мне кажется, что тот, кто задает вопрос, действительно спрашивает: «Хорошо, так что 3-й уровень хорошо понятен, но, похоже, существует смесь ажиотажа, растерянности и неуверенности относительно того, какой 4-уровень или обобщение, означает N-уровневую архитектуру. Итак ... что такое определение N-уровня, которое широко понято и согласовано? "

Это на самом деле довольно глубокий вопрос, и чтобы объяснить почему, мне нужно пойти немного глубже. Потерпите меня.

Классическая трехуровневая архитектура: база данных, «бизнес-логика» и презентация - хороший способ прояснить, как соблюдать принцип разделения интересов. То есть, если я хочу изменить то, как «бизнес» хочет обслуживать клиентов, мне не нужно просматривать всю систему, чтобы выяснить, как это сделать, и, в частности, не следует разбрасывать решения бизнес-вопросов. волей-неволей через код.

Сейчас эта модель хорошо работает десятилетиями, и это классическая модель «клиент-сервер». Перенесемся в облачные предложения, где веб-браузеры являются пользовательским интерфейсом для широкого и физически распределенного набора пользователей, и обычно приходится добавлять службы распространения контента, которые не являются частью классической 3-уровневой архитектуры (и которым нужно управлять самостоятельно).

Концепция обобщает, когда речь идет об услугах, микросервисах, распределении данных и вычислений и так далее. То, является ли что-то «уровнем», во многом зависит от того, предоставляет ли уровень интерфейс и модель развертывания для служб, которые находятся позади (или ниже) уровня. Таким образом, сеть распространения контента будет представлять собой уровень, а служба аутентификации - нет.

Теперь перейдите и прочитайте другие описания примеров N-уровневых архитектур с учетом этой концепции, и вы начнете понимать проблему. Другие перспективы включают подходы на основе поставщиков (например, NGINX), балансировщики нагрузки с учетом содержимого, службы изоляции данных и безопасности (например, IBM Datapower), которые могут или не могут повысить ценность данной архитектуры, развертывания и использования.

Насколько я понимаю, N-Tier отделяет бизнес-логику, клиентский доступ и данные друг от друга, используя отдельные физические машины. Теория заключается в том, что один из них может быть обновлен независимо от других.

N-уровневые приложения данных - это приложения данных, которые разделены на несколько уровней. Также называемые «распределенные приложения» и «многоуровневые приложения», n-уровневые приложения разделяют обработку на отдельные уровни, которые распределяются между клиентом и сервером. Когда вы разрабатываете приложения для доступа к данным, у вас должно быть четкое разделение между различными уровнями, составляющими приложение.

И так далее в http://msdn.microsoft.com/en-us/library/bb384398.aspx

При построении обычного MCV (3-уровневая архитектура) можно решить реализовать MCV с двухпалубными интерфейсами, так что фактически можно заменить определенный уровень без необходимости изменять даже одну строку кода.

Мы часто видим преимущества этого , например, в сценариях, когда вы хотите иметь возможность использовать более одной базы данных (в этом случае у вас есть двойной интерфейс между уровнями управления и данными).

Когда вы помещаете его на View-слой (презентация), вы можете (удерживать !!) заменить интерфейс USER другой машиной, тем самым автоматизируя РЕАЛЬНЫЙ ввод (!!!) - и тем самым вы можете запустить утомительные юзабилити-тесты тысяч раз, когда пользователю не нужно нажимать и повторно нажимать и снова повторно нажимать одни и те же вещи снова и снова.

Некоторые описывают такую 3-уровневую архитектуру с 1 или 2 двойными интерфейсами как 4-уровневую или 5-уровневую архитектуру, неявно подразумевая двойные интерфейсы.

Другие случаи включают (но не ограничиваются ими) тот факт, что вы - в случае частично или полностью реплицированных систем баз данных практически сможете рассматривать одну из баз данных как «главную», и, таким образом, у вас будет уровень состоящий из главной и другой содержащий ведомую базу данных.

Мобильный пример

Поэтому многоуровневый - или N-уровневый - действительно имеет несколько интерпретаций, в то время как я бы, конечно, придерживался 3-х уровневых + дополнительных ярусов, состоящих из тонких интерфейсных дисков, вклинивающихся между ними, для обеспечения упомянутых перестановок уровней, и с точки зрения тестирование (особенно используемое на мобильных устройствах) теперь позволяет запускать пользовательские тесты на реальном программном обеспечении, имитируя постукивание пользователей таким образом, который логика управления не может отличить от прослушивания реального пользователя. Это почти первостепенное значение при моделировании реальных пользовательских тестов , поскольку вы можете записывать все входные данные от пользователей OTA, а затем повторно использовать тот же самый вход при выполнении регрессионных тестов.

Когда мы говорим об уровнях, мы обычно говорим о физических процессах (имеющих различное пространство памяти).

Таким образом, в случае, если уровни приложения развернуты в разных процессах, эти разные процессы будут разными уровнями.

Например, в трехуровневом приложении бизнес-уровень связывается с мэйнфреймами (отдельный процесс) и со службой отчетов (отдельный процесс), тогда это приложение будет пятиуровневым.

Следовательно, родовое имя является n-уровневым.

с https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/n-tier

N-уровневая архитектура делит прикладные шины в основном на логические шины и физические уровни, и они делятся на подчасти.

Слои - это способ разделения обязанностей и управления зависимостями. Каждый слой несет определенную ответственность. Более высокий уровень может использовать сервисы более низкого уровня, но не наоборот.

Уровни физически разделены, работают на отдельных машинах. Уровень может напрямую вызывать другой уровень или использовать асинхронный обмен сообщениями (очередь сообщений). Хотя каждый слой может быть размещен на своем собственном уровне, это не обязательно. Несколько слоев могут быть размещены на одном уровне. Физическое разделение уровней улучшает масштабируемость и отказоустойчивость, но также добавляет задержку от дополнительного сетевого взаимодействия.

Традиционное трехуровневое приложение имеет уровень представления, средний уровень и уровень базы данных. Средний уровень не является обязательным. Более сложные приложения могут иметь более трех уровней. На приведенной выше схеме показано приложение с двумя промежуточными уровнями, инкапсулирующее различные области функциональности.

N-уровневое приложение может иметь архитектуру закрытого уровня или архитектуру открытого уровня:

In a closed layer architecture, a layer can only call the next layer immediately down.
In an open layer architecture, a layer can call any of the layers below it.

Архитектура закрытого слоя ограничивает зависимости между слоями. Однако это может создать ненужный сетевой трафик, если один уровень просто передает запросы следующему уровню.

N-уровневое приложение - это приложение, включающее более трех компонентов. Что это за компоненты?

• кэш
• Очереди сообщений для асинхронного поведения
• Балансировщики нагрузки
• Поисковые серверы для поиска по огромным объемам данных
• Компоненты, участвующие в обработке огромных объемов данных
• Компоненты, использующие разнородные технологии, обычно называемые веб-сервисами и т. Д.

Все социальные приложения, такие как Instagram, Facebook, крупные отраслевые сервисы, такие как Uber, Airbnb, многопользовательские онлайн-игры, такие как Pokemon Go, приложения с необычными функциями - n-уровневые приложения.

Мартин Фаулер ясно демонстрирует:

Расслоение является одним из наиболее распространенных методов, которые разработчики программного обеспечения используют для разделения сложной программной системы. Вы видите это в машинных архитектурах, где слои спускаются с языка программирования с вызовами операционной системы в драйверы устройств и наборы команд ЦП, а также в логические элементы внутри чипов. Сеть имеет FTP-уровень поверх TCP, который находится поверх IP, который находится поверх Ethernet.

Размышляя о системе в терминах слоев, вы представляете основные подсистемы в программном обеспечении, организованные в виде слоеного пирога, где каждый слой опирается на нижний уровень. В этой схеме верхний уровень использует различные сервисы, определенные нижним уровнем, но нижний уровень не знает о более высоком уровне. Кроме того, каждый уровень обычно скрывает свои нижние уровни от вышеперечисленных уровней, поэтому уровень 4 использует службы уровня 3, который использует службы уровня 2, но уровень 4 не знает об уровне 2. (Не все многоуровневые архитектуры непрозрачны, как это , но большинство из них - или, скорее, большинство в основном непрозрачные.)

Разбиение системы на слои имеет ряд важных преимуществ.

• Вы можете понимать один слой как единое целое, не зная много о других слоях. Вы можете понять, как создать службу FTP поверх TCP, не зная деталей того, как работает Ethernet.

• Вы можете заменить слои альтернативными реализациями одних и тех же базовых сервисов. Служба FTP может работать без изменений через Ethernet, PPP или любую другую кабельную компанию.

• Вы минимизируете зависимости между слоями. Если кабельная компания меняет свою физическую систему передачи, при условии, что она заставляет работать IP, нам не нужно менять наш FTP-сервис.

• Слои создают хорошие места для стандартизации. TCP и IP являются стандартами, потому что они определяют, как должны работать их уровни.

• После того, как вы создали слой, вы можете использовать его для многих сервисов более высокого уровня. Таким образом, TCP / IP используется FTP, telnet, SSH и HTTP. В противном случае все эти протоколы более высокого уровня должны будут писать свои собственные протоколы более низкого уровня. Из библиотеки Кайла Джеффри Пассарелли

Расслоение является важной техникой, но есть и недостатки.

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

• Дополнительные слои могут повредить производительность. На каждом слое вещи обычно должны быть преобразованы из одного представления в другое. Однако инкапсуляция базовой функции часто дает вам повышение эффективности, которое более чем компенсирует. Слой, который контролирует транзакции, может быть оптимизирован, и тогда все будет быстрее. Но самая сложная часть многоуровневой архитектуры - это решить, какие слои иметь и какова ответственность каждого слоя.