분산 아키텍처

분산 아키텍처에서 구성 요소는 서로 다른 플랫폼에 제공되며 여러 구성 요소가 특정 목표 또는 목표를 달성하기 위해 통신 네트워크를 통해 서로 협력 할 수 있습니다.

이 아키텍처에서 정보 처리는 단일 시스템에 국한되지 않고 여러 독립 컴퓨터에 분산됩니다.
분산 시스템은 다중 계층 아키텍처의 기반을 형성하는 클라이언트-서버 아키텍처에 의해 입증 될 수 있습니다. 대안은 CORBA와 같은 브로커 아키텍처 및 SOA (Service-Oriented Architecture)입니다.
.NET, J2EE, CORBA, .NET 웹 서비스, AXIS Java 웹 서비스 및 Globus Grid 서비스를 포함하여 분산 아키텍처를 지원하는 여러 기술 프레임 워크가 있습니다.
미들웨어는 분산 애플리케이션의 개발 및 실행을 적절하게 지원하는 인프라입니다. 응용 프로그램과 네트워크 사이에 버퍼를 제공합니다.
시스템 중간에 위치하며 분산 시스템의 여러 구성 요소를 관리하거나 지원합니다. 예로는 트랜잭션 처리 모니터, 데이터 변환기 및 통신 컨트롤러 등이 있습니다.

분산 시스템을위한 인프라로서의 미들웨어

분산 아키텍처의 기본은 투명성, 안정성 및 가용성입니다.

다음 표는 분산 시스템에서 다양한 형태의 투명성을 나열합니다.

Sr. 아니.	투명성 및 설명
1	Access 리소스에 액세스하는 방식과 데이터 플랫폼의 차이점을 숨 깁니다.
2	Location 리소스가있는 위치를 숨 깁니다.
삼	Technology 프로그래밍 언어 및 OS와 같은 다양한 기술을 사용자로부터 숨 깁니다.
4	Migration / Relocation 사용중인 다른 위치로 이동할 수있는 리소스를 숨 깁니다.
5	Replication 여러 위치에 복사 할 수있는 리소스를 숨 깁니다.
6	Concurrency 다른 사용자와 공유 할 수있는 리소스를 숨 깁니다.
7	Failure 사용자로부터 리소스의 실패 및 복구를 숨 깁니다.
8	Persistence 리소스 (소프트웨어)가 메모리 또는 디스크에 있는지 여부를 숨 깁니다.

장점

Resource sharing − 하드웨어 및 소프트웨어 리소스 공유.
Openness − 다른 공급 업체의 하드웨어 및 소프트웨어를 사용할 수있는 유연성.
Concurrency − 성능 향상을위한 동시 처리.
Scalability − 새 리소스를 추가하여 처리량을 늘 렸습니다.
Fault tolerance − 오류가 발생한 후에도 계속 작동 할 수있는 기능.

단점

Complexity − 중앙 집중식 시스템보다 더 복잡합니다.
Security − 외부 공격에 더 취약합니다.
Manageability − 시스템 관리에 더 많은 노력이 필요합니다.
Unpredictability − 시스템 구성 및 네트워크 부하에 따라 예측할 수없는 응답.

중앙 집중식 시스템과 분산 형 시스템

기준	중앙 집중식 시스템	분산 시스템
경제학	낮은	높은
유효성	낮은	높은
복잡성	낮은	높은
일관성	단순한	높은
확장 성	가난한	좋은
과학 기술	동종의	이기종
보안	높은	낮은

클라이언트-서버 아키텍처

클라이언트-서버 아키텍처는 시스템을 두 개의 주요 하위 시스템 또는 논리적 프로세스로 분해하는 가장 일반적인 분산 시스템 아키텍처입니다.

Client − 두 번째 프로세스, 즉 서버에 요청을 보내는 첫 번째 프로세스입니다.
Server − 요청을 수신하여 실행하고 클라이언트에게 응답을 보내는 두 번째 프로세스입니다.

이 아키텍처에서 응용 프로그램은 서버에서 제공하는 서비스 집합과 이러한 서비스를 사용하는 클라이언트 집합으로 모델링됩니다. 서버는 클라이언트에 대해 알 필요가 없지만 클라이언트는 서버의 ID를 알아야하며 프로세서와 프로세스의 매핑이 반드시 1 : 1은 아닙니다.

클라이언트-서버 아키텍처는 클라이언트의 기능에 따라 두 가지 모델로 분류 할 수 있습니다.

씬 클라이언트 모델

씬 클라이언트 모델에서는 모든 애플리케이션 처리 및 데이터 관리가 서버에서 수행됩니다. 클라이언트는 단순히 프레젠테이션 소프트웨어를 실행하는 책임이 있습니다.

레거시 시스템이 클라이언트에 구현 된 그래픽 인터페이스를 사용하여 레거시 시스템이 자체적으로 서버 역할을하는 클라이언트 서버 아키텍처로 마이그레이션 될 때 사용됩니다.
가장 큰 단점은 서버와 네트워크 모두에 과도한 처리 부하를가한다는 것입니다.

씩 / 뚱뚱한 클라이언트 모델

씩 클라이언트 모델에서 서버는 데이터 관리 만 담당합니다. 클라이언트의 소프트웨어는 응용 프로그램 논리 및 시스템 사용자와의 상호 작용을 구현합니다.

클라이언트 시스템의 기능을 미리 알고있는 새로운 C / S 시스템에 가장 적합
특히 관리를 위해 씬 클라이언트 모델보다 더 복잡합니다. 모든 클라이언트에 새 버전의 응용 프로그램을 설치해야합니다.

장점

사용자 인터페이스 프레젠테이션 및 비즈니스 로직 처리와 같은 책임 분리.
서버 구성 요소의 재사용 가능성 및 동시성 가능성
분산 응용 프로그램의 설계 및 개발을 단순화합니다.
기존 애플리케이션을 분산 환경으로 쉽게 마이그레이션하거나 통합 할 수 있습니다.
또한 많은 클라이언트가 고성능 서버에 액세스 할 때 리소스를 효과적으로 사용합니다.

단점

요구 사항 변경을 처리 할 이기종 인프라가 부족합니다.
보안 문제.
제한된 서버 가용성 및 안정성.
제한된 테스트 가능성 및 확장 성.
프레젠테이션과 비즈니스 로직을 함께 사용하는 팻 클라이언트.

다중 계층 아키텍처 (n 계층 아키텍처)

다중 계층 아키텍처는 프레젠테이션, 응용 프로그램 처리 및 데이터 관리와 같은 기능이 물리적으로 분리 된 클라이언트-서버 아키텍처입니다. 애플리케이션을 계층으로 분리함으로써 개발자는 전체 애플리케이션을 재 작업하는 대신 특정 계층을 변경하거나 추가하는 옵션을 얻을 수 있습니다. 개발자가 유연하고 재사용 가능한 애플리케이션을 만들 수있는 모델을 제공합니다.

다 계층 아키텍처의 가장 일반적인 용도는 3 계층 아키텍처입니다. 3 계층 아키텍처는 일반적으로 프레젠테이션 계층, 애플리케이션 계층 및 데이터 스토리지 계층으로 구성되며 별도의 프로세서에서 실행될 수 있습니다.

프레젠테이션 계층

프리젠 테이션 계층은 사용자가 웹 페이지 또는 운영 체제 GUI (그래픽 사용자 인터페이스)와 같이 직접 액세스 할 수있는 애플리케이션의 최상위 레벨입니다. 이 계층의 주요 기능은 작업과 결과를 사용자가 이해할 수있는 것으로 변환하는 것입니다. 다른 계층과 통신하여 결과를 브라우저 / 클라이언트 계층과 네트워크의 다른 모든 계층에 배치합니다.

애플리케이션 계층 (비즈니스 논리, 논리 계층 또는 중간 계층)

애플리케이션 계층은 애플리케이션을 조정하고, 명령을 처리하고, 논리적 결정을 내리고, 평가하고, 계산을 수행합니다. 세부 처리를 수행하여 응용 프로그램의 기능을 제어합니다. 또한 두 개의 주변 레이어 사이에서 데이터를 이동하고 처리합니다.

데이터 계층

이 계층에서 정보는 데이터베이스 또는 파일 시스템에서 저장 및 검색됩니다. 그런 다음 정보는 처리를 위해 다시 전달 된 다음 사용자에게 다시 전달됩니다. 여기에는 데이터 지속성 메커니즘 (데이터베이스 서버, 파일 공유 등)이 포함되며 저장된 데이터를 관리하는 방법을 제공하는 API (Application Programming Interface)를 애플리케이션 계층에 제공합니다.

Advantages

씬 클라이언트 접근 방식보다 성능이 우수하고 씩 클라이언트 접근 방식보다 관리가 더 간단합니다.
재사용 성과 확장 성을 향상시킵니다. 수요가 증가하면 추가 서버를 추가 할 수 있습니다.
멀티 스레딩 지원을 제공하고 네트워크 트래픽도 줄입니다.
유지 보수성과 유연성 제공

Disadvantages

테스트 도구 부족으로 인해 만족스럽지 못한 테스트 가능성.
더 중요한 서버 안정성 및 가용성.

브로커 아키텍처 스타일

브로커 아키텍처 스타일은 등록 된 서버와 클라이언트 간의 통신을 조정하고 활성화하기 위해 분산 컴퓨팅에 사용되는 미들웨어 아키텍처입니다. 여기서 객체 통신은 객체 요청 브로커 (소프트웨어 버스)라는 미들웨어 시스템을 통해 이루어집니다.

클라이언트와 서버는 서로 직접 상호 작용하지 않습니다. 클라이언트와 서버는 중개자 브로커와 통신하는 프록시에 직접 연결됩니다.
서버는 브로커에 인터페이스를 등록하고 게시하여 서비스를 제공하며 클라이언트는 조회를 통해 정적으로 또는 동적으로 브로커에 서비스를 요청할 수 있습니다.
CORBA (Common Object Request Broker Architecture)는 브로커 아키텍처의 좋은 구현 예입니다.

브로커 아키텍처 스타일의 구성 요소

브로커 아키텍처 스타일의 구성 요소는 다음 헤드를 통해 논의됩니다.

Broker

브로커는 결과 및 예외 전달 및 발송과 같은 통신 조정을 담당합니다. 클라이언트가 메시지를 보내는 호출 지향 서비스, 문서 또는 메시지 지향 브로커 일 수 있습니다.

서비스 요청을 중개하고, 적절한 서버를 찾고, 요청을 전송하고, 클라이언트에 응답을 보내는 일을 담당합니다.
위치 정보는 물론 기능과 서비스를 포함한 서버의 등록 정보를 유지합니다.
클라이언트가 요청하는 API, 응답 할 서버, 서버 구성 요소 등록 또는 등록 해제, 메시지 전송 및 서버 찾기를 제공합니다.

Stub

스텁은 정적 컴파일 시간에 생성 된 다음 클라이언트의 프록시로 사용되는 클라이언트 측에 배포됩니다. 클라이언트 측 프록시는 클라이언트와 브로커 사이의 중재자 역할을하며 클라이언트와 클라이언트 사이에 추가적인 투명성을 제공합니다. 원격 개체는 로컬 개체처럼 나타납니다.

프록시는 프로토콜 수준에서 IPC (프로세스 간 통신)를 숨기고 매개 변수 값을 마샬링하고 서버에서 결과를 마샬링 해제합니다.

Skeleton

스켈레톤은 서비스 인터페이스 컴파일에 의해 생성 된 다음 서버에 대한 프록시로 사용되는 서버 측에 배포됩니다. 서버 측 프록시는 낮은 수준의 시스템 특정 네트워킹 기능을 캡슐화하고 서버와 브로커 사이를 중재하기위한 높은 수준의 API를 제공합니다.

요청을 수신하고, 요청을 압축 해제하고, 메서드 인수를 마샬링하고, 적절한 서비스를 호출하고, 결과를 다시 클라이언트로 보내기 전에 마샬링합니다.

Bridge

브리지는 서로 다른 통신 프로토콜을 기반으로 두 개의 서로 다른 네트워크를 연결할 수 있습니다. DCOM, .NET 원격 및 Java CORBA 브로커를 포함한 다양한 브로커를 중재합니다.

브리지는 선택적 구성 요소로, 두 브로커가 상호 운용 될 때 구현 세부 정보를 숨기고 하나의 형식으로 요청과 매개 변수를 가져 와서 다른 형식으로 변환합니다.

Broker implementation in CORBA

CORBA는 OMG (객체 관리 그룹)에서 정의한 분산 객체 간의 통신을 관리하는 미들웨어 인 Object Request Broker의 국제 표준입니다.

서비스 지향 아키텍처 (SOA)

서비스는 잘 정의되고, 독립적이고, 독립적이며, 게시되고, 표준 프로그래밍 인터페이스를 통해 사용할 수있는 비즈니스 기능의 구성 요소입니다. 서비스 간의 연결은 서비스간에 요청과 응답을 느슨하게 전달할 수있는 SOAP 웹 서비스 프로토콜과 같은 공통 및 범용 메시지 지향 프로토콜에 의해 수행됩니다.

서비스 지향 아키텍처는 애플리케이션이 소프트웨어 서비스 및 소프트웨어 서비스 소비자 (클라이언트 또는 서비스 요청 자라고도 함)로 구성된 비즈니스 중심 IT 접근 방식을 지원하는 클라이언트 / 서버 설계입니다.

SOA의 특징

서비스 지향 아키텍처는 다음과 같은 기능을 제공합니다.

Distributed Deployment − 엔터프라이즈 데이터와 비즈니스 로직을 서비스라고하는 느슨하고, 결합되고, 검색 가능하고, 구조화되고, 표준 기반이며, 조악하고, 상태 비 저장 기능 단위로 노출됩니다.
Composability − 잘 정의되고 게시 된 표준 불만 인터페이스를 통해 원하는 세분화로 노출 된 기존 서비스에서 새로운 프로세스를 조립합니다.
Interoperability − 기본 프로토콜 또는 구현 기술에 관계없이 네트워크에서 기능을 공유하고 공유 서비스를 재사용합니다.
Reusability − 서비스 제공자를 선택하고 서비스로 노출 된 기존 리소스에 액세스합니다.

SOA 운영

다음 그림은 SOA가 어떻게 작동하는지 보여줍니다.

Advantages

서비스 지향의 느슨한 결합은 기업이 플랫폼 및 기술 제한에 관계없이 사용 가능한 모든 서비스 자원을 사용할 수있는 뛰어난 유연성을 제공합니다.
각 서비스 구성 요소는 상태 비 저장 서비스 기능으로 인해 다른 서비스와 독립적입니다.
서비스 구현은 노출 된 인터페이스가 변경되지 않는 한 서비스의 응용 프로그램에 영향을주지 않습니다.
클라이언트 또는 모든 서비스는 플랫폼, 기술, 공급 업체 또는 언어 구현에 관계없이 다른 서비스에 액세스 할 수 있습니다.
서비스 클라이언트는 공용 인터페이스, 서비스 구성 만 알면되기 때문에 자산 및 서비스의 재사용 가능성.
SOA 기반 비즈니스 애플리케이션 개발은 시간과 비용면에서 훨씬 더 효율적입니다.
확장 성을 향상시키고 시스템 간의 표준 연결을 제공합니다.
'비즈니스 서비스'의 효율적이고 효과적인 사용.
통합이 훨씬 쉬워지고 내부 상호 운용성이 향상됩니다.
개발자를위한 복잡성을 추상화하고 최종 사용자에게 더 가까운 비즈니스 프로세스를 활성화합니다.