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

Для использования в других целях см. Трехуровневая система.

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

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

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

Слои

"Слои" архитектурный образец был описан в различных публикациях.[4]

Общие слои

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

Книга Доменно-ориентированный дизайн описывает некоторые общие способы использования вышеуказанных четырех слоев, хотя его основное внимание уделяется уровень домена.[8]

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

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

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

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

Один слой находится поверх другого, потому что это зависит от него. Каждый слой может существовать без слоев над ним, и для работы требуются уровни под ним. Другое распространенное мнение состоит в том, что слои не всегда строго зависят только от соседнего слоя ниже. Например, в расслабленной многослойной системе (в отличие от строгой многоуровневой системы) слой также может зависеть от всех нижележащих слоев.[4]

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

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

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

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

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

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

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

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

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

Прочие соображения

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

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

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

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

Рекомендации

  1. ^ Шаблоны развертывания (Корпоративная архитектура Microsoft, шаблоны и практики)
  2. ^ Фаулер, Мартин «Шаблоны архитектуры корпоративных приложений» (2002). Эддисон Уэсли.
  3. ^ Шаблоны развертывания (корпоративная архитектура, шаблоны и методы Microsoft)
  4. ^ а б Бушманн, Франк; Менье, Регина; Ронерт, Ганс; Соммерлад, Питер; Сталь, Михаил (1996-08). Шаблонно-ориентированная архитектура программного обеспечения, Том 1, Система шаблонов. Wiley, август 1996 г. ISBN  978-0-471-95869-7. Извлекаются из http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471958697.html.
  5. ^ Уровень обслуживания Мартина Фаулера
  6. ^ Мартин Фаулер объясняет, что уровень обслуживания совпадает с уровнем приложения.
  7. ^ Сравнение / обсуждение уровня контроллера GRASP и уровня приложения / сервиса
  8. ^ Домен-ориентированный дизайн, книга, стр. 68-74. Извлекаются из http://www.domaindrivendesign.org/books#DDD.
  9. ^ а б Применение UML и шаблонов, Издание 3-е, стр. 203 ISBN  0-13-148906-2
  10. ^ Экерсон, Уэйн В. «Трехуровневая архитектура клиент / сервер: достижение масштабируемости, производительности и эффективности клиент-серверных приложений». Открытые информационные системы 10, 1 (январь 1995): 3 (20)

внешняя ссылка