24.08.06
today 😉
[MSA 환경에서 ErrorHanding, Utils는 어떻게 관리되어야 할까❓]
각각의 서버에서 공통 로직을 들고 있는 것이 베스트 처럼 보인다.
jar를 공통 모듈로 두고 나머지 멀티모듈을 구현한다.
공통모듈을 빌드할때만 사용하여 jar파일에 포함되어 빌드되게 할 수 있다.
[bootjar, build, jar 차이점]
bootjar
- {project-name}.jar
- 배포용
jar
- {project-name}-plain.jar
- 라이브러리용
build
- 두가지 jar 모두 생성
실행
java -jar {project-name}.jar
a와 b 모두 build-gradle을 사용하지 않음
a와 b 모듈 의존성 관리 방법
plugins는 초기 세팅 버전이 들어가고
group, version 은 jar 생성할때 관련이 있다.
[API gateway 와 LoadBalancer❓]
게이트웨이는 네트워크상에서 서로 다른 통신망, 프로토콜 끼리 통신이 가능하게 하는 컴퓨터/소프트웨어
API 게이트웨이는 API 관리와 라우팅에 초점을 맞추고, 로드 밸런서는 트래픽 분산과 서버 부하 관리에 중점을 둡니다.
nginx 같은 두개의 역할을 모두 하는 것들이 있다.
[레지스트리는❓ feat. MSA]
레지스트리는 소프트웨어들에 대한 각종 설정 값, 정보를 담고 있는 저장소라고 볼 수 있다.
MSA에서 레지스트리는 주소록이다. 이게 왜 필요 한가?
Client Side Discovery(Spring Cloud Netflix Eureka_구현체를 직접 사용, 장점: 구현 간단, 레퍼런스가 많음, 단점: 폴리그랏polyglot 환경의 경우, 환경에 따라 여러 번 구현해야함))
Server Side Discovery(단점: 네트워크 hop이 증가해서 상대적 속도 지연)
Scale-out을 할때 주소록을 수동으로 업데이트 해줘야 한다는 단점이 존재한다. 이 단점을 보완하기 위해서 주소록을 관리해주는 서비스 레지스트리를 둔다.
Request에 따른 서비스 주소가 필요할 때 레지스트리를 사용하기도 한다.
하나의 서비스에 따른 인스턴스가 여러개일 때 레지스트리를 사용하기도 한다.
[멀티 모듈이란❓]
배포할 수 있는 단위를 모듈이라고 한다. 스프링 프로젝트 1개를 모듈이라고 볼 수 있다.
