3계층 아키텍처

3계층 아키텍처 소개

3계층 아키텍처는 인터넷에서 가장 일반적인 상호 작용 아키텍처입니다. 2계층 서버 부분을 논리 계층 과 데이터 계층의 두 부분으로 나누었을 때 나타났습니다 .

다음과 같이 생겼습니다.

클라이언트 계층은 사용자 상호 작용을 담당하는 "분산 응용 프로그램"의 일부입니다. 이 계층은 비즈니스 로직을 포함하지 않아야 하며 중요한 데이터를 저장하지 않아야 합니다. 또한 데이터베이스 계층과 직접 상호 작용하지 말고 비즈니스 논리 계층을 통해서만 상호 작용해야 합니다.

그러나 여기에는 여전히 몇 가지 논리가 있습니다. 첫째, 이것은 인터페이스를 통한 사용자와의 상호 작용, 사용자가 입력한 데이터의 유효성 검사, 로컬 파일 작업입니다. 여기에는 서버 작업 시 사용자 인증 및 데이터 암호화와 관련된 모든 것이 포함됩니다.

둘째, 간단한 비즈니스 로직입니다. 예를 들어 온라인 상점에서 제품 목록을 보낸 경우 클라이언트 측에서 제품 목록을 정렬하고 필터링할 수 있습니다. 캐싱, 로그인한 사용자 쿠키 등의 기본 데이터 저장소도 여기에 있습니다.

비즈니스 로직 계층은 두 번째 수준에 있으며 대부분의 비즈니스 로직이 여기에 집중되어 있습니다. 외부에는 클라이언트로 내보내진 조각과 데이터베이스에 포함된 논리 요소(저장 프로시저 및 트리거)만 남아 있습니다.

비즈니스 논리 서버의 대부분은 이와 동일한 논리를 포함할 뿐만 아니라 확장 문제도 해결합니다. 즉, 코드가 여러 부분으로 나뉘어 여러 서버에 배포됩니다. 수요가 많은 일부 서비스는 수십 대의 서버에서 실행될 수 있습니다. 그들 사이의 부하는 로드 밸런서에 의해 관리됩니다.

서버 응용 프로그램은 일반적으로 서버의 다른 복사본을 쉽게 시작하고 다른 복사본과 협력하여 작업을 시작할 수 있는 방식으로 설계됩니다. 즉, 서버 코드를 작성하는 과정에서도 정적 클래스가 단일 인스턴스에서 시작된다는 보장이 없습니다.

데이터 계층은 데이터 저장소를 제공하고 별도의 수준에 배치되며 원칙적으로 데이터베이스 관리 시스템(DBMS)을 통해 구현되며 이 구성 요소에 대한 연결은 애플리케이션 서버 수준에서만 제공됩니다.

데이터 레이어를 분리하는 이유

데이터 레이어를 본격적인 세 번째 레이어로 분리하는 데는 여러 가지 이유가 있지만 주요 원인은 서버의 부하 증가입니다.

첫째, 데이터베이스는 데이터 처리를 위해 많은 메모리 와 프로세서 시간을 필요로 하기 시작했습니다. 따라서 그들은 별도의 서버에 모든 곳에 배치되기 시작했습니다.

부하가 증가하면 백엔드를 쉽게 복제할 수 있고 한 서버의 복사본 10개를 올릴 수 있지만 데이터베이스를 복제하는 것은 불가능했습니다. 데이터베이스는 여전히 시스템의 단일하고 분할할 수 없는 구성 요소로 남아 있습니다.

둘째, 데이터베이스가 똑똑해졌습니다 . 자체 비즈니스 로직이 있습니다. 저장 프로시저, 트리거, PLSQL과 같은 자체 언어를 지원하기 시작했습니다. 그리고 DBMS 내부에서 실행되는 코드를 작성하기 시작한 프로그래머도 등장했습니다.

데이터에 연결되지 않은 모든 논리는 백엔드로 가져와 수십 개의 서버에서 병렬로 실행되었습니다. 데이터와 결정적으로 연결된 모든 것은 DBMS 내부에 남아 있었고, 이미 자체적인 방법을 사용하여 증가된 부하 문제를 해결해야 했습니다.

• 데이터베이스 클러스터는 동일한 데이터를 저장하고 특정 프로토콜을 사용하여 동기화하는 데이터베이스 서버 그룹입니다.
• 샤딩 - 데이터가 논리적 블록으로 분할되고 여러 데이터베이스 서버에 분산됩니다. 이 접근 방식으로 데이터베이스 변경 사항을 유지 관리하는 것은 매우 어렵습니다.
• NoSQL 접근 방식은 엄청난 양의 데이터를 저장하도록 구축된 데이터베이스에 데이터를 저장하는 것입니다. 이들은 종종 데이터베이스가 아니라 특정 파일 저장소입니다. 관계형 데이터베이스에 비해 기능이 매우 부족합니다.
• 데이터 캐싱. 데이터베이스 수준의 단순 캐시 대신 전체 캐싱 DBMS가 등장하여 결과를 메모리에만 저장했습니다.

이 서버 기술 동물원을 관리하려면 별도의 사람 및/또는 전체 팀이 필요했으며 이로 인해 데이터 계층이 별도의 계층으로 제거되었습니다.

중요한! 모든 첨단 기술은 오래된 접근 방식이 더 이상 새로운 도전에 대처할 수 없는 대규모 IT 기업의 깊은 곳에서 탄생합니다. 데이터베이스를 별도의 계층으로 만드는 것은 어떤 프로그래머가 발명한 것이 아니라 Oracle 또는 IBM 깊이 있는 엔지니어 그룹에 의해 발명되었습니다.

흥미로운! Zuckerberg가 Facebook을 작성하기 시작했을 때 그는 단순히 PHP + MySQL에서 작업했습니다. 수백만 명의 사용자가 있었을 때 그들은 모든 PHP 코드를 C ++로 번역하고 네이티브 기계 코드로 컴파일하는 특수 번역기를 작성했습니다.

또한 MySQL은 수십억 사용자의 데이터를 저장할 수 없기 때문에 Facebook은 NoSQL 데이터베이스 개념을 개발하고 강력한 서버 측 NoSQL DBMS인 Cassandra를 작성했습니다. 그건 그렇고, 그것은 완전히 Java로 작성되었습니다.

애플리케이션 로직 위치 모호성

그리고 3계층 아키텍처는 부분 간에 역할을 거의 명확하게 분배하지만 시스템에서 비즈니스 논리의 새로운 부분(새 코드)을 추가해야 하는 위치를 정확하게 결정하는 것이 항상 가능한 것은 아닙니다.

이러한 모호성의 예가 아래 그림에 나와 있습니다.

서버 부분은 회색 배경으로 채워지고 클라이언트 부분은 흰색으로 채워집니다. 후자의 접근 방식(맨 오른쪽)의 좋은 예는 최신 모바일 앱입니다. 클라이언트 측(전화기)에는 보기(디스플레이), 논리 및 데이터가 포함됩니다. 때로는 이 데이터가 서버와 동기화됩니다.

가장 왼쪽 옵션의 예는 서버에 모든 논리가 있고 클라이언트에 이미 정적 HTML을 제공하는 일반적인 PHP 서버입니다. 이 두 극단 사이 어딘가에 프로젝트가 있습니다.

작업을 시작할 때 프로젝트에 대해 알게 된 후 다음 작업의 논리를 구현하는 것이 더 나은 위치에 대해 작업 중인 프로그래머와 상의해야 합니다.

자유롭게 그렇게 하십시오. 첫째, 그들은 헌장을 가지고 다른 사람의 수도원에 올라가지 않습니다. 둘째, 모든 사람(및 귀하도)이 코드를 찾을 것으로 예상되는 장소에서 필요한 코드를 더 쉽게 찾을 수 있습니다.