비동기 메시징 패턴 응용 통신 비동기 메시징은 메시지 브로커를 사용하는 경우 브로커 없이 서비스가 직접 하는 경우가 있다. 메시지 메시지는 Header와 Body 로 구성. 브로커를 사용하는 경우 메시지 채널을 통해서 교환 된다. 메시징 상호작용 클라이언트/서비스는 한 쌍의 메시지를 주고받는 비동기 요청/응답 스타일로 상호작용 한다. 클라이언트는 수행 작업과 매개변수를 메시징 요청 채널에 보내고 서비스는 요청 처리 후 메시지 응답 채널로 응답 한다. 클라이언트 → 요청 채널 → 서비스 → 응답 채널 → 클라이언트 구현 방법 단방향 알림 비동기 메시징을 이용하여 클라이언트만 서비스에 요청하고 서비스는 응답 하지 않음 발행/구독 메시징은 발행/구독 스타일을 기본 지원한다. 클라이언트는 여러 Consumer가..

MSA 프로세스 통신 2 부분 통신 실패 : 회로 차단기 패턴 항상 서비스는 실패할 가능성에 대해 오픈 마인드다. 한개 서비스 호출 불가는 전체 서비스에 대해 영향을 미침으로 서비스 부분 실패가 전체에 영향 가지 않도록 설계를 해야 한다. RPI 프록시 설계 Netflix는 다음과 같이 실패에 대해 처리한다. 네트워크 타임아웃: 응답에 대해 항상 Timeout 설정, 불필요한 리소스 사용 방지 미처리 요청 개수 제한: 최대 요청 횟수를 설정하여 초과시 요청을 포기하도록 한다. 회로 차단기 패턴: 서비스에 성공/실패에 대해서 counting을 하고 일정 임계치를 초과하면 그 이후에 요청은 포기한다. 부분 실패시 미리 정해진 default 값이나 캐시된 값 등을 반환하는 방법이 있다. 서비스 디스커버리 클라..

MSA 프로세스 통신 IPC 개요 통신 상호작용 기준 첫번째 일대일: Client의 요청은 한개의 서비스가 처리 일대다: Client의 요철을 여러개의 서비스가 처리 두번째 동기: Client가 서비스에게 요청하고 응답 대기를 하며 블로킹도 할 수 있음 비동기: Client가 블로킹 하지 않으며 응답은 바로 하지 않아도 됨 통신 상호작용 종류 요청/응답 : Client는 서비스에 요청을 하고 응답 대기. 강한 결합의 상호작용 스타일 비동기 요청/응답 : Client는 서비스에 요청을 하고 서비스는 비동기적으로 응답 단방향 알림 : Client는 요청만 하고 서비스는 응답을 하지 않음 API 설계 API 기능 추가/변경/삭제 등을 통해서 충분히 변경될 수 있다. 따라서 이런 문제를 해결하기 위해서 프로젝트..

마이크로서비스 아키텍쳐 3단계 프로세스 1단계는 요청을 추출, 요청에 대해서 추상적으로 관찰 해야 합니다. 2단계는 어떻게 서비스로 분해할지 결정 해야 합니다. 3단계는 서비스별 API를 정의하고 서비스에 역할 배정 및 서비스간 협동에 대해서 정의를 해야 합니다. # 1단계. 시스템 작업 식별 시스템 작업을 기술하기 위한 고수준 도메인 모델을 생성한다. 위 그림을 통하면 이는 Order, Delivery, Restaurant 로 추출할 수 있다. 고수준의 도메인 모델로 나누기 위해서는 시나리오 작성을 통해서 하는 방법이 있다. 전제 (Given) - 소비자가 있다. - 음식점이 있다. - 음식점은 소비자의 주소로 음식을 배달 한다. - 주문 총액은 최소 주문량 조건에 부합해야 한다. 조건 (When) -..

분해전략 애플리케이션의 아키텍쳐는 여러 파트로 분해와 파트들의 연관성 이 두가지 때문에 중요하다. 업무와 지식을 분리하여 효과적으로 팀을 이루어 생산적인 작업을 할 수 있고 어떻게 상호작용 하는지 알 수 있다. # 소프트웨어 아키텍쳐 4+1 뷰 모델 아래 4가지 뷰를 통해서 시나리오 뷰를 작동한다. 논리 + 구현 + 프로세스 + 배포 => 시나리오 논리 뷰 (Logical View) 구분 내용 개발자가 작성하는 것 엘리먼트 클래스, 패키지 관계 상속, 연관, 의존 등 클래스와 패키지의 관계 구현 뷰 (Implementation View) 구분 내용 빌드 시스템의 결과물 엘리먼트 모듈(JAR), 컴포넌트(WAR) 관계 모듈과 컴포넌트의 관계 프로세스 뷰(Process View) 구분 내용 런타임 컴포넌트 ..

패턴은 패턴은 특정 상황에 발생한 문제에 재사용 가능한 해법이며 실제로 검증된 유용한 생각입니다. 패턴은 어떤 상황에서는 유용하지만, 또 어떤 상황에서는 전혀 유용하지 않을 수 있습니다. 또 기술적인 부분이 강제되는 점도 있습니다. 강제 조항 (Forces) 문제 해결을 위해서 강제로 처리해야 할 이슈들에 대해서 우선순위를 정하는 것. 예를들어 코드를 이해하기 쉬우며 성능도 우수해야 한다면 리액티브 스타일 코드는 성능은 우수할지 모르지만 이해햐기 어렵습니다. 따라서 이는 전에 반드시 해결 되고 진행 되어야 함. (리액티브 스타일 : 함수형 언어나 엑셀등에서 사용, 자세한 것은 구글링) 결과 맥락 (Resulting Context) 패턴 적용 결과 장점과 단점, 이후 새로운 문제에 대해 고려 필요 연관 패..

FTGO 예시 모놀리식 구조 전형적인 자바 애플리케이션인 FTGO 의 전체 구조는 코어가 비지니스 로직으로 구성된 융각형 아키텍쳐이며 UI, 외부 시스템 통합을 위해 어댑터가 비지니스 로직을 감싼 모양새이다. # 마이크로 서비스 구조 FTGO 애플리케이션은 각 요청에 대해 서비스로 보내고 각자의 API 를 통해 서로 협동한다. # 마이크로 서비스로 변경을 통해 장점 크고 복잡한 애플리케이션을 지속적인 전달/배포 서비스 규모가 작아 관리 용이 서비스를 독립적으로 배포/확장 가능 서비스 팀별로 자율적인 업무 수행 가능 결함 격리가 쉬움 새로운 기술에 대해 도입 용이 단점 서비스를 찾기가 어려움 마이크로 서비스는 따로 정해진 규약이 없어 서비스 모듈을 잘 못 분해할 경우 분산 모놀리식이 구성 될 수도 있다. ..

모놀리식에서 MSA로 Micro Service Architecture 마이크로 서비스 아키텍쳐는 고수준에서 하라보면 하나의 애플리케이션을 여러 서비스로 기능 분해하는 기법 입니다. 각 서비스가 집중되고 응집된 역할을 수행을 합니다. 모듈성 모듈셩은 크고 복잡한 애플리케이션을 개발할 때 꼭 필요한 특성으로 규모가 방대하고 복잡하다면, 개인이 이해하기 어렵고 개발하기 힘듭니다. 따라서 여러 사람이 이해하기 쉽고 개발을 할 수 있도록 여러 모듈로 분할을 해야 합니다. 경계선 각 서비스는 다른 서비스가 침투하지 못하도록 API 라는 경계선을 갖고 있어 다른 서비스에서 접근이 불가하도록 해주며 이는 유지보수에 크게 도움이 됩니다. 또 서비스에 대해서 단위 별로 배포 및 확장에도 도움이 되는 장점이 있습니다. 개별..