[ENG][아키텍처]Architecture Styles

Active Repository Architecture Style

이 스타일은 리포지토리의 데이터 세트가 응용 프로그램( 예: 접근 모듈)에서 수동으로 액세스하는 공유 리포지토리 아키텍처 스타일을 약간 수정한 것입니다. 데이터세트 의 수동적 공유 는 Active Repository 아키텍처 스타일에서 능동 공유 로 변경됩니다 . 활성 저장소 는 구독자, 즉 응용 프로 그램의 레지스트리를 유지 관리하고 저장소 업데이트 이벤트를 구독자에게 적극적으로 알립니다. 

 

Batch Sequential Style

대용량 처리에 용이
구성 요소가 완료될 때까지 실행되고 다음 구성 요소가 시작되기 전에 전체 출력을 전송합니다. 사용자는 실행 중에 시스템과 상호 작용하지 않습니다. 그들은 출력을 받기 위해 실행이 끝날 때까지 기다립니다.
각 Sub System을 독립적으로 처리하는 프로그램이 될 수 있다.

cons : 대기시간이 길고, 대화식 인터페이스 제공 불가, 동시성 미지원 

 

Blackboard Style

Shared data, database와 같은 데이터 중심 패턴 중에 하나
명확히 정의된 문제 해법이 없을 때 문제를 풀어가는 하나의 방식을 정의한 패턴
대략적으로 해법을 수립하기 위해 특수한 서비스 시스템의 지식을 조합하는 패턴

pros : 완벽한 해법을 찾기 어려운 경우에 사용할 수 있음; 다양한 실험 가능
KS, Control, Blackboard 가 독립적으로 동작하여 가변성이나 유지보수 성이 좋음
KS는 타 문제 도메인에 재사용될 수 있음
장애 허용(Fault tolerance)과 저항성(robustness)을 지원함 

cons : 계산 결과가 항상 동일하지 않아 테스트가 어려움
어떤 좋은 해법도 완벽하다고 장담할 수 없음
좋은 전략 수립 어려움; 효율이 낮음
많은 시간에 걸쳐 수정되어야 하므로 개발에 많은 노력이 필요

 

Broker Style

아키텍처는 특정 시스템 혹은 특정 구현의 세 부 사항을 컴포넌트나 서비스 사용자로부터 숨겨야 함
Broker 컴포넌트가 클라이언트와 서버의 정보를 가지고 있어 서로간의 통신을 조율
클라이언트와 서버 Proxy를 두어 특정 환경과 관련된 부분을 처리
브로커는 그때그때마다 서버 호출이 바뀔수 있다 Stateless <-> 디스패처는 Dedicated 

pros : 
컴포넌트간의 위치 투명성, 컴포넌트의 가변성(Changeability)과 확장성(Extensibility)이 보장, 플랫폼 간의 이식가능성(Portability) 제공함, 재사용 컴포넌트 확보에 용이(Reusability)

cons : 
성능에 대한 불이익, 브로커 장애 발생 시를 대비해, 컴포넌트를 복제해 둠으로써 신뢰성을 보장해야 함, 테스트 디버깅의 복잡함

 

Client-Sever Style

pros : 분산 환경에서 UI presentation와 business logic의 분리에 용이함.
Server의 reusability가 높음.

cons : 요구 사항 변경시 client/server 양단을 변경해야하는 번거로움이 있음.
Server의 가용성, 안정성을 유지하는데 어려움이 있음.
Server/Client가 분산되어 있어 보다 복잡하고 어려운 보안 이슈가 발생할 수 있음

 

Dispatch Style

QoS evaluator랑 Sever allocator

pros : 서버의 교환가능성 보장, 서버의 위치 투명성 보장, 서버의 재구성 가능, 장애 허용성 보장, availability가 높아짐, Scalability가 높아짐.

cons : 명시적이며 우회적인 연결을 설정하기 때문에 효율성이 낮음, 디스패처 컴포넌트의 인터페이스에 발생하는 변경에 민감함

 

Edge Style

pros : 응답 지연(Latency) 감소, 대역폭(Bandwidth) 요구 감소, 신뢰성(Reliability) 증가

cons : 저장매체가 제한이 됨, 전원의 소모가 큼

 

Layered Style

각 레이어는 펑션콜이지 네트웍이 아니다
소프트웨어를 레이어 단위로 분할
각 레이어는 인터페이스를 가진 가상 머신(virtual machine) 
가상 머신은 엄격한 순서 관계에 따라 상호작용

하위 레이어의 변경은 인터페이스 뒤에서 은폐됨
하위 레이어의 변경이 상위 레이어에 영향을 미치지 않음

시스템의 규모가 커서 분해할 필요가 있을 경우
하위 레벨과 상위 레벨 이슈가 서로 혼재해 있다는 점이 주된 특징인 시스템 설계

pros : 
레이어 별 연동을 한정할 수 있어 Loosely coupled 원칙을 지킬 수 있음, 레이어 재사용 가능 

cons :  레이어 동작 변경 시 단계별 재작업 필요, 효율이 낮음 - 계층의 원칙을 지키기 위해 각 계층을 모두 거침

 

Master Slave Style

pros : 교환가능성(Exchangeability)와 확장성(Extensibility)을 도입, 관심사항(Concerns)의 분리가 가능, 병렬 계산을 신중히 구현하면, 특정 계산에서의 성능 향상 가능 

cons : Master의 작업 분할, 할당, 대기, 결과 계산 등을 위한 처리 시간과 공간 필요 - Feasibility
병렬 계산을 위해서는 하드웨어에 종속, 변경용이성과 이식성 하락 - 머신 종속성의 제약을 받음

 

Microkernel Style

시스템의 요구사항이 변할 때, 이를 쉽게 시스템에 반영하기 위한 패턴, 일반적인 시스템의 기능에서 최소 핵심 기능은 공통으로 두고 변경이 가능한 확장 부분을 
 - 플러그인 방식으로 추가할 수 있는 패턴
 - Microkernel 은 파일이나 프로세스처럼 리소스를 저장하는 역할을 하고 다른 컴 포넌트들이 접속할 수 있도록 인터페이스를 제공함
 - Microkernel 내에 구현할 필요가 없는 핵심 기능은 Internal server로 분리시 켜 크기나 복잡성을 줄임
 - External server에는 External server 자체의 뷰를 구현하고 Microkernel 의 인터페이스를 이용하여 연동함
 - Client는 Microkernel의 통신 기능을 이용하여 External server와 통신

pros : 모듈 단위 개발로 확장과 포팅이 용이, 이식성이 보장, 유연성과 교환가능성이 확보, 유지보수성과 가변성을 향상, 확장성(Scalability) 확보(새 머신 추가), 신뢰성 지원(서버 문제), 투명성을 제공

cons : 메시지 전달하는 방식으로 자원에 접근하여 태스크 스위칭에 많은 오버헤드 초래, 시스템 설계가 복잡하고 개발이 어려움

 

MVC Style

시스템이 3개의 레이어로 명확하게 분할된 경우. 
시스템이 고도로 사용자 상호 작용하는 경우
비즈니스 프로세스 를 기본 데이터 표현 과 독립 적으로 모델링 해야 하는 경우.

pros : 
동일한 모델로부터 여러 View 들을 표현할 수 있음
View의 추가, 변경, 삭제가 자유로움
프레임워크로 확장하여 구현이 가능함

cons :
설계가 복잡하고 개발이 어려움 
View와 Controller는 밀접히 관련되어 있음 - 재사용 어려움
모델의 인터페이스를 변경하면 View와 Controller로 변경 되어야 함

 

Micro Service Style

도메인은 공통 REST 기반 웹 인터페이스
서비스를 독립적으로 배포할 수 있습니다

pros : 확장성, 탄력성, 진화성
오류의 고립(Fault Isolation)을 돕는다. 새로운 기술을 도입, 적용하기가 용이하다.

cons : 성능, 단순성, 비용
여러 서비스를 배치를 하는 것이 좀 더 복잡해 진다.
어려운 트랜잭션 관리, 테스트의 어려움, 디버깅의 어려움,

 

N-Tier Style

cons : 2개 이상의 티어에 있는 데이터를 가져갈 때 어려움

 

Publish-Subscribe Style

Publish-Subscribe : Subject와 Observer 간에 직접적인 Dependency 존재
Public Broker Subscribe: 메시지 브로커 따로 존재, 비동기 방식

pros : 새로운 event handler (event listener)를 추가하기 용이함.
동적인 등록 절차를 통해 event source와 listener가 연결되므로 event source와 listener가 runtime에 변경되기 용이함

cons: Event listener의 동작이 언제 끝날지 예상되지 않아 테스트와 디버깅이 어려움.
Non-deterministic 한 문제: 전달하지 못할 수도 있음

 

Pipe-n-Filter Style

pros : 
Concurrency: High throughput
Reusability: 단계별 프로세싱이 filter로 filter를 변경함으로써 Encapsulation되어 끼워넣거나 치환하기가 쉽다.
Modifiability: pipe를 통한 filter간 연결로 filter간 low coupling이 형성되어 새로운 filter를 추가할 때 다른 filter에 주는 영향이 적다.
Flexibility: Sequential execution과 parallel execution 두가지를 지원함.

cons : 
Interaction이 많은 경우에 적합하지 않음.
Pip를 통과할 때마다 data parsing에 대한 overhead가 늘어남.
다중 입력을 받는 Filter의 경우 모든 입력을 받아야 출력을 산출
필터의 입출력에 단 하나의 데이터 타입을 사용하는 경우, 과부하 발생
에러 처리가 어려움 

batch sequential 스타일과의 차이점
Batch-sequential 스타일은 각 단계에서 다음 단계로 데이터를 전달하기 전에 데이터를 완전히 처리함

 

Peer to Peer Style

pros : 분할은 분산 시스템 플랫폼 상의 배치에 있어 유연성(flexibility)을 제공, CPU와 디스크 자원의 효율적인 사용, 탈중화된 컴퓨팅 지원, 특정 노드 장애 감내

cons : 보안이 힘듦, 서비스 품질 보장 어려움, 노드 갯수에 따라 성능 좌우

 

Presentation Abstraction Control Architecture Style

PAC 스타일의 시스템은 대화형 소프트웨어 시스템을 위한 협력 에이전트의 트리와 같은 계층을 정의합니다.
계층에는 최상위 에이전트, 중간 수준 에이전트가 포함됩니다.

사용자와 상호작용하는 부분 뿐만아니라 계층간의 상호작용도 함께 분리

 

Presentation(View, Controller), Abstraction(Model), Control

 

Shared Repository Style

cons:
데이터와 계산을 데이터 저장소와 데이터 접근자에 매핑시키는 방법이 중요 
성능은 향상시키지만 복잡성을 증가시키고 신뢰성과 보안을 감소,
스트럭쳐가 바뀌면 사용하는 부분에서 다 바꾸어주어야한다

 

Sensor Controller Actuator Architecture Style

이 스타일은 주로 시스템 환경 컨텍스트를 읽는 센서와 환경 설정을 제어하는 액 추에이터를 연결하는 임베디드 시스템을 설계하는 데 사용됩니다. 수행 동작 결정, 명령 전송 등을 수행. closed-loop

이 스타일의 시스템은 서비스 공급자가 서버 노드에 배포한 여러 서비스와 함께 개발 및 실행됩 니다. 따라서 서비스를 재사용함으로써 대상 시스템의 개발 노력을 줄이고 품질을 높일 수 있습 니다.

SOA 데이터베이스가 하나, 
마이크로서비스는 데이터베이스도 다 분리