Programming architecture, design patterns, refactoring
|
개요
|
구체적인 서브클래스들을 의존하지 않고, 여러 클래스 집단을 생성하기 위한 인터페이스
|
|
언제
|
객체들이 생성되는 것을 변경하게 하고 싶을 때, 관련된 여러 객체들이 함께 사용되어야 할 때, 여러 Product 군 중에서 하나를 선택해야 할때
|
|
참여자
|
AbstactFactory, ConcreteFactory, AbstractProduct, ConcreteProduct,Client
|
|
장점
|
구체 클래스를 client에서 분리, Product 그룹을 쉽게 교체, Product 그룹의 객체들 간의 일관성
|
|
단점
|
전혀다른 새로운 제품 제공이 어렵다.
|
|
언제
|
복잡한 객체들을 생성하는데 그 객체가 하나의 ADT로 나올 수 있을 때, 객체의 생성방법이 복잡하지만 동일한 생성API를 제공하고 싶을 때
|
|
참여자
|
Builder=생성API, ConcreteBuilder=실제생성, Director=생성workflow, Product=제품의ADT
|
|
장점
|
Product의 생성 로직을 변경할 수 있다, 생성과 Product 클래스를 코드 분리
|
|
추상팩토리
|
확장성에 관심, 매 생성시마다 객체가 나옴
|
|
빌더
|
복잡한 객체 생성을 단계별로 쪼개는 데 관심, 내부적으로 모든 작업이 끝난 뒤, 마지막에 하나의 객체가 생성 됨
|
|
뭐냐
|
UI event handling
|
|
언제
|
msg receiver들이 다수로 구성되어있고 누가 처리할 지 모를때, msg를 누가 처리할지 정하고 싶지 않을때
|
|
참여자
|
Handler(다른 Handler를 링크), ConcreteHandler
|
|
장점
|
msg receiver, sender의 결합이 낮아짐(= 동적으로 삭제/추가해도 무방하다는 것)
|
|
단점
|
msg가 반드시 처리되지는 않음,
|
|
뭐냐
|
Container의 구조를 노출하지 않고 구성요소를 순회하게 하는 것
|
|
언제
|
container의 내부구조를 노출하고 싶지 않을 때, 구성 요소를 순회하는 단일 API를 제공하고 싶을 때, 순회방법을 여러개 추가하고 싶을때
|
|
참여자
|
Aggregate(Container ADT), ConcreteAggregator, Iterator, ConcreteIterator
|
|
뭐냐
|
요청을 객체화
|
|
언제
|
요청을 지연하거나, 요청을 분산처리, 요청을 되돌리거나
|
|
참여자
|
Command(요청의 API), ConcreteCommand, Invoker(명령을 하나씩 처리), Receiver(client에게 알려줌)
|
|
장점
|
요청 추가가 쉽다, 요청을 지연,분산,undo 가능
|
|
언제
|
객체의 생성 시점을 client가 정해야 할때, 어떤 클래스를 생성해야 하는지는 서브클래스가 정하게 하고 싶을때
|
|
참여자
|
Product, ConcreteProduct, Creator, ConcreteCreator
|
|
장점
|
생성될 객체를 외부에서 변경할 수 있다.
|
|
단점
|
Product와 Creator 양쪽에 서브클래스를 하게 된다.
|
|
언제
|
어느 클래스의 인터페이스를 client가 원하는 인터페이스로 변경해야 할 때, 그런데 그 클래스를 수정할 수는 없을 때
|
|
참여자
|
ObjectAdapter(위임), ClassAdpater(다중상속) 2개 버전이 있다. Target=사용자가 바라보는 인터페이스, Adapter, Adaptee(문제아)
|
|
Adapter는 기존과 다른 interface로 변형 vs proxy는 realSubject와 동일한 인터페이스를 redirection
|
|
Proxy는 객체에 대한 접근을 관리하는 것.
|
|
뭐냐
|
구현과 추상을 분리해서 서로 조합하게 함.
|
|
언제
|
추상과 구현을 분리할 때, 구현을 런타임에 변경하고 싶을 때,
|
|
참여자
|
Abstraction, RefinedAbstraction(확장된 client가 사용할 API), Implementor(구현부의 ADT), ConcreteImplementor
|
|
장점
|
구현이 인터페이스에 얽매이지 않게 됨, 추상과 구현을 각각 확장 가능,상세한 구현을 숨김
|
|
구조적으로는 서로 똑같음. 목적이 다르다. client가 사용할 수 있도록 인터페이스를 맞추는 것. Bridge는 추상과 구현이 얽매이지 않도록 함.
|
|
뭐냐
|
복합객체의 workflow를 확장할 수 있도록 한 객체에 몰아주는 것.
|
|
언제
|
메소드 안에 복합객체가 여러 객체들간 interaction이 존재할 때, 각 객체들이 다른 객체와 많은 분산된 interaction이 존재할 때
|
|
참여자
|
Mediator, ConcreteMediator, Colleague, ConcretreColleague
|
|
장점
|
다른 객체를 접근하고 제어하는 코드는 모두 Mediator에 통합, 다른 객체들 간의 종속성을 줄어듬, 제어가 중앙집중적, Mediator를 상속해서 제어를 쉽게 수정
|
|
Facade는 편한 Interface 사용이 목적 vs Mediator는 객체간 interaction을 가운데서 통제하자.
|
|
Facade는 새로운 객체 추가하려면 수정 필요 vs Mediator는 필요 없음.
|
|
언제
|
객체의 상태에 따라서 런타임에 행동이 달라져야 할때, if-else가 가 너무 많을때
|
|
참여자
|
Context(client의 API), State, ConcreteState
|
|
장점
|
특정 state와 관련된 코드를 별도로 모아둘 수 있다, State를 명확하게 구분하고 state전이를 두드러지 게 한다.
|
|
뭐냐
|
객체의 트리구조를 하나의 클래스로 구성하는 것
|
|
언제
|
트리구조를 만들어야 하는데, 모든 구성요소를 하나의 API로 다룰 수 있도록 하고 싶을때
|
|
참여자
|
Component(client가 사용하는 객체 합성 API를 가짐), Leaf(합성이외에 객체를 행동을 정의), Composite(자식을 Component르 가질 수 있도록 API를 구현함)
|
|
장점
|
client 코드가 단순해짐, 일관된 클래스 hierarchy가 나옴
|
|
단점
|
너무 범용적이라 특수화 된 코드를 넣기가 어려움(자식을 1개만 두고 싶다, 새로운 메소드 추가 등)
|
|
뭐냐
|
복합객체의 구조와 코드를 유지하면서 외부에서 그 요소에 대한 연산을 수행할 수 있다.
|
|
언제
|
객체의 구조의 요소들이 서로 다른 클래스일 때, 클래스마다 다른 연산을 적용해야 할때, 해당 클래스들은 코드 수정하고 싶지 않을때, 이러한 추가 연산이 앞으로도 또 일어날 때
|
|
구조
|
Visitor, ConcreteVisitor, Element, ConcreteElement
|
|
장점
|
새로운 연산을 쉽게 추가한다, 관련 연산을 추가할때 한군데에 모아둘 수 있다
|
|
단점
|
새로운 ConcreteElement 추가하면 모든 Visitor를 다 수정해야 한다.
|
|
참여자
|
Subject(여러개의 Observer를 가지며, notify()가 불려지면 observer들에게 통보한다), ConcreteSubject, Observer, ConcreteObserver(subject로부터 상태가 변경되었다고 받으면 ConcreteSubject에게 notify 한다.)
|
|
장점
|
1:N 의 sender, receiver 구조를 가질 수 있다, 동적으로 변경할 수 있다,
|
|
언제
|
동적으로 알고리즘 교체, 클래스가 같아도 알고리즘은 달라야 할때, 알고리즘의 추가를 고려할때
|
|
참여자
|
Context(client의 API), Strategy, ConcreteStategy
|
|
장점
|
상속을 사용하지 않으므로 알고리즘을 변경하기 위해서 서브클래싱을 찍어내는 걸 안해도 된다, 조건문이 사라짐, 동적으로 알고리즘 선택
|
|
단점
|
사용자가 각 전략들이 무엇인지 알고있어야 한다, 어떠한 ConcreteStategy는 Stategy로 넘어온 인자가 필요없는 오버헤드가 있을 수 있다, 객체 수가 증가한다.
|
|
정의
|
한 클래스는 하나의 책임만 가져야 한다.
|
|
안되면?
|
책임이 결합된다. 분리되어 있으면 일부만 수정한 부분을 조합해서 재사용이 가능했을 것이다.
|
|
정의
|
확장에 열려있고, 수정에 닫혀있어야 한다.
|
|
뭐야?
|
사용자가 사용하지 않는 메소드에 의존하도록 해서는 안된다.
|
|
어떻게 해결?
|
다중 상속 (mixin, interface), Delegation
|
|
뭐야?
|
'구현에 의존하지 말고, 추상화에 의존하자. 상위 수준(ADT)은 하위수준(구체클래스)에 의존해서는 안된다.
|
|
결합도 -> 코드가 딱 붙어 의존상태가 강한 정도 (상속, Composition, 등) 낮을수록 좋다
|
|
응집도 -> 클래스가 하나의 책임에 대해 관련 있는 코드만 잘 모여져 있는가. 관련 없는 메소드가 많이 모여 있거나, 책임이 너무 많이 모여있으면 응집도가 떨어진다.
|
|
요구공학
|
System Service (FR)과 Context(NFR)을 찾고 정리하는 것
|
|
SDLC의 종류
|
Water fall, Incremental, Evolutionary, Spiral Iterative, Agile, RUP
|
|
RUP의 프로세스
|
Inception, elaboration, construction, transition
|
|
Incremental의 프로세스
|
RE는 RE만, code 팀은 code만, Test팀은 Test만 파이프라인 처럼
|
|
Validation vs Verification
|
Verification은 명세대로 했는가, Validation은 명세가 올바른가
|
|
RE의 과정
|
Feasibility Test > RE Elicitation > Req Specification > Req Validation
|
|
Elicitation
|
System model을 만들고 Workshop, Brainstorming, survey, interview, role playing, prototyping 등을 해서 요구사항을 뽑아낸다. Prioritization&Negotiation으로 NFR에 대해 점수를 메긴다. (FR은 반드시 해야 하므로 필요없다)
|
|
Negotiation
|
요구사항의 우선순위 측정은 ranking, ahp, grouping, bubble sort, hundred dollors
|
|
Specification
|
뽑아낸 요구사항을 분류 / 조직화한다.
|
|
SRS
|
Software Requirement Specification (요구사항 최종 산출물). 설계나 Plan이 들어있으면 안된다.
|
|
Validation
|
최종 검증 (프로토타이핑 등)
|
|
Suitability(적합성)
|
지정된 작업과 사용자 목적에 따라 적절한 기능들을 제공
|
|
Accuracy
|
올바른 결과를 얼마나 잘 제공할 수 있는가
|
|
Interoperability(상호운영성)
|
다른 시스템과 interaction 할 수 있는 정도
|
|
Security
|
권한이 없는 사람의 접근을 막거나, 데이터의 변조를 막거나, 권한있는 사람이 허용되게 하는 것
|
|
Compliance(준수성)
|
SW 관련된 법적 규제, 관례, 규정을 준수하는 정도
|
|
Maturity(성숙성)
|
SW 결함이 발생하여 고장이 나지 않도록 하는 정도
|
|
Fault Tolerance(결함허용성)
|
결함이 발생하여도, 명세한 성능을 유지할 수 있는 정도
|
|
Recoverability(복구성)
|
고장 발생시, 명세된 성능으로 다시 돌아가고 영향받은 데이터를 복구 하는 능력
|
|
Usability
|
사용자가 쉽게 이해하고 학습하고 사용되고 선호하는 정도
|
|
Understandability(이해성)
|
소프트웨어가 적합한지, 어떻게 사용해야 하는지 사용자가 쉽게 이해하는가?
|
|
Learnability(학습성)
|
사용자가 쉽게 배울 수 있도록 도와주는 능력
|
|
Operability(운영성)
|
사용자가 SW를 쉽게 운영/관리 하게 할 수 있는가?
|
|
Attractiveness(선호도)
|
사용자에 의해 선호되는 정도
|
|
Effectiviness
|
명세된 조건하에서 얼마나 자원을 덜 사용하여 높은 성능을 내는가?
|
|
TimeBehavior(시간 반응성)
|
명세된 조건하에서 처리시간과 처리율이 얼마나 빠르고 좋은가?
|
|
Resource Utilization(자원 활용성)
|
기능을 수행하기 위해서 얼마나 덜 자원을 사용하는가
|
|
Analyzability(분석성)
|
SW 결함의 원인을 진단하는 능력
|
|
Changeability(변경성)
|
명세가 변경되었을때 쉽게 구현하는 정도
|
|
Stability(안정성)
|
SW 변경으로 예상치 않은 결과가 잘 발생하지 않게 하는 정도
|
|
Testability
|
변경된 SW를 검사할 수 있는 능력
|
|
Adaptability(적응성)
|
SW에서 원래 목적으로 제공되는 것 이외에 다른 환경으로 변경될 수 있는 정도
|
|
Installability(설치성)
|
명세된 환경에 설치가 얼마나 쉬운가
|
|
Co-existency(공존성)
|
공통 자원을 공유해야 하는 환경에 설치될 경우, 다른 SW와 같이 공존하는 정도
|
|
Replaceability(대체성)
|
동일한 환경에서 같은 목적인 SW들과 대체가 얼마나 쉬운가
|
|
Viewpoints?
|
시스템을 바라보는 관점. View는 그 관점에서 시스템의 요소를 도식화 한것. Logical Views는 구조를, Process View는 흐름, 즉 런타임 동작을, Development는 개발팀의 산출물 (패키지, 코드 위치등)을, Deployment는 최종 시스템 요소의 물리적인 설치를
|
|
Use-Case view
|
Activity/Info Flow Diagram, UseCase diagram
|
|
Logical View
|
Sequence Diagram, Domain Model Class Diagram
|
|
Development view
|
component diagram, package diagram
|
|
Domain Model?
|
RE 에서 요구사항 분석을 위한 Conceptual class diagram.
|
|
Process view
|
sequence, activity diagram
|
|
Physical view
|
deployment diagram
|
|
Process Quality
|
|
|
Internal QA
|
개발팀 내에서 세분화한 QA
|
|
External QA
|
Stake holder 들이 제시한 QA. 위에 2개 모두 제품 관점에서 산정한 모델
|
|
Quality in use
|
사용자 관점에서 산정한 QA의 모델(모음집)
|
|
Architecture concerns
|
요구사항 이외에 아키텍트가 추가로 넣는 요구사항으로, 일반적으로 이 프로젝트에서 추가하는 요구사항 혹은 경험에 따라서 추가하는 요구사항 들이다.
|
|
Responsibility란?
|
클래스에 주어진 contract 혹은 의무. 다른 메소드 / 객체와 연계해서 메소드로써 구현됨. 메소드로 동작을 하는 책임도 있는 반면, 다른 객체나 private field를 아는 것도 책임에 포함됨
|
|
GRASP
|
coupling, cohension, expert, controller, creator, don't talk to stranger
|
|
Low coupling이 높으면?
|
재사용이 힘듬. 하나 바꾸면 다 바꿔야 함, 코드 이해가 어려움,
|
|
cohension이 낮으면?
|
여러 책임이 한 클래스에 다 모여있어서 이해가 어려움 직관적이지 않음,
|
|
Information Expert
|
가장 먼저 클래스에 줄 책임은, 가지고 있는 private info (encapsulated)를 관리하고 값을 채워넣는 책임이다.
|
|
Creator
|
A가 B를 매우 친밀하거나, B를 가지고 있거나, B와 aggregate 하거나 B가 생성될때 초기화 정보를 넣어준다면 A가 B를 생성하게 하라.
|
|
controller
|
|
|
Don't talk to stranger
|
|
|
ADD?
|
Architecture Design Methodology
|
|
Plan do and check
|
모듈 선택 -> 분해 -> Architecture Driver 선택 -> NFR해결을 위한 Style 선택 + FR을 위한 하위 모듈 실체화 -> 하위 모듈의 인터페이스 정의 -> Usecase, QA를 검증하고 contraint 확정 -> 이하 반복
|
|
UP 구성
|
inception phase, elaboration, construction, transition
|
|
각 phase 별 disciplines
|
test, code, planning, Req, analysis & design, business modeling, deployment, configuration & change management, Project management
|
|
Inception phase
|
Business modeling, Req 추출, Prototyping, feasibility study
|
|
Elaboration
|
ADD 방법론 등을 사용하여 아키텍처 설계를 해서 Baseline Architecture를 정의한다. Baseline archirecture는 skeleton architecture로 elaboration 단계가 끝나면 최종 완성되며 이후 절대로 바뀌어서는 안된다.
|
|
Architecture Style
|
== Architecture Pattern
|
|
Pattern?
|
특정한 문맥(조건,상황)에서 발생하는 설계 문제가 있을때 그것을 잘 해결하는 일반화된 설계 형태를 제시한 것.
|
|
Design pattern?
|
components나 subsystem을 설계할 때 적용 가능한 패턴
|
|
idium
|
구현시 적용 가능한 패턴
|
|
Association
|
클래스를 사용함
|
|
Aggregation
|
포함 관계가 있지만 owner가 죽어도 owning은 영향 없음. 중간에 다른 객체에 붙을 수도 있음
|
|
Composition
|
포함관계가 있으며 라이프 사이클이 동일함.
|
|
품질속성 시나리오 구성
|
Source(위치), 원인(Stimulus), 대상(Artifact), 상태(Environment), 대응(Response), 대응결과(Response Measure)
|
|
Modifiability
|
변경 지역화(책임을 분리시킴), 기존 인터페이스를 유지, LateBinding
|
|
성능(자원수요)
|
필요한 자원을 줄이기(알고리즘 개선, 요청 자체를 없앤다, 이벤트 빈도 줄이기,
|
|
성능(자원관리)
|
동시성 제공,데이터 처리가 병목 되지 않도록, 자원을 늘림(HW),
|
|
가용성(오류감지)
|
Ping,Echo(다른 컴포넌트,프로세스가 잘 동작하는지 확인), HeartBeat(정상이라고 신호를 내가 보낸다),
|
|
가용성(오류복구)
|
같은 일을 처리하는 여러개의 프로세스/Node를 둬서 하나가 망가져도 다른쪽이 잘 동작시킴, 롤백
|
|
보안
|
기밀성(권한 있는 사람만 본다), 무결성(권한 있는 사람만 write), 인증(송신자가 맞는지 확인), Non-Repudication(부인봉쇄, 안보냈다고 뻥카치지 못하게, AccessControl(권한이 있어야 사용 가능), 가용성(권한이 있으면 서비스 이용이 지속되야)
|
|
class diagram
|
class, interface, component, visibility
|
|
deployment diagram
|
artifacts(file, db), node, components
|
|
component diagram
|
port, provided interface, required interface, component,
|
|
sequence
|
lifeline, message, interaction use,
|
|
activity diagram
|
swim lanes, merge node, decision node, initial node, final node, merge node, fork node
|
|
data flow
|
external entity, process, datastore
|
|
분류
|
Data Flow
|
|
뭐냐
|
Data Flow AS 중 하나. 데이터가 단방향으로 하나의 서브시스템에서 다른 서브시스템으로 이동한다. 각 서브시스템은 input이 넘어와야만 작업할 수 있다.
|
|
참여자
|
Program, Data Store
|
|
장점
|
오직 데이터(파일)에 의해서만 연결되어있이므로 데이터 포맷만 맞추면 쉽게 분리 가능,
|
|
단점
|
데이터만 input이므로 외부에서 각 서브시스템을 제어하기에는 다소 맞지 않는다. 동시성을 지원하지 못하므로 높은 latency를 가진다.
|
|
분류
|
Data Flow
|
|
뭐냐
|
스트림을 따라서 데이터가 필터에 도착하면 데이터를 가공하고 다음 필터로 파이프로 전달.
|
|
참여자
|
데이터스트림, 필터, 파이프
|
|
장점
|
동시성을 제공한다. 데이터가 끊임없이 밀려오고 각 필터는 자기 담당만 처리하므로., 재사용, 변경이쉽다, 단순하다.
|
|
단점
|
동적으로 데이터의 포맷을 변경할 수 없다.
|
|
Batch Sequencial의 차이
|
사전 처리 과정이 완료되어야 하지만, 파이프&필터는 데이터가 계속 주어지는 상황을 전제로 한것이다.
|
|
분류
|
Data Flow
|
|
참여자
|
Controller, Actuator, Process, Sensor
|
|
뭐냐
|
Controller가 현재 상태를 측정값을 보고 Actuator에게 start/stop을 내린다. Actuator는 핵심 기능을 담당하는 Process에게 이 정보를 전달하고 Process에 input이 들어가면 start/stop을 수행한다. 그 결과는 sensor가 수집하여 다시 Controller에게 전달한다. 이처럼 closed - loop의 구조를 주로 띄게 된다.
|
|
장점
|
복잡한 공식이 없어도 상태값을 일정한 수준으로 유지하게 하는게 가능하다.
|
|
추천 적용
|
상태 값을 제어하는 임베디드 시스템, 빌딩 온도 제어 시스템, 핵 발전소 등
|
|
참여자
|
Repository, Components
|
|
뭐냐
|
중간에 공유 저장소가 있는 것. 그래서 저장소를 기반으로 데이터 interaction 하는 것이다.
|
|
장점
|
데이터 통합되게 해준다, BackUp&Restore를 쉽게 달성한다, 각 components의 확장성/ 재사용 가능하다 (직접적으로 interaction을 하지 않기 때문에),
|
|
단점
|
데이터 중복이 발생할 수 있다, 저장된 데이터의 구조에 components들이 높은 의존성, 데이터의 포맷을 변경하고 확장하는 것은 비용이 크다.
|
|
분류
|
Data Centered
|
|
참여자
|
Blackboard, Control, KnowledgeSource
|
|
뭐냐
|
KnowledgeSource는 독립된 서브시스템으로 복잡한 문제 1개를 잘 알려진방법으로 해결한다. Blackboard는 공유 저장소를 가지고 있고 여기에 붙은 KnowledgeSource들은 blackboard에 있는 데이터를 각각 해결해서 업데이트한다. Control은 이 변화를 모니터링 한다.
|
|
언제?
|
유일한 해결책이 없는 복잡한 문제를 해결해야 할때
|
|
장점
|
KnowledgeSource를 쉽게 추가가 가능하다. 동시성을 제공한다.
|
|
단점
|
blackboard의 구조를 바꾸면 매우 많이 바꿔야 한다. 언제까지 계속 데이터를 업데이트 해야 하는지 판단하는 것이 어렵다. 여러 KnowledgeSource들 간에 동기화문제
|
|
분류
|
Hierarchical
|
|
참여자
|
Layer
|
|
뭐냐
|
상위 레이어는 하위레이어에 의존한다. 아래에서 위로 의존관계가 맺어지지는 않는다. 하나의 Layer에서 발생한 수정은 다른 layer에 영향을 주지 않는다.
|
|
언제 적용?
|
시스템이 확장해가면서 최소한의 의존을 만들고 각 모듈이 모듈성 재사용성을 높이면서 독립적으로 개발될 수 있어야 할때
|
|
장점
|
인터페이스가 변하지 않는 한, 하위레이어의 수정이 상위레이어에 영향을 주지 않는다, 각 layer는 미리 정의된 인터페이스로 통신하기 때문에 인터페이스만 지켜주면 쉽게 확장/교체 가능하다.,
|
|
단점
|
런타임 성능이 떨어진다. 아래까지 내려갔다가 위로 올라와야 하니까, Exception Handling도 마찬가지로 depth가 깊기 때문이다.
|
|
분류
|
Hierarchical
|
|
참여자
|
CoreSystem, Plug-in modules
|
|
뭐냐
|
App 추가 로직을 PlugIn을 떼었다가 붙였다가 하는 것. 핵심로직은 coreSystem으로 미리 구현을 해놓아야 한다.
|
|
장점
|
이식성, 확장성,
|
|
참여자
|
Application, Virtual Machine, Existing Platform
|
|
장점
|
이식성, SW개발 쉬움
|
|
단점
|
속도 느림
|
|
분류
|
Implict asynchronous communication software
|
|
참여자
|
Event source, event listener
|
|
뭐냐
|
버퍼를 두지 않고 컴포넌트 끼리 비동기로 interaction 한다. 이벤트가 발생하면 바로 쏜다. 옵저버 패턴하고 유사함
|
|
장점
|
런타임에 listener를 쉽게 추가/삭제, 재사용성(쉽게 다른 source, listener를 붙일 수 있다),
|
|
단점
|
listener의 동작이 언제 끝날지 알기가 힘들다, 디버깅이 어려움, 버퍼 비동기보다 직접적으로 의존하므로 결합도가 높다
|
|
분류
|
Implicit Asynchronous communication
|
|
참여자
|
MessageBroker, Consumer, Producer
|
|
뭐냐
|
Producer가 msg를 xml 등과 같은 형태로 broker에 넣는다. Broker는 가공하거나, 보안체크를 하거나 다른 borker로 route하거나 consumer들에게 전달한다.
|
|
언제 적용
|
네트워크 관리, 날씨 예보, 뱅킹 시스템
|
|
장점
|
비동기가 가능한데 Producer가 메시지를 보낼때 Consumer가 idle 상태가 아니어도 된다, 매우 독립적인 설계가 가능하며 쉽게 교체/확장이 가능하다, producer는 누가 이 메시지를 받을 것인지 어디에 위치하고 있는지 몰라도 된다, 동시성을 보장한다
|
|
단점
|
메세지 큐에 한계는 있다, 구현에 복잡도가 올라간다, 디버깅이 어렵고 직접호출보다 퍼포먼스가 저하된다.
|
|
분류
|
Distributed
|
|
참여자
|
Client, Server
|
|
뭐냐
|
전체 시스템의 구조를 요청자와 처리자로 tier를 분산하는 것이다.
|
|
언제?
|
클라이언트가 여러명이 하나의 서비스로 접근하는데 이를 효율적으로 관리하고 싶을때, 리소스 Control은 중앙집중으로 하고 싶고 리소스 자체는 여러 군데 분산시키고 싶을때
|
|
장점
|
책임을 분리시킬 수 있다. (presentation, businiess logic), 보안성, 서버의 가용성
|
|
분류
|
Distributed
|
|
참여자
|
Tier
|
|
Layer vs Tier
|
Layer는 소프트웨어 적으로 구분한 구조의 구성 요소, Tier는 물리적인 요소
|
|
장점
|
중간에 tier를 넣음으로써 확장성과 재사용성, 비지니스 관련은 중간 티어에만 들어감, 트래픽 감소, 신뢰성 증가,
|
|
단점
|
테스트가 더 어렵다
|
|
분류
|
Distributed
|
|
참여자
|
Client, Broker, Server
|
|
뭐냐
|
Server들은 모두 같은 구현이다. Broker는 Server의 걸린 load를 보고 제일 좋은 Server로 client의 요청을 연결 시켜 준다. Broker또한 별도의 tier이며, Server는 Broker에 register 한다.
|
|
장점
|
Client-Server가 결합도가 낮다, 트래픽에 강하다, 서비스 가용성이 좋다,
|
|
단점
|
Broker를 거쳐서 통신하므로 퍼포먼스 저하, 테스트가 어렵다.
|
|
분류
|
distributed
|
|
참여자
|
Broker, Client, Servant
|
|
뭐냐
|
CORBA임. 분산객체 각 Node는 Broker를 앞에 달고 있고 Broker는 해당 Node 내에서 등록한 Servant 들을 모두 들고 있음. Node와 Node는 서로 통신이 가능함.
|
|
장점
|
컴포넌트가 로컬에 있건 외부에 어디에 있건 위치 관계없이 의도한 결과를 얻는다, 완전히 다른 서버와 플랫폼 간의 interaction이 쉽게 가능함, 컴포넌트 재사용이 좋다
|
|
단점
|
성능이 떨어진다, 장애가 발생할 경우 대처가 어렵다 (fault-torelance), 테스트가 어렵다
|
|
언제?
|
많은 시스템이 분산되어있다, 바인딩을 동적으로 바꾸고, 객체로써 다루고 싶고 서비스 제공자의 위치를 알고싶지도 않고....
|
|
분류
|
Distributed
|
|
참여자
|
Master, Slave
|
|
뭐냐
|
Master는 Slave 중에서 주어진 문제를 해결할 수 있는 놈을 선정해서 그 결과를 받아옴
|
|
장점
|
fault tolerance, 신뢰성(실패해도 다른 slave와 연결)
|
|
언제 적용
|
fault tolerance, reliability가 중요할때
|
|
분류
|
Distributed
|
|
뭐냐
|
동일한 역할을 부여받은 Peer 노드 끼리 Provider 이자 Consumer로써 서로 연결되어 하나의 contents에 대한 일정 비율을 각각 나누어 가져서 제공하는 것
|
|
structured, unstructured
|
unstructured는 말그대로 중앙이 아무것도 없음, structured는 중앙에 관리 혹은 분배하는 놈이 더 있고 더 효율적임.
|
|
장점
|
중앙이 없으므로 중앙이 실패할 염려도 없음, 확장성이 좋음 그냥 연결해서 붙이면 끝, 별도의 DB나 서버를 둘 필요가 없음
|
|
단점
|
시스템 전체적으로 일관성을 갖도록 유지하는 것이 어렵다, 각 node 마다 power가 다르다
|
|
분류
|
distributed
|
|
뭐냐
|
서비스(흔히 생각하는 OS의 서비스가 아니다)라고 하는 작은 단위에 독립적인 MVC를 모두 가진 서브시스템이 있다. 이 서비스들을 매우 완화된 포맷인 XML등을 사용해서 레고블럭 처럼 쌓아서 통신하는 것이다. 네트워크를 사용할 수도 있고 사용하지 않을 수도 있다. 다른 언어라고 해도 XML만 지원하면 동작한다.
|
|
언제?
|
하나의 큰 시스템을 책임으로 묶어서 보다 작은 서비스로 만들어, 이들간에 표준화된 인터페이스를 정의하고 이를 잘 블럭처럼 쌓아올려서 다른 시스템을 만들때 재사용하고자 하는 것
|
|
장점
|
상호운용성, 확장성, 재사용성
|
|
단점
|
구축하기 어렵다, 성능이 떨어진다, 병목현상이 발생할 수 있다.
|
|
분류
|
Distributed
|
|
뭐냐
|
SOA의 일종의 부분집합이다. SOA는 monolithic 아키텍처다. interaction은 언어에서 독립적인 방법으로 수행하지만 공통으로 묶을 수 있는 부분은 묶는다. (예를들면 공용 DB) 반면 Microsoervice는 각 서비스를 작게 쪼개서 네트워크를 통해 API를 제공할 뿐 그 안에 구성은 encapsulation 하듯이 감추는 것이다. DB도 각자사용하거나 DB를 없앤다.
|
|
RESTful?
|
네트워크로 API를 만들려면 다양한 방식이 있을 것이다. json으로 https로 날려도 되고. RESTful은 이러한 API를 HTTP의 방식 GET, POST 등을 사용해서 표현하는 것을 말한다. 즉 API 정의방법.
|
|
장점
|
독립적인 작은 서비스이므로 확장이 쉽고, 결합도가 낮다. 모듈화 수준이 높다, 테스트/개발이 쉽다.
|
|
단점
|
|
|
언제?
|
결합도가 너무너무 높다, 하나만 기능을 고치려는데 시스템 전체를 다 체크한다, 기존 시스템을 분해하면 수십개의 micro service가 나온다.
|
|
단점
|
View와 Control 구분하는 것이 때로는 명확하지 않다, Model이 변경되면 impact가 크다.
|
No comments yet.
Cheatography n. The art of mapping complex subjects into clear, instantly navigable reference guides.
