-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #32 from danmooozi/max
study(max): 13, 14chapter
- Loading branch information
Showing
2 changed files
with
69 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,41 @@ | ||
# 13. 서비스 기반 아키텍처 스타일 | ||
|
||
- 마이크로서비스 아키텍처 스타일의 일종 | ||
- 아키텍처가 유연해서 가장 실용적인 아키텍처 스타일 중 하나 | ||
- 덜 복잡, 비용이 많이 들지 않음 | ||
|
||
## 13.1 토폴로지 | ||
|
||
- 각각 따로 배포된 유저 인터페이스와 원격 서비스, 그리고 모놀리스 데이터베이스로 이루어진 대규모 분산 레이어 구조 | ||
|
||
<img width="589" alt="스크린샷 2024-11-10 오후 11 57 53" src="https://github.com/user-attachments/assets/c3763785-e14a-445c-8a82-e99c8e705fbc"> | ||
|
||
- 서비 기반 아키텍처의 도메인 서비스는 각각 단일 인스턴스로 패포 | ||
- 확장성, 내고장성, 처리량 요구사항에 따라 인스턴스를 여럿 둘 수 있다. | ||
- 서비스 인스턴스를 다수 생성하여 배포하려면 유저 인터페이스로 유입된 요청이 가용한 서비스 인스턴스로 흘러갈 수 있도록 유저 인터페이스와 도메인 서비스 간의 부하 분산 기능이 필요. | ||
|
||
### 13.2 토폴로지 변형 | ||
|
||
- 특유의 유연성 때문에 정말 다양한 변형이 존재 | ||
- 단일 모놀리식 유저 인터페이스는 다시 여러 유저 인터페이스 도메인으로 나눌 수 있고, | ||
- 각 도메인 서비스에 맞게 나눌 수도 있다. | ||
|
||
### 13.3 서비스 설계 및 세분도 | ||
|
||
- 보통 단위가 크다. | ||
- 도메인 서비스를 API 퍼사드 레이어, 비즈니스 레이어, 퍼시스턴스 레이어로 구성된 레이어드 아키텍처 스타일로 설계하는 것이 일반적. | ||
- 모듈러 모놀리스 아키텍처 스타일처럼 서브도메인을 이용해서 각 도메인 서비스를 분할하는 방법도 많이 쓰인다. | ||
|
||
<img width="602" alt="스크린샷 2024-11-10 오후 11 58 01" src="https://github.com/user-attachments/assets/6ac68a77-941e-473c-8f78-940a911ae9b5"> | ||
|
||
### 13.4 데이터베이스 분할 | ||
|
||
- 데이터베이스 변경 영향도와 리스크를 낮추는 한 가지 방법은, 데이터베이스를 논리적으로 분할하고 이러한 논리 분할을 연합 공유 라이브러리를 통해 명시하는 것. | ||
|
||
### 13.5 아키텍처 예시 | ||
|
||
### 13.7 언제 이 아키텍처 스타일을 사용하는가 | ||
|
||
- 도메인 주도 설계와 궁합이 잘 맞다. | ||
- 서비스를 큰 단위로 나누고 그 범위를 도메인으로 한정하기 때문 | ||
- |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,28 @@ | ||
# 14장. 이벤트 기반 아키텍처 스타일 | ||
|
||
- 확장성이 뛰어난 고성능 애플리케이션 개발에 널리 쓰이는 비동기 분산 아키텍처 스타일 | ||
- 적응성이 좋아 소규모 애플리케이션부터 크고 복잡한 애플리케이션까지 두루 사용할 수 있다. | ||
- 애플리케이션은 대부분 요청 기반 모델을 따른다. | ||
|
||
## 14.1 토폴로지 | ||
|
||
- 중재자 토폴로지와 브로커 토폴로지 | ||
- 중재자 토폴로지 : 이벤트 처리 워크플로를 제어해야 할 경우 | ||
- 브로커 토폴로지 : 신속한 응답과 동적인 이벤트 처리 제어가 필요할 때 | ||
|
||
### 14.4 비동기 통신 | ||
|
||
- 시스템 응답성을 전반적으로 높이는 강력한 기법으로 활용할 수 있다. | ||
|
||
### 14.5 에러 처리 | ||
|
||
- 리액티브 아키텍처의 워크플로 이벤트 패턴은 비동기 워크플로에서 에러 처리 문제를 해결하는 한 가지 방법 | ||
- 시스템 응답성에 영향을 미치지 않고 탄력적으로 에러 처리할 수 있게 만드는 패턴. | ||
|
||
### 14.6 데이터 소실 방지 | ||
|
||
- 불행하게도, 이벤트 기반 아키텍처는 데이터가 소실될 만한 곳이 많다. | ||
|
||
### 14.7 브로드캐스팅 | ||
|
||
- 이벤트 기반 아키텍처는 메시지를 누가 받든, 그 메시지로 무슨 일을 하든 상관없이 이벤트를 브로드캐스트 할 수 있다. |