[wynter] 챕터 13, 14 정리

ch13_서비스_기반_아키텍처_스타일/ch13_wynter.md

@@ -0,0 +1,41 @@
+# CHAPTER13 서비스 기반 아키텍처 스타일
+
+마이크로서비스 아키텍처 스타일의 일종으로, 아키텍처가 유연해서 실용적인 아키텍처 스타일 중 하나입니다.
+
+## 13.1 토폴로지
+
+서비스 기반 아키텍처의 기본 토폴로지는 각각 따로 배포된 유저 인터페이스와 원격 서비스, 그리고 모놀리스 데이터베이스로 이루어진 대규모 분산 레이어 구조입니다.
+
+이 아키텍처 스타일에서 서비스는 큼지막한 단위로 분리해 별도로 배포하는 애플리케이션의 일부입니다. 서비스를 배포하는 방식 자체는 여느 모놀리식 애플리케이션과 동일하므로 컨테이너화가 필수는 아닙니다.
+
+서비스 기반 아키텍처의 도메인 서비스는 각각 단일 인스턴스로 배포하지만, 인스턴스를 여럿 둘 수도 있습니다.
+
+서비스는 원격 액세스 프로토콜로 유저 인터페이스 외부에서 접속할 수 있습니다.
+
+서비스 개수가 적어서 데이터베이스 커넥션은 대개 문제가 안 되지만 데이터베이스 자체의 변경은 이슈가 될 수 있습니다.
+
+## 13.2 토폴로지 변형
+
+## 13.3 서비스 설계 및 세분도
+
+도메인 서비스는 레이어드 아키텍처 스타일이나 모듈러 모놀리스 아키텍처 스타일로 설계할 수 있음
+
+어떻게 설계하든 유저인터페이스 -> 비즈니스 기능을 위해 API 액세스 퍼사드가 필요함. 이 친구는 비즈니스 요청을 오케스트레이트함. 이런 요청을 마이크로서비스 아키텍처에서 처리한다면 별도 배포된 다수의 전용 원격 서비스를 오케스트레이션해야 합니다. 세분도 관점에서 보면, 내부 클래스 수준의 오케스트레이션과 외부 서비스의 오케스트레이션이라는 차이점이 마이크로서비스와의 중요한 차이점.
+
+## 13.4 데이터베이스 분할
+
+테이블 스키마 변경 시 문제가 될 수 있습니다. 테이블 스키마를 올바르게 변경하지 않을 경우 모든 서비스에 악영향을 미치기 때문에. 엔티티 객체를 커스텀 공유 라이브러리에 둡니다. 이게 결국 언 ㅡ서비스가 실제로 테이블 변경에 영향을 받을지를 미리 예측하기란 어렵습니다.
+
+리스크를 낮추는 방법은 데이터베이스를 논리적으로 분할하고 이런 논리 분할을 연합 공유 라이브러리를 통해 명시하는 것입니다.
+
+## 13.5 아키텍처 예시
+
+## 13.6 아키텍처 특성 등급
+
+평균 등급이 높은듯.
+
+## 13.7 언제 이 아키텍처 스타일을 사용하는가
+
+어쩌면 가장 실용적인 아키텍처. 도메인 주도 설계와 궁합이 잘 맞습니다. ACID 트랜잭션이 더 잘 보존됩니다.
+
+우리회사에서는 이 서비스 기반 아키텍처 스타일을 기본적으로 쓰는 것 같넹???

ch14_이벤트_기반_아키텍처_스타일/ch14_wynter.md

@@ -0,0 +1,51 @@
+# CHAPTER14 이벤트 기반 아키텍처 스타일
+
+이벤트 기반 아키텍처는 확장성이 뛰어난 고성능 애플리케이션 개발에 널리 쓰이는 비동기 분산 아키텍처 스타일입니다. 이벤트를 비동기 수신/처리하는 별도의 이벤트 처리 컴포넌트들로 구성되며, 스탠드얼론 아키텍처 스타일로 사용하거나 다른 아키텍처 스타일에 내장할수도 있습니다.
+
+## 14.1 토폴로지
+
+중재자 토폴로지와 브로커 토폴로지가 있습니다. 중재자 토폴로지는 주로 이벤트 처리 워크플로를 제어해야 할 경우에, 브로커 토폴로지는 신속한 응답과 동적인 이벤트 처리 제어가 필요할 때 각각 사용됩니다.
+
+## 14.2 브로커 토폴로지
+
+브로커 토폴로지는 중앙에 이벤트 중재자가 없다는 점에서 중재자 토폴로지와 다릅니다. 메시지는 경량 메시지 브로커를 통해 브로드캐스팅되는 식으로 이벤트 프로세서 컴포넌트에 분산되어 흘러갑니다. 이 토폴로지는 비교적 이벤트 처리 흐름이 단순하고 굳이 중앙에서 이벤트를 조정할 필요가 없을 때 유용합니다.
+
+브로커 토폴로지는 네 가지 기본 아키텍처 컴포넌트, 시작 이벤트, 이벤트 브로커, 이벤트 프로세서, 처리 이벤트로 구성됩니다.
+
+성능, 응답성, 확장성 측면에서 장점이 많지만 단점도 적지 않습니다. 시작 이벤트와 연관된 전체 워크플로를 제어할 수 없습니다. 실제 주문 트랜잭션이 언제 끝났는지 모릅니다. 에러 처리 역시 어렵습니다. (표 참고)
+
+## 14.3 중재자 토폴로지
+
+이벤트 프로세서 간 조정이 필요한 시작 이벤트에 대하여 워크플로를 관리/제어하는 이벤트 중재자가 핵심입니다. 중재자 토폴로지는 시작 이벤트, 이벤트 큐, 이벤트 중재자, 이벤트 채널, 이벤트 프로세서 이렇게 5개 아키텍처 컴포넌트로 구성됩니다.
+
+브로커 토폴로지냐, 중재자 토폴로지냐, 결국 워크플로 제어와 에러 처리 기능이 우선인가 아니면 고성능과 확장성이 더중요한가의 트레이드오프를 잘 따져 선택할 수 밖에 없습니다.
+
+## 14.4 비동기 통신
+
+이벤트 기반 아키텍처 스타일은 (이벤트 컨슈머의 응답을 받아야 하는) 요청/응답 처리 뿐만 아니라 (응답이 필요없는) 파이어 앤드 포켓 처리 모두 비동기 통신만 사용한다는 점에서 다른 아키텍처 스타일과 차별화됩니다.
+
+## 14.5 에러 처리
+
+리액티브 아키텍처의 워크플로 이벤트 패턴은 비동기 워크플로에서 에러 처리 문제를 해결하는 한 가지 방법입니다. 이 패턴은 워크플로 대리자를 통해 위임, 봉쇄, 수리 작업을 합니다.
+
+## 14.6 데이터 소실 방지
+
+데이터 소실이란, 메시지가 도중이 삭제되거나 최종 목적지에 도달하지 못한 상태를 말합니다.
+
+## 14.7 브로드캐스팅
+
+이벤트 기반 아키텍처는 메시지를 누가 받든, 그 메시지로 무슨 일을 하든 상관없이 이벤트를 브로드캐스트(전파)할 수 있습니다.
+
+## 14.8 요청-응답
+
+처리도중 필요한 것들이 생길 경우에는 동기 통신이 필요함. 이벤트 기반 아키텍처는 동기 통신을 요청-응답 메시징 방식으로 수행합니다.
+
+## 14.9 요청 기반이냐, 이벤트 기반이냐
+
+요청 기반 모델과 이벤트 기반 모델 모두 소프트웨어 시스템을 설계하는 유효한 접근 방식입니다. 워크플로의 확정성과 제어가 중요하면 체계적인 데이터 기반의 요청에 특화된 요청 기반 모델을, 복잡하고 동적인 유저 처리 등 주로 고도의 응답성과 확장성을 요하는 유연한 액션 단위의 이벤트를 처리한다면 이벤트 기반 모델이 좋은 선택입니다.
+
+## 14.10 하이브리드 이벤트 기반 아키텍처
+
+## 14.11 아키텍처 특성 등급
+
+단순성이 1점, 진화성 내고장성 성능 확장성 5점