./auth -> 인증
./agent -> 랭체인 서버
./common -> 공통
./core -> 메인 스프링부트 서버
./gateway -> 중계 프록시 서버
./batch -> cpu 바운드 작업 서버
./ ... -> 기타 등등
등으로 서비스를 나눠서 개발하고 있는데요
스키마는 통합된 형태이기에
어 뭔가 이상하네 진정한 MSA면 스키마도 서비스마다 별도로 해야하지 않나? 라는 의문을 가지기는했어요
고객사에서 이것도 MSA임 이러기도하고
경험도 부족하고, 초보티 내기 싫어서
그런가보다 하고있었는데
여기서 궁금증이 갑자기 든 부분이 뭐냐면
만약 서비스 별도로 스키마를 나누면
하나의 스키마에 존재하는 모든테이블 마다 연관관계가 사라지게 되고
이때는 RDB의 조인을 쓸 수 없게되는데
그렇다면 외래키에 해당하는것을 그냥 인자로 받아서 영속성 상관없이 독자적인 테이블로 사용하는건가요??
연관관계 그냥 없는체로??
그럼 트랜잭션은??
- dc official App
니 말대로 디비까지 나눠버리면 감당안되니까 디비는 통합해둔거임. - dc App
아닌경우라 한다면 관계형일 필요가 거의 없는경우만 해당한다고 보면 될까요 - dc App
디비까지 나누면, 글로벌 트랜잭션 도입을 하지, 트랜잭션을 포기하지 않음. 근데 글로벌 트랜잭션은 모르겟다 - dc App
아 미들웨어 기타 등등이 필요하겠군요.. 이해하였음 - dc App
MSA이전의 CBD에서도 당연히 테이블의 논리적 분할로 조인을 막는데. 조인은 풀어놓고 리소스를 분리하는게 무슨 MSA.. 대학생 수준에서 MSA흉내내기 아닌가?;;
이때는 RDB의 조인을 쓸 수 없게되는데 그렇다면 외래키에 해당하는것을 그냥 인자로 받아서 영속성 상관없이 독자적인 테이블로 사용하는건가요?? → Yes 그럼 트랜잭션은?? → 이제 그걸 db가 아니라 어플리케이션 레벨에서 직접 고민해야함, 지옥시작
냐는 지금 DB까지 아얘 나눈 경우 이야기 하는거임
트랜잭션을 고민한다는 것 자체가 잘못된 설계라는거임 - dc App
? - dc App
마이크로서비스에서 분산 트랜잭션을 고민하는 설계가 좋지않다는건 나도 아는데 고민할수밖에 없는 경우도 잇으니깐 항상 예시로 많이 나오는 결제와 정산 시스템같이
이게맞음 db 다 분리하는게 맞음
그냥 MSA 를 안하면 됨 얼마나좋아
msa 강하게 나누면 디비도 나누게 되는데 (단 n 서비스 1 db임. 유사 도메인의 서비스는 같은 디비 쓰는게 나음) 어플리케이션 레이어에서 오직 http 통신을 통해 여러 디비의 데이터를 핸들링 해야함.
그리고 메인 스프링부트 라는건 허상에 불과함. 메인 영역도 나눌 수 있음.
요건 미들웨어, 분산 시스템 더 공부하고 해봐여겠네여 - dc App
ㅇㅇ db 다 나누고 조인이나 트랜잭션은 어플리캐이션 레벨에서 구현해야함 - dc App