아 난 왜 이렇게 똑똑하지??? 타고난 지능은 어쩔 수 없는듯
데이터 중복을 허용해서 서로 이벤트만 게시/구독하고 직접호출은 아예 없게 하는거임
예를들어 유저 서비스에 유저 나이정보가 있고 주문 서비스에 주문 목록이 있을때, 주문 목록을 유저 나이로 필터링하려면 주문 서비스의 유저 테이블에 유저 나이 컬럼을 추가해서, 앞으로는 유저 생성/업데이트 이벤트를 받을 때마다 유저 나이 컬럼도 동기화 시켜주는 식
유저 나이 컬럼은 이제 주문서비스, 유저서비스에 중복으로 있는 대신 주문 서비스가 주문 목록을 유저 나이로 필터링 할때 유저 서비스를 호출하지 않아도 됨
ㄹㅇ 개쩌는듯 ㅋㅋㅋㅋㅋㅋㅋ
데이터 중복을 허용해서 서로 이벤트만 게시/구독하고 직접호출은 아예 없게 하는거임
예를들어 유저 서비스에 유저 나이정보가 있고 주문 서비스에 주문 목록이 있을때, 주문 목록을 유저 나이로 필터링하려면 주문 서비스의 유저 테이블에 유저 나이 컬럼을 추가해서, 앞으로는 유저 생성/업데이트 이벤트를 받을 때마다 유저 나이 컬럼도 동기화 시켜주는 식
유저 나이 컬럼은 이제 주문서비스, 유저서비스에 중복으로 있는 대신 주문 서비스가 주문 목록을 유저 나이로 필터링 할때 유저 서비스를 호출하지 않아도 됨
ㄹㅇ 개쩌는듯 ㅋㅋㅋㅋㅋㅋㅋ
그냥 같은디비 보는 거에 비해 장점이 뭐임?
그럼 유저서비스는 디비 양쪽을 다 보고 업데이트치고 그중 하나를 주문서비스가 빨대꽂아 쓰는 모양 아닌가?
음..그리고 나중에 그런 중복칼럼을 쓰는 서비스가 히마씩 늘어날때마다 유저서비스 소스도 그쪽 디비 업데이트 치도록 같이 수정해줘야 하는 건데 그런 게 많아지면 그런 디펜던시 관리가 번거롭지 않을까
양쪽을 다 보고 업데이트 치는 건 아니고 유저 업데이트가 일어나면 이벤트 게시를 하면 주문 서비스에서 이벤트를 받고 주문 서비스 내의 나이 컬럼을 업뎃치는거야
다른 서비스 유저 컬럼 추가하는 거 때문에 유저서비스 코드를 건드려야 히는 것 자체를 msa라고 볼 수 있는지도 궁금하다
나중에 비슷한 도메인이 마이크로 서비스로 쪼개졌을때 중복 컬럼 많아질때가 고민이긴 함
그럼 만약 유저서비스 쥭었는데 각자 동기화되어야하는 데이터가 동기화 안된채로 주문로직이 돌아갈 시나리오는 없나?? 주문뿐만아니라 비슷한구조의 다른시나리오들이라도 말이지
너가 약간 이해를 잘못하고 있긴 한 거 같은데 어쨌든 ㄱㅅ
사실 이벤트가 유실될 일은 없어서 결국 데이터가 맞춰지긴하거든 사실 결과적 일관성이 유지되는 상태라 니 말대로 동기화를 신경써서 로직을 써야하긴함
ㄱㅅㄱㅅ
해당 댓글은 삭제되었습니다.
보통 이렇게 하는거임?
동기적 rest api 위주로 되면 msa라고 하기 애매하지 않나 싶음 아예 없긴 어려울 수도 있지만
혹시 근데 msa 플젝 해본적 있음? 동기적 호출이 필요한 경우가 어떤 경우가 있었음? 동기적 호출이 필요한 경우에는 그걸 떠로 서비스로 뺐음?
만약 eventual consistency조차도 허용이 안 되는 민감한 비즈니스면 동기적으로 해야겠지? 내 팀은 msa로 되어있는데 안티패턴으로 범벅된 msa라서 어떻게 해야된다보다는 어떻게 하면 힘들다는 많이 알게됨
어떻게 하면 안된다고 느낀 예시가 뭐뭐 있음?
글 보니까 너도 이미 알고 있는 거 같긴한데 1. 마이크로서비스 분할을 테이블 단위로 한다 2. 비즈니스의 boundede context 분석이 선행되지 않는다 3. k8s 등 서비스 orchestration을 쓰지 않는다 4. 저장소를 분할하지 않는다 5. 팀 규모에 비해 너무 잘게 짜른다 6. tracing을 하지 않는다
추가적으로 spring cloud config, spring eureka 같은 것도 살짝 안티패턴이라고 느낌 이건 지극히 개인적인 관점임
그리고 맨 앞 서버가 단순 프록시만 하는 거
오옹 tracing은 로깅을 말하는거??
ㅇㅇ 비슷
ㄱㅅㄱㅅ
멩... 주문 서비스에서 유저의 동기화된 데이터를 다룬다는거에서부터 MSA보단 모놀리스에 가까워지지 않나요...?
각 서비스가 자기만의 유저테이블을 다 가지고 있음. 예를 들면 결제 서비스 유저 테이블에는 유저의 아이디, 포인트, 회원 등급, 가입일 컬럼이 있고 주문 서비스의 유저 테이블엔 아이디, 주문 횟수, 가입일 컬럼이 있음. 이런 식으로 일부 중복된 컬럼을 서로 이벤트 구독을 통해 결과적 일관성을 유지하면서 다른 서비스에 대한 의존 없이 로직을 작성하겠다는 의도
그러면 결국 주문 마이크로서비스에서도 유저 정보에 대한 처리를 해주는 무언가를 만들어야하는게 아닐까요? 하다못해 이벤트를 구독하고 적절히 유저-주문 연관테이블을 관리하는 코드가 추가돼야할텐데.. 유저, 주문 두개만 존재하진 않을테고 각각의 모든 서비스에 대해서 각각이 구독받아서 데이터베이스를 구축한다고 친다면 그건 MSA가 맞을지 잘 모르겠네요.. 원시데이터에 대한 어느정도의 전처리 및 후처리도 MSA의 역할이라고 생각하는데, 이걸 구독하는 코드에 넣는다 치면... 글쎄요.. 전 잘 모르게써요
서버의 메모리나 성능 변경비율도 크게 변함이 없다는 가정 하에 어느정도 상태를 유지시켜야 하는 서비스의 환경에서 이게 msa의 단점인듯.
일반적으로 트랜잭션이 서비스에 있는데, 서비스가 repository 계층을 넣도록 고정 시키면 메모리 낭비율이 ㅈㄴ 심해보이네
상황 고려해야되서 짜는데 msa 했다고 하길래 글 읽어봤는데 생각하면 할수록 좀 오반데.. 트랜잭션 복구 기능 고려해서 이렇게 짜서 성능이 안 떨어진다면 그건 니 서비스가 트랜잭션을 오랫동안 점유시켜도 돌아가게 설정했거나(이건 컴퓨터에 램에서 존재하는 메모리가 아깝고) 아니면 트랜잭션 객체 유지시간을 엄청 짧게 설정하게 했거나(성능 아깝고) 이렇게 해놓고 MSA 짰다고 한거면 개꼴받네
트랜잭션을 레파지토리 계층에 둬도 되는데 그건 일부 상황에서만 되는건데, 하나의 서비스가 그렇게 전부 repository 계층에 넣을 수 있도록 서비스를 만들었을 것 같진 않아서 이렇게 말한 그대로 안 만들었길 빈다..