- Ground Rule
- Git 전략, Commit Convention, PR review
- [회원] 전체 흐름
- 환경 변수로 비밀번호 입력이 필요합니다.
--spring.datasource.password={password}
- local DB 정보 입력이 필요합니다.
DATASOURCE_URLDATASOURCE_USERNAMEDATASOURCE_PASSWORD
-
URL : http://49.50.162.164:5601/app/apm/services/apm-1/overview?comparisonEnabled=true&environment=ENVIRONMENT_ALL&kuery=&latencyAggregationType=avg&offset=1d&rangeFrom=now-15m&rangeTo=now&serviceGroup=&transactionType=request
- ID : elastic
- P.W :
- module-api bootJar 실행 후 apm.sh 파일 .jar 뒤에
--spring.datasource.password={password}옵션 붙여서 sh 실행 시키면 client 실행 됩니다.
- 이 모델은 Choreographed SAGA 패턴과 유사합니다.
- 메시지 브로커 활용 대신 트랜잭션을 잡고 있는 점이 달라 장애 처리는 비교적 용이하지만, 복수 개의 서비스에 연쇄적인 트랜잭션이 생기고 있어 관리와 추적이 힘들다는 단점이 같습니다.
- 반면 2PC 패턴은 트랜잭션의 관리 주체가 한 곳으로 집중되어 트랜잭션 관리가 용이합니다.
- 반면 2PC 패턴은 트랜잭션의 관리 주체가 한 곳으로 집중되어 트랜잭션 관리가 용이합니다.
- api-module만이 Spring 의존도를 가지며 그 외 module은 도메인 로직을 가지도록 설계했습니다.
따라서 usecase에 따라 각 module에서 생성된 결과를 api-module에서 영속시킵니다. - 사이드 프로젝트이기에 복잡도가 높지 않기에 로직의 추가가 api-module에 영향을 주어도 괜찮다고 생각했습니다.
아마 실무였다면 트랜잭션 타임을 줄이기 위해 MQ를 도입하고 Orchestration Saga 패턴을 고려했을 것 같습니다.
하지만 사이드 프로젝트에 MQ까지 고려하는 것은 힘들었고, 도메인 분리와 모듈 프로그래밍에 집중하기 위해 2PC 패턴의 구성을 선택했습니다.
좀 더 많은 예시와 생각은 블로그를 참고 부탁드립니다. 분산 트랜잭션 설계하기 (초급)