stringtranslate.com

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

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

Архитектура приложений N -уровня предоставляет модель , с помощью которой разработчики могут создавать гибкие и повторно используемые приложения. Разделяя приложение на уровни, разработчики получают возможность изменять или добавлять определенный уровень вместо того, чтобы перерабатывать все приложение. Архитектура N-уровня хорошо подходит для небольших и простых приложений из-за своей простоты и низкой стоимости. Кроме того, она может быть хорошей отправной точкой, когда архитектурные требования еще не ясны. [1] [2] Трехуровневая архитектура обычно состоит из уровня представления , уровня логики и уровня данных .

Хотя концепции слоя и яруса часто используются взаимозаменяемо, одна довольно распространенная точка зрения заключается в том, что действительно есть разница. Согласно этой точке зрения, слой — это логический механизм структурирования для концептуальных элементов, составляющих программное решение, в то время как ярус — это физический механизм структурирования для аппаратных элементов, составляющих системную инфраструктуру. [3] [4] Например, трехслойное решение может быть легко развернуто на одном ярусе, например, в случае архитектуры, ориентированной на экстремальную базу данных, называемой архитектурой RDBMS-only [5] или на персональной рабочей станции. [6]

Слои

Архитектурный шаблон «Слои» был описан в различных публикациях. [7]

Общие слои

В логической многослойной архитектуре информационной системы с объектно-ориентированным дизайном наиболее распространены следующие четыре:

В книге «Проектирование на основе предметной области» описываются некоторые общие примеры использования четырех вышеупомянутых слоев, хотя основное внимание уделяется слою предметной области . [11]

Если архитектура приложения не имеет явного различия между бизнес-слоем и уровнем представления (т. е. уровень представления считается частью бизнес-слоя), то реализуется традиционная клиент-серверная (двухуровневая) модель. [ необходима цитата ]

Более распространенное соглашение заключается в том, что прикладной уровень (или уровень сервиса) считается подуровнем бизнес-уровня, обычно инкапсулирующим определение API, выходящее на поверхность поддерживаемой бизнес-функциональности. Прикладные/бизнес-уровни могут, по сути, быть дополнительно подразделены, чтобы подчеркнуть дополнительные подуровнеи с различной ответственностью. Например, если используется шаблон модель-представление-презентатор , подуровень презентатора может использоваться как дополнительный уровень между уровнем пользовательского интерфейса и уровнем бизнеса/приложения (представленным подуровнем модели). [ необходима цитата ]

Некоторые также выделяют отдельный слой, называемый слоем бизнес-инфраструктуры (BI), расположенный между бизнес-слоем(ями) и слоем(ями) инфраструктуры. Его также иногда называют «низкоуровневым бизнес-слоем» или «слоем бизнес-сервисов». Этот слой очень общий и может использоваться на нескольких уровнях приложений (например, CurrencyConverter). [12]

Уровень инфраструктуры может быть разделен на различные уровни (технические службы высокого или низкого уровня). [12] Разработчики часто фокусируются на возможностях сохранения (доступа к данным) уровня инфраструктуры и поэтому говорят только о уровне сохранения или уровне доступа к данным (вместо уровня инфраструктуры или уровня технических служб). Другими словами, другой вид технических служб не всегда явно рассматривается как часть какого-либо конкретного уровня. [ необходима цитата ] . Уровень доступа к данным обычно содержит объект, известный как объект доступа к данным (DAO) .

Слой находится над другим, потому что зависит от него. Каждый слой может существовать без слоев над ним и требует, чтобы слои под ним функционировали. Другое распространенное мнение заключается в том, что слои не всегда строго зависят только от соседнего слоя ниже. Например, в ослабленной многоуровневой системе (в отличие от строгой многоуровневой системы) слой может также зависеть от всех слоев под ним. [7] У ослабленной многоуровневой системы больше связей, и, следовательно, ее сложнее изменить. Многоуровневые архитектуры могут использовать гибридный подход, так что некоторые слои будут строгими, а другие — ослабленными. [13] [14]

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

Обзор трехуровневого приложения.

Трехуровневая архитектура — это шаблон архитектуры программного обеспечения клиент-сервер , в котором пользовательский интерфейс (представление), функциональная логика процесса («бизнес-правила»), хранилище компьютерных данных и доступ к данным разрабатываются и поддерживаются как независимые модули , чаще всего на отдельных платформах . [15] Она была разработана Джоном Дж. Донованом в Open Environment Corporation (OEC), инструментальной компании, которую он основал в Кембридже, штат Массачусетс .

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

Обычно пользовательский интерфейс работает на настольном ПК или рабочей станции и использует стандартный графический пользовательский интерфейс , функциональную логику процесса, которая может состоять из одного или нескольких отдельных модулей, работающих на рабочей станции или сервере приложений , и СУБД на сервере базы данных или мэйнфрейме , которая содержит логику хранения компьютерных данных. Средний уровень может быть многоуровневым сам по себе (в этом случае общая архитектура называется « n -уровневой архитектурой»). [16]

Уровень презентации
Это самый верхний уровень приложения. Уровень представления отображает информацию, связанную с такими услугами, как просмотр товаров, покупка и содержимое корзины покупок. Он взаимодействует с другими уровнями, посредством которых он выдает результаты на уровень браузера/клиента и все другие уровни в сети. Проще говоря, это уровень, к которому пользователи могут получить прямой доступ (например, веб-страница или графический интерфейс операционной системы).
Уровень приложений (бизнес-логика, логический уровень или средний уровень)
Логический уровень выведен из уровня представления и, как его слой, управляет функциональностью приложения, выполняя детальную обработку.
Уровень данных
Уровень данных включает механизмы сохранения данных (серверы баз данных, общие файловые ресурсы и т. д.) и уровень доступа к данным, который инкапсулирует механизмы сохранения и предоставляет данные. Уровень доступа к данным должен предоставлять API для уровня приложений, который предоставляет методы управления сохраненными данными без предоставления или создания зависимостей от механизмов хранения данных. Избегание зависимостей от механизмов хранения позволяет выполнять обновления или изменения без того, чтобы клиенты уровня приложений были затронуты или даже не знали об изменениях. Как и при разделении любого уровня, существуют затраты на реализацию и часто затраты на производительность в обмен на улучшенную масштабируемость и удобство обслуживания.

Использование веб-разработки

В области веб-разработки термин «трехуровневый» часто используется для обозначения веб-сайтов , обычно сайтов электронной коммерции , которые построены с использованием трех уровней:

  1. Веб-сервер front-end, обслуживающий статический контент и потенциально некоторый кэшированный динамический контент. В веб-приложении front-end — это контент, отображаемый браузером. Контент может быть статическим или генерироваться динамически.
  2. Сервер приложений среднего уровня обработки и генерации динамического контента (например, Symfony , Spring , ASP.NET , Django , Rails , Node.js ).
  3. Внутренняя база данных или хранилище данных , включающее в себя как наборы данных, так и программное обеспечение системы управления базами данных , которое управляет данными и обеспечивает доступ к ним.

Другие соображения

Передача данных между уровнями является частью архитектуры. Вовлеченные протоколы могут включать один или несколько из SNMP , CORBA , Java RMI , .NET Remoting , Windows Communication Foundation , сокетов , UDP , веб-служб или других стандартных или фирменных протоколов. Часто для соединения отдельных уровней используется промежуточное программное обеспечение . Отдельные уровни часто (но не обязательно) работают на отдельных физических серверах, и каждый уровень может сам работать на кластере .

Прослеживаемость

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

Смотрите также

Ссылки

  1. ^ Ричардс, Марк (2020). Основы архитектуры программного обеспечения: инженерный подход (1-е изд.). O'Reilly Media. ISBN 978-1492043454.
  2. ^ Ричардс, Марк (2022). Шаблоны архитектуры программного обеспечения . O'Reilly Media, Inc. ISBN 9781098134273.
  3. ^ Шаблоны развертывания (Microsoft Enterprise Architecture, шаблоны и практики)
  4. ^ Фаулер, Мартин «Шаблоны архитектуры корпоративных приложений» (2002). Эддисон Уэсли.
  5. ^ Висенте, Альфонсо; Эчеверри, Лорена; Сабигеро, Ариэль (2021). «Архитектура RDBMS-only для веб-приложений». XLVII Латиноамериканская компьютерная конференция 2021 г. (CLEI) . стр. 1–9. doi :10.1109/CLEI53233.2021.9640017. ISBN 978-1-6654-9503-5. S2CID  245387844.
  6. ^ Шаблоны развертывания (Microsoft Enterprise Architecture, шаблоны и практики)
  7. ^ аб Бушманн, Франк; Менье, Регина; Ронерт, Ганс; Соммерлад, Питер; Сталь, Михаил (1996–08). Архитектура программного обеспечения, ориентированная на шаблоны, Том 1, Система шаблонов. Уайли, август 1996 г. ISBN 978-0-471-95869-7 . Получено с http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471958697.html. 
  8. ^ Уровень обслуживания Мартина Фаулера
  9. ^ Мартин Фаулер объясняет, что уровень услуг — это то же самое, что и уровень приложений.
  10. ^ Сравнение/обсуждение уровня контроллера GRASP и уровня приложений/сервисов
  11. ^ Domain-Driven Design, книга, стр. 68-74. Получено с http://www.domaindrivendesign.org/books#DDD.
  12. ^ ab Применение UML и шаблонов, 3-е издание, стр. 203 ISBN 0-13-148906-2 
  13. ^ Ричардс, Марк (3 марта 2020 г.). Основы архитектуры программного обеспечения: инженерный подход (1-е изд.). O'Reilly Media. ISBN 978-1492043454.
  14. ^ Ричардс, Марк. Шаблоны архитектуры программного обеспечения . O'Reilly Media, Inc.
  15. ^ Экерсон, Уэйн В. «Трехуровневая архитектура клиент/сервер: достижение масштабируемости, производительности и эффективности в клиент-серверных приложениях». Open Information Systems 10, 1 (январь 1995 г.): 3(20)
  16. ^ Статья основана на материалах, взятых из трехуровневого словаря Free On-line Dictionary of Computing до 1 ноября 2008 года и включенных в соответствии с условиями «перелицензирования» GFDL версии 1.3 или более поздней.

Внешние ссылки