억지로라도 마이크로서비스 경험해보고싶어서 간단하게 만들어보고 있는데
현재 컨테이너는 2개임
컨테이너1
-> 로그인/회원가입 담당 + grpc로 유저id나 이메일 같은정보 토대로 다른 컨테이너에게 유저정보 줌
예를들어서 이 컨테이너로 1234라는 유저 id를 요청하면 DB에서 해당 id에 맞는 유저 찾아서 다시 grpc 통신으로 응답함
컨테이너2
-> 물건 구매/판매 컨테이너로 유저정보 같은건 컨테이너1에 요청해서 갖고옴
근데 중요한건 컨테이너1이랑 컨테이너2가 같은 DB를 사용함.
그니까 사실 컨테이너2가 굳이 컨테이너1에 요청안하고 그냥 컨테이너2에서 DB뒤져서 유저정보 찾으면 되긴함
이러면 마이크로서비스가 아닌건가..?
아님 유저정보를 찾는 로직은 다른 컨테이너로 분리했으니까 마이크로서비스가 맞는건가..?
엄밀히 말하면 아니긴하지. 서비스를 도메인으로 나눠서 운영하는건데 모노 디비로 할꺼면 의미가없음
그럼 위 예제의 경우 2개 디비를 만들고 하나는 진짜 유저이름, 이메일 같은것만 저장하고 나머지 하나는 유저이름, 물건에 관한 정보들 이렇게 저장하는 방식으로 해야되나?
두개디비다 user id는 같은걸로 저장하고
디비에 중복 감수하고 디비 따로 써야지…. 머 니가 토이로 하는거니 지금은 상관없다만 디비에 부하가 두배로 걸리는 상황이잖음 - dc App
서비스가 제공하는 개념이랑 db랑 별개잖어 하나로 써도 무슨상관임
db 사이드이펙트로 결합돼있으니까 아니라 할수있잖음 - dc App
애초에 별도의 분리된 서비스처럼 운영하는게 핵심인데 db가 얽혀있으면 아키텍처 뿌리가 얽힌거나 마찬가진데 의미가 없지 장애대응도 마찬가지고
근데 디비랑 서버 중간에 메시지큐 하나 놓으면 되지않아?
마이크로 서비스 내부의 물리적 분할까지 신경써야한다고? 추상적인 개념으로 생각했는데….
DB 컨테이너 하나 더 올리자 - dc App
위에 애들 말 다 무시하셈 한명도 제대로 아는놈이 없음. 마이크로서비스의 핵심은 목적과 기능의 구분임. 위 같은 시나리오면 유저관리/유저데이터Normalize/유저조회 등 하나, 판매/구매기능 하나, 공용(global)데이터 저장소 하나 이렇게 해야함
공용 저장소는 DB위에 API든 이벤트 리스너든 서비스 하나 만들어서 유저 뿐만 아니라 예로 구매/판매 데이터, 기타 회사 관련 데이터 등 다양한 서비스가 참조할 수 있어야함. 각 서비스는 자기 데이터를 Normalize해서 보내주고.