멀티티어 아키텍처
Multitier architecture소프트웨어 엔지니어링에서 다중 계층 아키텍처(흔히 n-tier 아키텍처라고 함)는 프레젠테이션, 애플리케이션 처리 및 데이터 관리 기능이 물리적으로 분리된 클라이언트-서버 아키텍처다.다중 계층 아키텍처의 가장 널리 사용되는 것은 3계층 아키텍처다.
N-계층 애플리케이션 아키텍처는 개발자들이 유연하고 재사용 가능한 애플리케이션을 만들 수 있는 모델을 제공한다.애플리케이션을 계층으로 분리함으로써, 개발자들은 전체 애플리케이션을 재작업하는 대신 특정 계층을 수정하거나 추가하는 옵션을 얻는다.3계층 아키텍처는 일반적으로 프레젠테이션 계층, 로직 계층 및 데이터 계층으로 구성된다.
계층과 계층의 개념은 종종 서로 교환하여 사용되지만, 한 가지 일반적인 관점은 실제로 차이가 있다는 것이다.이 견해는 계층은 시스템 인프라에 대한 물리적 구조 메커니즘인 반면 계층은 소프트웨어 솔루션을 구성하는 요소들에 대한 논리적 구조 메커니즘이라고 주장한다.[1][2]예를 들어, RDBMS 전용 아키텍처라 불리는 극단적인[3] 데이터베이스 중심 아키텍처의 경우나 개인 워크스테이션에 3계층 솔루션을 쉽게 배치할 수 있다.[4]
레이어
"레이어" 건축 양식은 다양한 출판물에 설명되어 왔다.[5]
공통층
객체 지향 설계를 가진 정보 시스템의 논리적 다층 구조에서 다음 4가지는 가장 흔하다.
- 프리젠테이션 레이어(a.k.a.다중 계층 아키텍처의 UI 계층, 보기 계층, 프레젠테이션 계층)
- 애플리케이션 계층(예: 서비스 계층[6][7] 또는 AHIGH 컨트롤러 계층 )
- 비즈니스 계층(예: 비즈니스 로직 계층(BLL), 도메인 로직 계층)
- 데이터 액세스 계층(예: 특정 비즈니스 계층을 지원하는 데 필요한 지속성 계층, 로깅, 네트워킹 및 기타 서비스)
책 도메인 중심 설계는 그것의 주요 초점이 도메인 계층이지만 위의 4개 계층에 대한 몇 가지 일반적인 용도를 설명한다.[9]
애플리케이션 아키텍처가 비즈니스 계층과 프리젠테이션 계층(즉, 프레젠테이션 계층은 비즈니스 계층의 일부로 간주됨)을 명확히 구분하지 않는다면, 전통적인 클라이언트-서버(2계층) 모델이 구현된 것이다.[citation needed]
더 일반적인 관례는 애플리케이션 계층(또는 서비스 계층)을 비즈니스 계층의 하위 계층으로 간주하는 것으로, 일반적으로 지원되는 비즈니스 기능성을 서핑하는 API 정의를 캡슐화한다.실제로 애플리케이션/비즈니스 계층은 뚜렷한 책임의 하위 계층을 추가로 강조하기 위해 더 세분화될 수 있다.예를 들어, 모델-뷰-프레젠더 패턴을 사용하는 경우, 발표자 하위 계층은 사용자 인터페이스 계층과 비즈니스/애플리케이션 계층 사이의 추가 계층으로 사용될 수 있다(모델 하위 계층으로 표현됨).[citation needed]
일부는 또한 비즈니스 계층과 인프라 계층 사이에 위치한 BI(비즈니스 인프라 계층)라고 불리는 별도의 계층을 식별한다."저수준 비즈니스 계층" 또는 "비즈니스 서비스 계층"이라고도 한다.이 계층은 매우 일반적이며 여러 애플리케이션 계층(예: CurrentConverter)에서 사용할 수 있다.[10]
인프라 계층은 다른 레벨(고급 또는 저급 기술 서비스)로 분할할 수 있다.[10]개발자들은 종종 인프라 계층의 지속성(데이터 액세스) 기능에 초점을 맞추고, 따라서 (인프라 계층이나 기술 서비스 계층 대신) 지속성 계층이나 데이터 액세스 계층에 대해서만 이야기한다.다시 말해, 다른 종류의 기술 서비스는 특정 계층의 일부로 항상 명시적으로 생각되는 것은 아니다.[citation needed]
한 겹은 다른 층 위에 있다. 왜냐하면 그것은 그것에 의존하기 때문이다.모든 계층은 그 위의 계층 없이 존재할 수 있으며, 그 아래 계층이 기능하도록 요구한다.또 다른 일반적인 견해는 계층이 항상 아래의 인접한 계층에만 엄격하게 의존하는 것은 아니라는 것이다.예를 들어, 완화된 계층화된 시스템에서(엄격한 계층화된 시스템과 반대로) 계층은 그 아래 모든 계층에 의존할 수도 있다.[5]
3계층 아키텍처
3계층 아키텍처는 사용자 인터페이스(프레젠테이션), 기능 프로세스 논리("비즈니스 규칙"), 컴퓨터 데이터 스토리지 및 데이터 액세스가 독립된 모듈로서 개발되고 유지되는 클라이언트-서버 소프트웨어 아키텍처 패턴이다.[11]존 도노반이 매사추세츠주 케임브리지에 설립한 공구회사 OEC(Open Environment Corporation)에서 개발한 것이다.
인터페이스가 잘 정의된 모듈형 소프트웨어의 일반적인 장점과는 별개로, 3계층 아키텍처는 요구사항이나 기술의 변화에 대응하여 3개 계층 중 어느 한 계층이라도 독립적으로 업그레이드 또는 교체할 수 있도록 하기 위한 것이다.예를 들어, 프리젠테이션 계층의 운영 체제의 변경은 사용자 인터페이스 코드에만 영향을 미칠 것이다.
일반적으로 사용자 인터페이스는 데스크톱 PC 또는 워크스테이션에서 실행되며 표준 그래픽 사용자 인터페이스, 워크스테이션 또는 애플리케이션 서버에서 실행되는 하나 이상의 개별 모듈로 구성될 수 있는 기능 프로세스 논리 및 컴퓨터 데이터 저장 논리를 포함하는 데이터베이스 서버 또는 메인프레임의 RDBMS를 사용한다.중간 계층은 다중 계층 그 자체일 수 있다(이 경우 전체 아키텍처를 "n-tier 아키텍처"라고 한다).
- 프레젠테이션 계층
- 이것은 응용 프로그램의 가장 높은 수준이다.프레젠테이션 계층은 상품 검색, 구매 및 쇼핑 카트 컨텐츠와 같은 서비스와 관련된 정보를 표시한다.그것은 결과를 브라우저/클라이언트 계층 및 네트워크의 다른 모든 계층에 제공하는 다른 계층과 통신한다.간단히 말하면, 그것은 사용자가 직접 접근할 수 있는 계층이다(예: 웹 페이지 또는 운영 체제의 GUI).
- 애플리케이션 계층(비즈니스 로직, 로직 계층 또는 미들 계층)
- 논리 계층은 프리젠테이션 계층에서 제외되며, 그것의 자체 계층으로서, 그것은 상세한 처리를 수행함으로써 애플리케이션의 기능을 제어한다.
- 데이터 계층
- 데이터 계층에는 데이터 지속성 메커니즘(데이터베이스 서버, 파일 공유 등)과 지속성 메커니즘을 캡슐화하고 데이터를 노출시키는 데이터 액세스 계층이 포함된다.데이터 액세스 계층은 데이터 스토리지 메커니즘에 대한 의존성을 노출하거나 생성하지 않고 저장된 데이터를 관리하는 방법을 노출하는 API를 애플리케이션 계층에 제공해야 한다.스토리지 메커니즘의 종속성을 방지하면 애플리케이션 계층 클라이언트가 변경의 영향을 받거나 심지어 인식하지 않아도 업데이트 또는 변경이 가능하다.모든 계층의 분리와 마찬가지로, 확장성과 유지 보수성을 향상시키는 대가로 구현 비용과 성능 비용이 발생하는 경우가 많다.
웹 개발 사용법
웹 개발 분야에서는 흔히 전자 상거래 웹사이트인 웹 사이트를 지칭하기 위해 3개 계층을 사용하는 경우가 많은데, 이 웹사이트는 다음과 같은 3개 계층을 사용하여 구축된다.
- 정적 콘텐츠를 제공하는 프런트 엔드 웹 서버 및 잠재적으로 캐시된 동적 콘텐츠.웹 기반 응용프로그램에서 프런트 엔드는 브라우저에 의해 렌더링된 콘텐츠다.콘텐츠는 정적이거나 동적으로 생성될 수 있다.
- 중간 수준의 동적 컨텐츠 처리 및 생성 레벨 애플리케이션 서버(예: Symfony, Spring, ASP)NET, 장고, 레일즈, 노드.js.
- 데이터 세트와 데이터를 관리하고 데이터에 대한 액세스를 제공하는 데이터베이스 관리 시스템 소프트웨어로 구성된 백엔드 데이터베이스 또는 데이터 저장소.
기타 고려사항
계층 간의 데이터 전송은 아키텍처의 일부분이다.관련된 프로토콜은 하나 이상의 SNMP, CORBA, Java RMI, .NET 원격 설정, Windows Communication Foundation, 소켓, UDP, 웹 서비스 또는 기타 표준 또는 독점 프로토콜을 포함할 수 있다.종종 미들웨어는 별도의 계층을 연결하는 데 사용된다.별도의 계층은 별도의 물리적 서버에서 실행되는 경우가 많으며(필수는 아니지만) 각 계층 자체가 클러스터에서 실행되는 경우도 있다.
추적성
n-계층 시스템을 통한 데이터 흐름의 엔드 투 엔드 추적성은 시스템의 복잡성이 증가할 때 더욱 중요해지는 어려운 작업이다.Application Response Measurement는 성능을 측정하고 계층 간의 트랜잭션을 상호 연관시키기 위한 개념과 API를 정의한다.일반적으로, "티어"라는 용어는 별도의 서버, 컴퓨터 또는 네트워크(처리 노드)에 있는 시스템 구성요소의 물리적 분배를 기술하기 위해 사용된다.그러면 3계층 아키텍처는 3개의 처리 노드를 가질 것이다."레이어"라는 용어는 하나의 처리 노드에 물리적으로 위치하거나 위치하지 않을 수 있는 구성요소의 논리적 그룹을 말한다.
참고 항목
- 추상화층
- 클라이언트-서버 모델
- 데이터베이스 중심 아키텍처
- 프런트 엔드 및 백엔드
- 계층적 인터넷 작업 모델
- 로드 밸런싱(컴퓨팅)
- 획일적 응용
- 개방형 서비스 아키텍처
- 리치 웹 애플리케이션
- 서비스 계층
- 피복층
- 웹 응용 프로그램
참조
- ^ 배포 패턴(Microsoft Enterprise Architecture, 패턴 및 관행)
- ^ Fowler, Martin "엔터프라이즈 애플리케이션 아키텍처의 패턴"(2002)애디슨 웨슬리
- ^ Vicente, Alfonso; Etcheverry, Lorena; Sabiguero, Ariel (2021). "An RDBMS-only architecture for web applications". 2021 XLVII Latin American Computing Conference (CLEI): 1–9. doi:10.1109/CLEI53233.2021.9640017.
- ^ 배포 패턴(Microsoft Enterprise Architecture, 패턴 및 관행)
- ^ a b 부슈만, 프랭크, 메우니에, 레긴, 로네르트, 한스, 소머라드, 피터, 스탈, 마이클(1996-08).패턴 지향 소프트웨어 아키텍처, 제1권, 패턴 시스템.와일리, 1996년 8월ISBN 978-0-471-95869-7http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471958697.html에서 검색됨.
- ^ 마틴 파울러의 서비스 계층
- ^ Martin Fowler는 서비스 계층이 애플리케이션 계층과 동일하다고 설명
- ^ HIGH 컨트롤러 계층 비교/토론애플리케이션/서비스 계층
- ^ 도메인 중심 설계, 책 페이지 68-74.http://www.domaindrivendesign.org/books#DDD에서 검색됨.
- ^ a b IMT-2000 3GPP-UML과 패턴 적용, 제3판, 203페이지 ISBN 0-13-148906-2
- ^ Eckerson, Wayne W. "3계층 클라이언트/서버 아키텍처:클라이언트 서버 애플리케이션에서 확장성, 성능 및 효율성 달성."정보 시스템 열기 10, 1(1995년 1월): 3(20)